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
* Rename banned and comment_banned roles
* Add data update script to rename roles containing 'ban'
* Add named error for Suspended users
* Update unidiomatic method names
* Rename misc banned to suspended
* Apply suggestions from code review
Co-authored-by: Michael Kohl <me@citizen428.net>
* Add unit tests for suspended methods
This commit also adds TODO comments for removing banned and
comment_banned from the codebase after data update scripts have
successfully run on all of our Forems.
Co-authored-by: Michael Kohl <me@citizen428.net>
