Как адаптировать UX/UI под permissions

[@Sabubu]

У вас PermissionPipe зачем-то сделан на глобальных переменных и сам лезет в localStorage. Это нарушение принципа разделения ответственности.

На мой взгляд, тут pipe вообще не нужен и вы бессмысленно переусложнили код. pipe ведь предназначен для всякой мелочи вроде форматирования. Можно просто сделать объект UserRights, который хранит права текущего пользователя, передать его в шаблон, и там написать:

[disabled]="!userRights.can('todos_create')"

Получается и разделение ответственности, и инкапсуляция, и никто не лезет в глобальные переменные. И с таким подходом при желании извратиться, можно вывести, как будут форму видеть разные пользователи.

И декоратор тоже сделан неправильно. Он не должен лезть в глобальные переменные и тем более показывать алерты (используйте исключения). Вместо этого он должен просто объявлять нужные права доступа, а тот, кто вызывает обработчик, должен их проверить (или же: тот, кто вызывает, обязан передать UserRights, а декоратор их проверяет).

[@danduh]

Это всего лишь пример. И он не претендует на 100% правельность всех имплиментаций.
Посмотрите на GitHub, я не использую localStorage впринципе (не в компонентах/сервисах). Везде используется store, как единственный source of truth.

То же самое с декоратором, — это пример.

[@yarosroman]

Перевод конечно ужас, Сразу с переводчика на хабр? Приложения — аппликация, разрешения — где-то пермисионы, где-то permisions, есть же нормальный перевод этих слов. Ну и использование disabled вместо ngIf, может привести, к тому, что я просто через инспектор элементов уберу это свойство и все.

[@danduh]

Не перевод :). Точнее перевод того что было в голове.
Русский не мой основной язык и мне далеко не всегда удачно получается испльзовать правилно технические термины на другом языке кроме английского.

[@yarosroman]

Отдавайте тогда на корректировку кто русский знает, ибо очень тяжело читать такие тексты.

[@gubber]

Мы данную проблему решили исключительно серверными средствами. Мы с сервера для каждого пользователя(после авторизации) выдаём дерево путь->[компонент[->компонент]] и права действия над ними FULL/VIEW. Всё что приходит в дереве, отображается в интерфейсе с пришедшими ограничениями. То, что не пришло в списке разрешённых компонентов не загружается в DOM модель.
Да, это требует синхронизации интерфейса и сервера. Но она и так требуется при появлении нового функционала. Вопрос в том, кто инициатор синхронизации: разработчик клиента, который говорит о новых путях и компонентах в приложении или разработчик бекенда, который говорит о новых действиях.
При этом скрытие элементов или запрет действий на интерфейсе не означает, что проверку прав доступа не надо делать на стороне сервера.
В нашей схеме, к каждому компоненту может быть привязано действие, выполнение которого проверяется уже на стороне сервера, об этой части прав доступа интерфейс не знает вообще ни чего, но на стороне бекенда эти сущности синхронизованы.

[@kostiqueee]

У Вас в экспорте скрылся Стас :)

export permissions = [
    'todos_create',
    'todos_read', 
    'todos_update', 
    'todos_delete', 
    'stas'              // <= Вот тут
]