1 person found this helpful
We're seeing issues like this in the core product without using the API.. so it could be that the REST API isn't at fault.. you're using it right, but the underlying code isn't working quite right. We're on 188.8.131.52.
We too are on 184.108.40.206. If its not the way I use it that's wrong, I suppose that I will log a case to go to the bottom of it (if it hasnt already been done).
Thanks for the input!
Hi Maxime. Can you provide me some specifics around which fields are being deleted, along with an example of the data you're passing to the Person update service?
Hi Ryan, here is how we proceed in our script :
- For each user we have to update, we get his actual data : GET http://our.jive.community.com/api/core/v3/people/xxxx
- We build a dynamic list of profile fields from the results of the GET request for this user;
- We modify the value of the profile fields that needs to be updated;
- We update the user by doing a PUT http://our.jive.community.com/api/core/v3/people/xxxx . The body of this request is generated from the modified profile fields list for this user and have the same structure as the body of the response we got from the initial GET request.
The script works fine. But after doing some more tests, this is what I've found out :
- Lets say a user change all the privacy settings he can for different values than the default ones.
- If we update his profile with our nightly script :
- If a profile field was empty and is still empty after the update : the privacy setting for this field will not be lost (since the field was not actually updated);
- For all the other case (new value, updated value, deleted value/update to blank) : the privacy setting of the update field will be lost.
In our case, all the information we get from the original GET is sent back in the PUT request, so even for the fields that havnt changed, it still count as an update and the privacy settings are lost.
I hope my explanation are clear enough, if not, dont hesitate to tell me.
Also, Matt mentioned that he was seeing similar behavior in the core Jive product (without using the REST API). I havnt been able to reproduce that after all except for a field that I only have in my UAT environnment. Its the only "Boolean" field I have and its not a field the user can update himself but they can change its visibility. Currently no values are selected, but every time I save my profile (in Jive, not the REST API) I lose the privacy setting on this field. Its the only occurrence of this behavior that I got in Jive.
So, if you have any questions, dont hesitate to ask!
Any additional info on this? We are looking to use the API for a nightly update also (JIveX Essentials, cloud) Not wild about the idea of all the users privacy settings reverting back to the defaults. It will impact how we do the nightly update.
This problem was identified as a severity 1 bug back in november (JIVE-38448) and its now fixed. So you should not have to fear for your users privacy settings reverting back to the defaults. But if you want to be certain, its easy to test.
By the way, if you are looking at updating daily your users profile using the REST API, you might want to make sure you are not running into another issue that we have : the profiles we update using the REST API are updated correctly after each nightly update, but the information in the Analytical Database is not always updated accordingly when the ETL runs. So the impact is that I cannot trust the informations returned in the CMR Profile Completion report because it often show old outdated data.
We are currently on 220.127.116.11, so you might not have this problem (or maybe nobody else than us have this problem), but it would be best to make some tests on your side before you start using the REST API, because if you rely on the CMR reports, you might have to stops doing it if you cannot trust whats in the reports.
Thanks so much for the update and the heads up about the analytical database. Will add it to the testing plan☺