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

I still need to add a couple more scopes.



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!

CLA assistant check
All committers have signed the CLA.