Replies: 2 comments
-
It's not a DB migration step, just an artifact of us fixing a bug where the values were being displayed as strings instead of numeric booleans. Users are not created with values in the permissions field by default - someone would have had to save their profile to set those values. See also #16836 |
Beta Was this translation helpful? Give feedback.
0 replies
-
Thanks for the explanation. Good to know there's nothing wrong with the DB. So I gather it wouldn't be too difficult to cook up an artificial zero-permissions object in the API if DB says there's no such thing? |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Summary
I upgraded from 8.0.X to 8.3.1 and somewhere in there the
permissions
field of a user appears to have broken.So for instance
GET /users
GET /users/me
Format
First off the format changed from string ints to plain ints. I.e. it used to look like this
and now it's like this:
That's actually a step for the better IMO. Booleans would be even better.
This wasn't the real issue though.
Empty objects
The real issue is that the majority of users will return an empty object:
Sure enough they don't have any rights either, but this should be indicated as just having all the fields at 0. If you edit the permissions of such user the problem goes away. You'll get a full permissions object whether they have permissions or not.
So it appears like some db migration step might be lacking?
Beta Was this translation helpful? Give feedback.
All reactions