Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

User & Roles API: Who can invite what role #3083

Closed
ErisDS opened this issue Jun 24, 2014 · 8 comments · Fixed by #3388
Closed

User & Roles API: Who can invite what role #3083

ErisDS opened this issue Jun 24, 2014 · 8 comments · Fixed by #3388
Assignees
Labels
affects:api Affects the Ghost API

Comments

@ErisDS
Copy link
Member

ErisDS commented Jun 24, 2014

The User API will need to be updated to honour the following:

  • The new owner role can do anything it likes.
  • An admin can invite a user, and that user can have the admin, editor or author role.
  • An editor can invite a user, but that user can only have the author role.
  • An author cannot invite a user.

As well as enforcing that a user is not able to create a user with a role it shouldn't be able to, we also need a way to determine the list of roles a user can create, in order to correctly populate the dropdown in #3079

The dropdown should be correctly populated as a result of this issue.

@sebgie
Copy link
Contributor

sebgie commented Jun 24, 2014

Do we want to let admins create other admins or should this be a right only the owner of a blog has? This question comes up for me when thinking about who has permission to delete other users? I guess admins should only be deleted by the owner or are admins allowed to delete other admins (probably a new issue)? And as a follow up question what happens to the posts/tags/created-/updated_by relations/... of a deleted user?

@ErisDS
Copy link
Member Author

ErisDS commented Jun 24, 2014

The rules here should be correct for edit/delete too. An admin is a trusted user.

Not sure what we're going to do with the relations, that's a good question and probably one for @JohnONolan to wade in on.

@nuclearpengy
Copy link

I think generally "admin" is assumed to be almost all powerful, just not as powerful as "owner".

If I hire someone and give them access to something as 'Admin", they should be able to do what ever it takes to get the tasks done, even if this mean recruiting and adding other admins.

I would however not want an admin to be able to delete me(owner). ;-)

On the delete front, I guess this depends on if we're "deactivating" the account or actually removing it from the DB.

@JohnONolan
Copy link
Member

Admins can do everything an owner can. At this stage only difference between admin and owner is that owner cannot be deleted.

@nuclearpengy
Copy link

ok cool.

@ErisDS
Copy link
Member Author

ErisDS commented Jun 24, 2014

The owner can transfer ownership to an admin. That is the only extra power it has.

@nuclearpengy
Copy link

on delete, should we consider prompting to have posts by the previous user assigned to a different userID or do we leave some form of reference.

the use case I can think of is when a user has been a regular publisher/contributor and stops contributing. Their account is deleted but their content is still visible but unlinked.

Should we not then consider, deactivating the account so that all previously published posted can still be linked to the original author.

Alternatively should we not do a check to see if a user has already published content:

On delete
if user has published posts
deactivate account
else delete user?

just a thought.

@ErisDS
Copy link
Member Author

ErisDS commented Jun 25, 2014

The delete user flow will include an option to decide what to do with the content. @JohnONolan is working on the issue to do this, and there is also #3100

@ErisDS ErisDS assigned jaswilli and unassigned javorszky Jul 22, 2014
ErisDS added a commit to ErisDS/Ghost that referenced this issue Jul 28, 2014
refs TryGhost#3083, TryGhost#3096

In order to implement advanced permissions based on roles for specific
actions, we need to know
what role the current context user has and also what action we are
granting permissions for:
- Permissible gets passed the action type
- Effective permissions keeps the user role and eventually passes it to
  permissible
- Fixed spelling
- Still needs tests
ErisDS added a commit to ErisDS/Ghost that referenced this issue Jul 28, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
affects:api Affects the Ghost API
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants