Editing books where you're an author

So this is similar to the DSLoid thing that I was thinking about, i.e. when you look at an authsome mode with its nested ifs https://gitlab.coko.foundation/pubsweet/pubsweet/blob/master/packages/server/test/helpers/authsome_mode.js#L58 and loops https://gitlab.coko.foundation/pubsweet/pubsweet/blob/master/packages/server/test/helpers/authsome_mode.js#L14 a lot of this could be made more readable with some constraints. Specifically the above could be expressed as some form of :

Collections:
  unauthenticated:
    GET: 
     filter: (collections) => collections.filter(collection => collection.published)
  authenticated:
    extends: unauthenticated
  teamMembers: 
    POST: true
    PATCH: true

You can abstract this up or down depending on the need, but there are a lot of common authorization patterns across apps that could be abstracted away (i.e. team membership, filtering).

In terms of your proposal, which looks to me to be a kind of an abstraction of the current team-based system, I'll try to walk through a few examples and see if I get it.

Editing books where you're an author

We have the following role config

Author:
  capabilities:
    - edit book

What links the book to the author? Some kind of role table? Like you say, currently this is basically teams and team memberships.

id	role	type	objectId
1	author	book	someBookId

So when can(user, 'edit', book) comes in, it's checked if user is author on the book, and if the author role's capabilities include edit.

Say you've done your edits, and the book is now in the final phases of production, the copy editor is looking through it.

Copyeditor:
  capabilities:
    - edit book

At this point the Author shouldn't be able to edit the book. Where would this conditional link be described? Currently this kind of thing is evaluated in the authsome mode, which is app-level code, which is also what you're suggesting, but do you have a different place in mind for storing these state-based conditionals?

The state machine is an interesting idea, and probably generally applicable to documents with state, but I'm not sure it ties directly to authorization. Feels like the question asked there is 'what can happen to a document/object', more than 'who can do the thing'. It's in the same spirit (in the 'what can happen full stop' way), but these two types of questions can be completely disconnected in principle.

My $4 for now. I'll give it more thought and work through another example.

What links the book to the author?

Current team structure would work but there might be a better way which combines it with general roles. i.e. user has a roles array like [{role:'operations'},{role:'author',object:123}]

Where would this conditional link be described?

I was thinking that these could be different actions depending on the current state. E.g. make decision vs change decision, edit draft book vs edit finalised book. I can also see some kind of hooks system to allow more complex logic to be added but they should only be used in exceptional circumstances to keep things simple.