Add role endpoint

[sebgie]

To make available roles accessible by the frontend we need an endpoint to fetch all available roles.

• GET /ghost/api/v0.1/roles/: returns all available roles

As second endpoint will be needed to get all roles a user is allowed to assign #3079.

• GET /ghost/api/v0.1/roles/?permission=<my-role>: returns all roles filtered by permissions. For example an admin will get all available roles except for the owner role and an editor will get the author role only. Implementation will have to be in accordance with User & Roles API: Who can invite what role #3083.

[javorszky]

I'll start with this as #3083 needs this. Unless someone already started it.

[javorszky]

Hm, would I be able to fake ?permission=<my-role> though? I assume server side there'd be additional validation to make sure that the user making the request does actually have the role that he sent down.

[sebgie]

I see this endpoint as informative only. Everyone can query what roles are available to a permission and if the permission is faked the operation that uses the information will fail. The real check has to be done when a new user is invited/deleted.

I think this endpoint doesn't need special permissions. But some thought has to be put into implementing the relation between roles and permissions.

Sent from my iPhone

On 05.07.2014, at 14:15, Gabor Javorszky notifications@github.com wrote:

Hm, would I be able to fake ?permission= though? I assume server side there'd be additional validation to make sure that the user making the request does actually have the role that he sent down.

—
Reply to this email directly or view it on GitHub.

[sebgie]

As discussed in IRC it would make more sense to use the permission that is needed instead of the role of the current user for the filter.

• GET /ghost/api/v0.1/roles/?permissions=add: returns all roles that are available to the current user for the add operation

[javorszky]

Note to self: user.related('roles').each(function (role) {});

<javorszky> although I'm unsure how I would be adding new rules to the canThis thing
<HannahWolfe> Cool :)
<javorszky> and whether I need to pass the whole user object to the canthis or only the ID is enough
<HannahWolfe> canThis should be passed options.context
<HannahWolfe> What that contains is determined elsewhere
<javorszky> hm... is there any documentation on how to use canThis?
<HannahWolfe> Not really
<javorszky> mm
<HannahWolfe> it's a custom component
<HannahWolfe> there isn't much documentation for the internals atm :(
<javorszky> aite
<HannahWolfe> But essentially, canThis checks the current context (could be a user, could be an app, could be internal) and the object you give it against it's big map of who is allowed to do what
<HannahWolfe> The format is: canThis(context).action(object)
<HannahWolfe> ir rather: canThis(thing).doThisAction(toThis) ?
<javorszky> so in essence I could do
<javorszky> canThis(user).addRole("Editor")
<javorszky> (if I build it, need to expand the fixtures)
<HannahWolfe> canThis(options.context).edit.post(options.id)
<HannahWolfe> That's from the post api
<javorszky> oh, so... add.role(role.id) ?
<HannahWolfe> There's a subtle difference here in that the user isn't adding a role
<HannahWolfe> they're adding a user with that role
<HannahWolfe> or rather, they're creating a roles_users relation
<HannahWolfe> so I think it would be canThis(options.context).add.roleUser('Editor')
<HannahWolfe> but yes there is some complexity in that you'd need to expand the fixtures a bit, and possibly add some more logic
<HannahWolfe> I'm in the process of doing that for a few things, so there may be some better examples by the end of the day
<javorszky> yay :)