Allow API to use membership permission system

[gabestein]

Motivation

• So developers can use the API internally for, e.g., creating new related pubs in the editor

Requirements

• Ability to resolve user capabilities from their login session instead of a token, and have the API work appropriately
• Ability to use the /site API from within core, rather than only using it externally.

Acceptance Criteria

• API should read login information using getLoginData if no bearer token is detected.
• The permission check should work the same as our internal permission checks work (e.g. inside of a server action). This is conditional on how #671 is implemented.
  • Roughly, you should be able to specify some priviliges on a route, and if the user that hits the route does not meet them, throw some error
  • Possibly we could specify these authorization requirements in a layer that is shared between e.g. server actions and the API, but for now duplicating it is fine.

[kalilsn]

does this issue also require us to filter out related pubs (e.g. in the api after #738) based on the permissions?

Ability to specify a permission, instead of a token, and have the API work appropriately

does this mean the caller specifies a permission? how should they do that?

[3mcd]

@kalilsn I just updated that requirement to say

Ability to resolve user capabilities from their login session instead of a token, and have the API work appropriately

I'm not sure if it's essential that this ticket covers the pub access control/filtering within the API. That portion could instead be covered by a separate ticket (I thought I created one for that but I can't find it). Thoughts @gabestein?

[kalilsn]

Thanks, that makes sense to me now!

After looking at the existing API endpoints, I think we have most of the capabilities we need. But I think we need one for viewCommunityPubTypes or maybe a general viewCommunityConfig that includes reading but not writing pub types, pub fields, and forms. What memberships should grant that capability?

I also think we'll need a viewRelatedPubs capability, although I'm a little fuzzy on precisely how that should work. It might be complicated to implement that, in the same way that checking authorization for the getMany endpoints (efficiently) might be complicated.

[3mcd]

@kalilsn

656 states that only community admins should be able to "edit community settings". It's not clear who can view pub types/fields. I think any community membership should grant you whatever capability you'd need to view pub types (and fields for that matter). But only community admins would be able to modify them.

I'm not totally sure if we need a specific capability for viewing related pubs. IMO related pubs should be filtered in the exact same way as the requested pub. That is, if you have the ability to see a pub, it should appear in any of its subject pubs' relationships.

CC @gabestein

[kalilsn]

In the old requirements of https://github.com/pubpub/platform/issues/595 it says that stage editors (and stage admins)

Can see and edit children/related pubs of Pubs in the stage, even if child/related Pubs are not in the stage

That's why I was thinking we'd need the viewRelatedPubs permission, though I see now that it can probably just use the permission we have for editing related pubs.

[gabestein]

I'm not sure if it's essential that this ticket covers the pub access control/filtering within the API

That's right. We're doing this so we can create related pubs from the editor, mainly, which will have the context of a user with existing permissions. If we need to add the ability to do that, we can later.

I'm not totally sure if we need a specific capability for viewing related pubs. IMO related pubs should be filtered in the exact same way as the requested pub. That is, if you have the ability to see a pub, it should appear in any of its subject pubs' relationships.

That's why I was thinking we'd need the viewRelatedPubs permission, though I see now that it can probably just use the permission we have for editing related pubs.

The reason I had specified some difference in contributor/editor permissions for viewing related Pubs (wherever they are in the community) is there's a common scenario where a Journal Article Pub is in the Under Review stage and has a related Review Pub that's in the "Returned By Reviewer" stage. In this instance, you wouldn't want a contributor to either the Journal Article Pub or the Review Pub to be able to see the other Pub! But you would want an editor of either to see either.