Returning custom properties in the 'getChildren' Web script

[deane]

The "getChildren" Web script –

GET /alfresco/service/api/path/{store_type}/{store_id}/{id}/children?types={types}&filter={filter?}&skipCount={skipCount?}&maxItems={maxItems?}‍

– specifies a "filter" argument.  The definition is this:

String filter: Filter specifying which properties to return.

What is the format of this?  I have a custom property of "custom:Type".  What would I put in the "filter" argument to return this?  I've tried about everything.

I've specified "ObjectId," and it did limit the returned properties to the "cmisbjectId" property.  But am I limited to just the "cmis" namespace?  Can I get my custom property out?

Deane

[t_broyer]

The "getChildren" Web script –

GET /alfresco/service/api/path/{store_type}/{store_id}/{id}/children?types={types}&filter={filter?}&skipCount={skipCount?}&maxItems={maxItems?}‍

– specifies a "filter" argument.  The definition is this:

String filter: Filter specifying which properties to return.

What is the format of this?

A comma-separated or space-separated list (the current implementation just checks if a given property name exists in the filter, so fooObjectIdbar would give you the ObjectId property)

I have a custom property of "custom:Type".  What would I put in the "filter" argument to return this?  I've tried about everything.

I've specified "ObjectId," and it did limit the returned properties to the "cmisbjectId" property.  But am I limited to just the "cmis" namespace?  Can I get my custom property out?

You're limited to properties that would be listed when you omit the filter (or use filter=*), that is, a fixed set of CMIS properties.

[deane]

You're limited to properties that would be listed when you omit the filter (or use filter=*), that is, a fixed set of CMIS properties.

So, is there any way to get my custom property back from this Web script?  Or do I have to write my own Web script?

[t_broyer]

So, is there any way to get my custom property back from this Web script?

No (from what I've read in the webscript sources)

Note that this seems to be a limitation of the Alfresco implementation of CMIS, not in CMIS itself (I didn't read the spec closely, though), so you're free to submit patches 😉
(hint: the file you'd need to patch is templates/webscripts/org/alfresco/cmis/atomentry.lib.atom.ftl)

Note: actually, unlike I said in my previous message, the filter must be a comma-separated list, per CMIS spec:

A property filter can be used to specify which properties to be returned in a request. A valid property filter will follow the following grammar:

[*] | <propertyname>[,[ ]*<propertyname>]*
‍‍‍

or in other words:

A property filter is a string that contains either ‘*’ (to return all properties) or a comma-separated list of property names (to return selected properties). An arbitrary number of spaces are allowed before or after each comma.

Alfresco's implementation never throws FilterNotValidException though in case you pass an invalid (e.g. space-separated list) filter.

[bill_curtis3]

I am new to this forum and to this product, but I have been doing ECM for quite a while with IBM's products.  I was wanting to port a client I wrote to Alfresco to hit a new market, but I ran into a small problem.  I separate the different object types into different tabs to display their attributes completely.  I am using dojo, and I wanted to use or modify the AtomReadStore to retrieve the contents of a folder, but I don't get enough info back from the RESTful APIs to sort the documents into their appropriate types.

For my example, let me use the "my:sop" that we are all familiar with.  There is at least one field that I want to show, it is called authorisedBy.  When I get either the properties of that 1 document, or if I get the list of children that contain this 1 document, it doesn't show me the my_authorized field.  This is because of what is explained before.

My suggestion is this:

1.  Instead of comparing a known list of fields to the ones specified in the filter, make the filter specify which fields are to be used.  Change the FTL to iterate through the list of fields, and if the filter is empty or if the filter is *, then put in a default list of fields.

2.  Generate a default list of fields using a helper function that can be incorporated into the .js portion of the Web Script.  It could be called just like "cmisproperty", call it "cmisallproperties".  That helper function would then list all non-stream, non-internal/system properties.  This list could then be split or iterated.

3.  If you reverse the properties from a known list  to an unknown list of fields, then you would have to be able to discover property types.  Again, you would need one of those helper functions/classes like cmisproperty to get the type.  It could be called cmispropertytype and could take 1 parameter, the name of a field, and it would return the values of "INTEGER", "STRING" and so on.

If you did all of this, then you would end up with a way to always describe a document and ALL of its fields.  If you don't want all of the fields, then change "filter" to whatever you need.  It would be better if the call would be too verbose by default.

Another handy idea would be to add filtering of not only "types", but model object types as well.  That way you could filter down to "my:sop" documents only. 

Thanks,

Bill

[t_broyer]

I believe this is now done in HEAD, as Dave Caruana has been working on it recently. See http://twitter.com/dcaruana/statuses/1317716516 and http://twitter.com/dcaruana/statuses/1371141876 among others.

[bill_curtis3]

Thanks for the info, I will start watching his other info on Twitter.  I will also get the latest head.  Again, thanks.