Updating setting reverts display_name to null and settings property is empty

RESOLVED FIXED

Status

support.mozilla.org
BuddyUp
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: espressive, Assigned: mythmon)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

3 years ago
Currently I do the following to update a setting with regards to notifications:

request_with_auth(endpoint, 'PATCH', { settings: setting })

The end point would be:
https://support.allizom.org/api/2/user/SmallRedDog415/?format=json

The payload would be:
{"settings":{"new_comment_notify":false}}

After having sent the request, the server responds with a 200 OK but, the user object that is returned, looks as follows:

{
  username: SmallRedDog415,
  display_name: null,
  date_joined: "2014-12-17T23:51:17Z",
  avatar: "https://secure.gravatar.com/avatar/d41d8cd98f00b204e9800998ecf8427e?s=48",
  bio: null,
  .... // some additional fields
  settings: Array[0] // aka, empty array
  ....
}

The problems then here are:
1) The display name is reverted to null
2) The settings Array is empty

The pull request that among other things contain the UI code is at the address below:
https://github.com/mozilla/buddyup/pull/39
(Reporter)

Comment 1

3 years ago
Just FYI, I have also tried this with the payload simply being:
{"new_comment_notify":false}
(Reporter)

Comment 2

3 years ago
I have also tried sending the following as the payload:
{"settings":[{"name":"new_comment_notify","value":true}]}
Component: Users and Groups → BuddyUp
(Assignee)

Comment 3

3 years ago
You cannot manipulate settings through PATCH. This is a shortcoming of the API I hope to eventually fix, but for now you have to use the endpoints /api/2/user/<username>/set_setting and /api/2/user/<username>/delete_setting to add or remove settings on at a time.
(Reporter)

Comment 4

3 years ago
Got it, thanks Mike!
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
(Reporter)

Comment 5

3 years ago
If a setting exists, calling set_settings will not overwrite the current setting but simply add a duplicate.

I assume this means we need to always first delete the setting before setting it. This is a problem for, especially the profile view, as we have two settings on here and then other user data. This then means that when a user updates their profile, we will have to:

1) Make a call to PATCH the user details excluding the settings.
2) Make a call to delete the first setting
3) On success, set the first setting again
4) Make a call to delete the second setting
5) On success, set the second setting again
Status: RESOLVED → REOPENED
Flags: needinfo?(mcooper)
Resolution: FIXED → ---
We should be able to overwrite the existing setting. Schalk: Have you tried using PUT instead of POST?

If PUT doesn't work, then it's a server side bug we should fix.
Flags: needinfo?(schalk.neethling.bugs)
(Assignee)

Comment 7

3 years ago
This is definitely a server side bug. PUT probably isn't even allowed. set_settings is supposed to be more like a "upsert" or set/update operation. Duplicates should not be possible (and in fact, I thought there was a database constraint preventing that, but I guess not).
Flags: needinfo?(schalk.neethling.bugs)
Flags: needinfo?(mcooper)
(Assignee)

Updated

3 years ago
Depends on: 1118037

Updated

3 years ago
No longer depends on: 1118037
Let's close this bug and track the dependency back to the correct BuddyUp bug.
Status: REOPENED → RESOLVED
Last Resolved: 3 years ago3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.