What does Managed="0" in List view XML mean?

Question

I've written a Data Extender class and editor extension that properly displays a few additional columns for items as you browse lists in the CME (folders and structure groups). I had to register my class to handle commands like GetList, GetListSearch, GetListUserFavorites, and GetListCheckedOutItems.

What I've noticed is that the code gets run even when a list of say, schemas is loaded for a drop-down list in the CME (like when creating a new component and you get the list of schemas in a drop-down). so, even though my additional data columns aren't needed in that situation, the code is still being executed and it slows things down.

It seems that it's the GetList command called in those situations. So, I can't just skip processing based on the command. So, I started looking at the XML that the class receives for the list and I've noticed when the code is run for the drop-downs, there's a Managed="0" in the XML. For example:

• For a Structure Group list: <tcm:ListItems Managed="64" ID="tcm:103-546-4">
• For a Folder list: <tcm:ListItems Managed="16" ID="tcm:103-411-2">
• But for a Schema list: <tcm:ListItems ID="tcm:0-103-1" Managed="0">
• For a drop-down showing keyword values for a category: <tcm:ListItems Managed="0" ID="tcm:103-506-512">

So, can I just use this Managed="0" as a flag to indicate that the list being processed isn't going to show my additional columns and I can just quit processing?

Answer 1

Managed value is representation of what items can be created inside OrganizationItem:

• 64 means you can create pages
• 16 means you can create components
• 10, for example would mean you can create folders (2) + schemas (8)
• 518 - folders (2) + structure groups (4) + categories (512)

The value is 0 for non organizational items.

Value depends on the item itself (you can't create pages in folder, for example), as well as on security settings you have on publication and organizational item

Answer 2

Unfortunately CME can't offer right now that kind of granularity level to allow you to tell in a data extender where a particular WCF API call is coming from. Our WCF API is not context aware yet. It may change in the future.

Trusting Managed="0" is not a great idea. The reason for that is the model lists are client cached per filter. In the current design the filter has CM related data and nothing related to the context the request is being fired from. Typically the client user interface is reusing cached model data whenever is possible. For instance the same model list could be used in the CME dashboard and a drop down control placed into some item view, but with different xml list definitions: the first one will have more columns defined in the list definition than the latter. They are basically different views of the same data.

Therefore you may want to think of different solutions for your problem. Now... where is the data behind those additional columns is coming from? Is it Tridion CM or a third party provider? Sometimes the web server caching may provide an acceptable way to improve the response times. But that's the kind of design you should evaluate and decide upon.

Answer 3

I think you would have a more robust solution if you read the ID of the list, and only execute your code for lists of type 2 and 4 (Folders and Structure Groups respectively). but that won't help you with search views etc.

Answer 4

From previous experience and what User978511 says the Managed attribute is an indication of item types that can be created from the context of that list.

Unfortunately that means that the Managed attribute may well be 0 for any user that doesn't have sufficient rights to create items. E.g. check what Managed is in a Structure Group for a user that isn't allowed to create Pages or Structure Groups. It may well be 0 in that case too, meaning it is useless for your situation.

Update

You may be able to reach your goal better by looking at the columns parameter:

context.Parameters["columns"]

In a few tests I've run I get different values, depending on whether I get a list for the main list view, the tree or a drop down list.

543
 23
  7

Those values are a bit mask of these constants (from Constants.js):

/**
 * Defines the column filter.
 * Used to specify which attributes should be included in XML list data.
 * @enum
 */
Tridion.Constants.ColumnFilter =
{
    ID: 1,
    ID_AND_TITLE: 3,
    DEFAULT: 7,
    EXTENDED: 15,
    ALLOWED_ACTIONS: 16,
    VERSIONS: 32,
    INTERNALS: 64,
    URL: 128,
    XML_NAME: 256,
    CHECK_OUT_USER: 512,
    PUBTITLE_AND_ITEM_PATH: 1024
};

So from my limited testing it seems that drop downs request DEFAULT columns, while the main list view and the tree both have ALLOWED_ACTIONS in there. This makes sense to me, since the user gets can interact with the list items in the tree and list view, while they can only select them in the drop downs. So checking for the presence of ALLOWED_ACTIONS in the columns parameter might be one way to reduce the number of places where your data extender adds information.