Hey @stof ! Would you mind to elaborate why enums would be bad fit for permissions ?

First let me make my case why I believe permissions to be pretty much a closed list.
I think no one generates new permissions on the fly right? If you don't generate them or do some weird magic with creating permissions by joining strings then permissions seems like pretty closed list to me.

The most likely use case now is that they are declared as public constants in some permission class. Afaik adding public constants is not possible in php so again it looks to me like we are storing them as a closed list of options.
And what is a perfect fit for closed list of options? Exactly, enums.

The current way of storing them has one disadvantage - no typesafety.

Here is a real bug in production I had to figure out recently, that was caused because our permissions were stored as constants and therefore were not typesafe:
We have an administration that manages different entities. Two of them are Questionnaire and FormalRequest
both of these entities can be exported to csv.
Questionnaires existed first and the permission to export to csv was string canExportToCsv. Later FormalRequests were added. I think you know where this is going. The permission to export FormalRequest to csv was also string canExportToCsv.
This caused both completely unrelated voters to vote on the same permissions and one would always forbid the action. The exporting had no associated subject, it was a global action, so there was no $subject to check support for.

Had the permissions been enums this couldn't happen.

Uh oh!

BackedEnum support for voters #46312

Description

Description

Example

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions