87e1622e6b
Prior to this commit many of the policy methods were of the form: ``` def create? edit? end ``` The above works, but introduces a place for code drift. We can shorten this to: ``` alias create? edit? ``` This helps keep the policy methods compact and scannable. All things authorization policy related should create narrow surface areas. By hand-crafting methods, it is easier for "slippage" to occur. Another advantage of `alias` is it's use is reflected in API documentation. With alias you need only write documentinig comments for one method and the doc generators will relate the alias and the original method. If you "hand craft" a method using explicit delegation, the API documentation won't pick up that two methods are aliases. Further, I believe we should be moving towards parity between the GET/POST/PUT methods that are related (e.g. the create/new pair and the update/edit pair). This is not the case, as we "silently" suspend folks. As we move through the [authorization work][1], we will start hiding the links/buttons when a user can't take the action. Related to #16483 and #16523 [1]:https://github.com/orgs/forem/projects/46
15 lines
479 B
Ruby
15 lines
479 B
Ruby
# ConsumerApp::FOREM_APP_PLATFORMS are all the platforms supported by every
|
|
# Forem instance by default. These are App Integrations that populate their
|
|
# credentials from ENV variables and are not meant to be modified by creators.
|
|
# Creator apps are those dynamically managed by creators in the Admin dashboard.
|
|
class ConsumerAppPolicy < ApplicationPolicy
|
|
def create?
|
|
@record.creator_app?
|
|
end
|
|
|
|
alias edit? create?
|
|
|
|
alias update? create?
|
|
|
|
alias destroy? create?
|
|
end
|