[5.x] Add `view other authors entries` permission

[aerni]

This PR aims to solve the longstanding community request to restrict users' view access to other authors' entries.

It adds a new view other authors {collection} entries permission and makes the existing author-related permissions its children. The updated policy is pretty straightforward. The tricky part was getting the query and filtering for the entries index listing and fieldtype working correctly. Thanks to @ryanmitchell for lending a hand.

This PR also dynamically changes the author field visibility and listing column depending on the user's permissions:

• The author field is hidden and the column removed from the index listing if the user has no view permission.
• The author field is read_only if the user has view permission
• The author field is visible if the user has edit permission

TODO:

• [ ] Add update script to add the new permission to existing roles

[AtmoFX]

This is a nice PR to see, I myself created https://github.com/statamic/ideas/issues/1333 to address it. There is 1 point I wanted to discuss before implementing it myself (though sadly, the statamic/ideas repo is getting a huge inactive backlog nowadays) and I do not see it addressed here.

I imagined there was a valid workflow where:

1. User A creates a draft entry.
2. Another user B manages the published state for that entry.
   But importantly, user B cannot edit the content of the entry created by A

This would require changing src/Auth/CorePermissions.php to place publish other authors {collection} entries as a:

• direct child of view other authors {collection} entries
• which means it would be a sibling of edit other authors {collection} entries, instead of a descendent

Could we perhaps have this discussion now? Or directly change the file in the PR to do this?

[aerni]

@AtmoFX I think that's a valid feature request. But it might be a little overkill to add it in this PR. I'd like to keep it as simple as possible to make review easier. I see your request as a bigger overhaul of how other authors' entries are treated. But I'll leave it up to the core team to decide.

[duncanmcclean]

It looks like some of the tests are failing. Are you able to take a look?

[aerni]

Yes, will do. Didn't get to it yet 👍🏻

[aerni]

I fixed the tests and also added an update script to add the appropriate permissions.

[Jubeki]

Good idea this PR, something I would like to use myself.

What happens if you configure the blueprint so that you can have multiple authors on the same entry? Would this still work as intended?

I would assume that all listed authors can view the entry, but not listed authors can not.

[aerni]

@Jubeki This PR doesn't tackle multiple authors. It only supports entries with a single author. It might be a good idea to add support for it will make things a lot more complicated. I'm not even sure it can be done, as the queries would have to look different depending if the author field is a string or array. Maybe query wizard @ryanmitchell can chip in here.

[ryanmitchell]

@aerni it should just be a case of doing ->where() for blueprints with max_items: 1 and ->orWhereIn() for blueprints with max_items not 1.... i.e.

->where(fn ($query) => $query->whereIn($blueprintsWithoutMaxItems1)->orWhere($blueprintsWithMaxItems1))

[aerni]

@Jubeki I've added support for multiple authors :-)

[aerni]

@duncanmcclean This is ready for review now 😃