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
9 lines
136 B
Ruby
9 lines
136 B
Ruby
class PinnedArticlePolicy < ApplicationPolicy
|
|
def show?
|
|
user&.any_admin?
|
|
end
|
|
|
|
alias update? show?
|
|
|
|
alias destroy? show?
|
|
end
|