Original work started for WPD and LGB, who wish to restrict flags
visibility in the UI based on admin_level. To support this change and
upcoming changes, `const.PERMS: string -> int` was created.
Potentially targetting a future design where Permissions is a proper
business object integrated with the User model; however, for now just
looking toward getting admin_level magic numbers centralized.
This commit applies PERMS to: create_hole, flags visibility in UI,
flag removal in UI & backend. Flag visibility in Comment & Submission
json_raw methods is unaffected to avoid needing a user object to
build the JSON.
The changes to helpers/get.py @ get_user(...) in a6b7fed2fc resulted
in `is_blocking` no longer being present on all User objects retrieved
via `get_user`. This triggered a latent identifier shadow where the
property method `User.is_blocking` on the User model caused checks for
blocks on objects retrieved via `get_user` to always return True.
Notably: when the get_user return value left `is_blocking` unset and
thus implied False, the following expression yielded True due to the
presence of the first-class function at the same identifier:
hasattr(user, 'is_blocking') and user.is_blocking
Proximate cause of 500 error on frontpage is that `Query` has no
such method `remove(...)`. Merely removing the line can't guarantee
identical logic, but I'm not quite clear if explicit removal from the
Query pseudo-collection is necessary, or if the final `pins` variable
after `Query.all()` will be appropriately filtered. It appears to
work right in practice, and the risk of expired pins persisting for
one extra pageload for only one user seems relatively minor.