You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As I've been working on writing tests for #3196 and also getting the user permissions correct and tested for #3096 I've hit a roadblock whereby it's impossible to make all of the conditions pass.
Essentially, I have what I believe is a full suite of tests, where one test always fails. Every time I fix the permissions so that the broken test passes, that change breaks another test.
There are a couple of underlying problems with the permissions model which is causing this:
For user edit and add we now have 2 permissions checks:
canThis(context).add/edit.user(userId) and canThis(context).assign.role(roleId)
This is a bit restrictive in that:
We can't ask if the context can assign a role to a specific user, essentially the code should probably be:
canThis(context).add.roleUser(roleId, userId)
But joinTables aren't treated as models and canThis isn't really setup for testing the join tables. canThis(context).add.role(roleId, userId) or canThis(context).add.role(roleId).to.user(userId) would be great, but will require extensive reworking of canThis.
This is not so bad, and we'll likely have an issue to extend canThis and fix this later.
Inside of testing for assign permissions, we don't know whether we're assigning to a new or existing user.
The rules for assigning to an existing user, and assigning to a brand new user are subtly different:
no one can assign the owner role to a new user
owners can assign the owner role to an existing admin user
This could be solved by having 2 permissions: assignToNew and assignToExisting, but the above latter rule is actually just one very special case purely for transferring ownership. When the owner wants to transfer their ownership to another user, they can do so only if the other user exists and is already an admin. No one else is ever allowed to perform this action, and this action is already considered to be different to a standard edit in the UI (there's a different control),
Furthermore, it seems odd to me that in a certain case, calling edit on a user model can cause more than one user to be updated.
Finally this would resolve both my problems with the permissions model and #3403 in one fell swoop. Therefore I believe, making an endpoint just for this change makes the most sense.
That just leaves what to call it.. I'm looking at:
closesTryGhost#3426
- added transfer ownership endpoint
- added owner to roles.permissible
- manually removed owner from roles.browse
- removed hard coded author role
- fixed tests that were passing due to hard coded author role
- added testUtils.setup(‚roles‘)
As I've been working on writing tests for #3196 and also getting the user permissions correct and tested for #3096 I've hit a roadblock whereby it's impossible to make all of the conditions pass.
Essentially, I have what I believe is a full suite of tests, where one test always fails. Every time I fix the permissions so that the broken test passes, that change breaks another test.
There are a couple of underlying problems with the permissions model which is causing this:
For user edit and add we now have 2 permissions checks:
canThis(context).add/edit.user(userId)
andcanThis(context).assign.role(roleId)
This is a bit restrictive in that:
canThis(context).add.roleUser(roleId, userId)
But joinTables aren't treated as models and canThis isn't really setup for testing the join tables.
canThis(context).add.role(roleId, userId)
orcanThis(context).add.role(roleId).to.user(userId)
would be great, but will require extensive reworking of canThis.The side effect of this is that the check which prevents modifying your own role has to be outside of the permissions system: https://github.com/TryGhost/Ghost/pull/3395/files#diff-e1c52a506c4dfb4202439ef6db5f2de0R111
This is not so bad, and we'll likely have an issue to extend
canThis
and fix this later.assign
permissions, we don't know whether we're assigning to a new or existing user.The rules for assigning to an existing user, and assigning to a brand new user are subtly different:
This could be solved by having 2 permissions: assignToNew and assignToExisting, but the above latter rule is actually just one very special case purely for transferring ownership. When the owner wants to transfer their ownership to another user, they can do so only if the other user exists and is already an admin. No one else is ever allowed to perform this action, and this action is already considered to be different to a standard edit in the UI (there's a different control),
Furthermore, it seems odd to me that in a certain case, calling edit on a user model can cause more than one user to be updated.
Finally this would resolve both my problems with the permissions model and #3403 in one fell swoop. Therefore I believe, making an endpoint just for this change makes the most sense.
That just leaves what to call it.. I'm looking at:
router.put('/users/owner', api.http(api.users.transferOwnership));
The text was updated successfully, but these errors were encountered: