I've implemented support for returning fullName field in the /rest/user endpoint (in Groovy script) to allow it to be synced to 1dev (using our extension for 1dev).

Additionally, I've added it to future /rest/user endpoint handler (UserHandler.java). Additionally, I've allowed this future endpoint to not only return full name but to also update it in Tigase XMPP Server user vcard.

Those changes in are separate branch rest-user-ext as I'm not fully convinced to them. While having fullName there is useful it adds additional load on this endpoint, I'm thinking that moving vcard management (including retrieval) to a separate endpoint would be a better idea.

That could force us in our 1dev extension to call Tigase endpoints twice, but it would give us clean separation of context (user vs vcard).

@wojtek What do you think?

Please note, that as I've looked at current /rest/user groovy script and compared it to UserHandler.java there is a different feature set offered by both. I think that we should decided on what this endpoint should do and offer only that in the new handler (in Java).

Also, I wonder if that wouldn't be a good time to switch our integration (for 1dev and other apps) to use this new endpoints written in Java? Those are disabled for now, but we could enable them as at some point we would disable old groovy scripts.

@kobit What do you think about?

I've implemented support for returning fullName field in the /rest/user endpoint (in Groovy script) to allow it to be synced to 1dev (using our extension for 1dev).

Additionally, I've added it to future /rest/user endpoint handler (UserHandler.java). Additionally, I've allowed this future endpoint to not only return full name but to also update it in Tigase XMPP Server user vcard.

Those changes in are separate branch rest-user-ext as I'm not fully convinced to them. While having fullName there is useful it adds additional load on this endpoint, I'm thinking that moving vcard management (including retrieval) to a separate endpoint would be a better idea.

That could force us in our 1dev extension to call Tigase endpoints twice, but it would give us clean separation of context (user vs vcard).

@wojtek What do you think?

We already have separate endpoint for avatar?

As for limiting load? Maybe add the information conditionally on parameter (e.g: ?includeVcardInfo=true or somesuch). IMHO it should be the best - we need this info eitehr way and if we care about load, limiting number of calls to Tigase REST is also good.

I was considering adding parameter for that (to enable additional data being returned).

I was considering having a separate /vcard endpoint to make it possible to make changes and fetch data from vcard using REST API while at the same time keep it separated from /user data (account details). Separation of scopes of data (data domains). I wouldn't like to push everything from vcard to /user endpoint as it would end up being huge (even if some data would be returned if parameter would be passed).

I think we can close that as in the end we are going to use LDAP for syncing data and not REST API. Right now LDAP does not expose user full name, but we could add it there.

Due to that I think we can close this issue.

agreed