How can I read context attributes with HTTP API?

[janny_buh]

Hi,
I'm experiencing on config cascade on OXSE 6.20 and 7.4:
http://oxpedia.org/wiki/index.php?title=ConfigCascade

In particular, I've added some custom user attributes using RMI api:

/opt/open-xchange/sbin/changeuser -A postmaster@uc.test.it -P password -c 1001 -u test.test@uc.test.it --attr_myUserAttribute/key1=value1

and I'm able to read that value using HTTP api:

http://myhost.it/ajax/user?action=getAttribute&id=3625&name=myUserAttribute/key1&session=6c458ae12d4f4cedb61e37e03d5152a6


{"data":{"name":"myUserAttribute/key1","value":"value1"}}

Please note that, when using RMI to store properties, I need to prefix my custom user attribute "myUserAttribute/key1" with "attr_" in order to be able to read it using HTTP api (AFAIK this "feature" is undocumented ).



Now, I would like to store some custom properties at context level:

/opt/open-xchange/sbin/changecontext -A oxadminmaster -P secret -c 1001 --attr_myContextAttribute/key2=value2

but I don't know how to read that property with HTTP api.
I've tried to simply replace the previous call with:

http://myhost.it/ajax/user?action=getAttribute&id=3625&name=myContextAttribute/key2&session=6c458ae12d4f4cedb61e37e03d5152a6


{"data":{"name":"myContextAttribute/key2"}}

but it does not return the expected value. I've also tryed to omit the "attr_" keyword when using RMI api, but the result is the same...


I've checked that the "contextAttribute" table is correctly updated when using RMI api, so the value is stored into database as expected, but then I'm not able to read it using HTTP api.
Is it possible to read it somehow?

[Viktor Pracht]

The --attr_ prefix is not documented in the ConfigCascade article because it's not part of the config cascade. Only settings starting with --config/ are part of it.

If you want to have custom cascaded settings in the UI (e.g. for your own plugin), just create them as normal global settings in /opt/open-xchange/etc/settings/*.properties, and override them with --config. I just updated the section about UI Properties with an example.

[janny_buh]

Thanks for your reply, I'll try to experiment a bit with your solution

Just another quick question:
ConfigCascade lets "cascade" my custom plugin settings into user UI so that I should be able to access those properties, within javascript, using configGetKey().

So, if this is correct, what is the purpose of User/Context Attributes and how can I access them using HTTP API (if possible)?
http://oxpedia.org/wiki/index.php?ti..._with_v6.20.29


My problem is that I could need some settings being read both from OSGI bundles (at server side) and UI (at client side), so I think that User Attributes could fit my need. I already know how to access them at server side, using RMI API (prefixing them with "attr_" keyword) or directly reading the User object in Session, and I also know how to access those properties with HTTP API at the client side.

I recently found that there are also Context Attributes that can be manipulated using RMI API, so my question is if I can access them at client side and it they could be "cascaded" into User Attributes (I guess that latter is not possible)

Thanks

[Viktor Pracht]

The cascade is not about the UI.
The cascade is about propagation of values through the scopes: from global scope to context sets, to contexts, to users.
If you want a setting to be available both in the UI and on the server, the solution is the same as before: Read properties from /opt/open-xchange/etc/*.properties using a ConfigurationService, and provide them as UI settings by implementing a PreferencesItemService for OX6 and either mapping that in /opt/open-xchange/etc/paths.perfMap or registering a ConfigTreeEquivalent for OX App Suite. If you don't need OX6 support then you should use the new JSlob infrastructure.
In any case, the config cascade applies automatically to all values in /opt/open-xchange/etc/ and /opt/open-xchange/etc/settings/.