FEATURE: Add scopes to API keys (PR #9844)

I still need to add a couple more scopes.

Screenshots:

GitHub

Do we need to ensure that certain columns cannot be null?

We probably need an index on this column.

What values can resource be? If it is from a fixed set, it may be more efficient to store an integer representation rather than a string. I think it’ll be the same for action as well.

dig may return nil so calling nil.to_a will blow up.

Do we need any validations on this model?

I usually prefer to not use generic assertion like not_to be_empty because this test will pass even if data['scopes'] contains random data.

I suspect this gets tricky because plugins are allowed to contribute new resources/scopes, so we can’t pre-allocate consistent integer ids. I think a string is more flexible in this case. This table is never going to a be a performance bottleneck, so I think we can take the hit.

We should make sure that these mappings get removed when plugins are disabled. The easiest way is probably to use a filtered_register in the DiscoursePluginRegistry.

Can we flip this round, so that it sounds a bit more scary. Maybe “Global Key (allows all actions)” with a checkbox?

Can we make it possible for action to be an array? So that later we have the option of making topics:write support multiple actions?

nil.to_a will return an empty array.

Ah icic . Today I learned something new

@tgxworld @davidtaylorhq Thanks for the review. I have addressed all the comments, feel free to take another look!