пришел как то к нам чувак, новенький, хотя с виду старенький (35+), и сразу же меня спросил - а как у вас тут к бухлу относятся? - всмысле? - ну, нам на прошлой работе шеф говорил - делайте что хотите, можете даже бухать и спать тут, главное чтобы работу сделали

кмк пить на работе вообще зло

мы в кабинете как-то вискарь на ковер пролили

потом коллеги заходили, говорили: "опять бухаете?"

воняло пиздец

хорошо хоть не ковролин который прибит к полу

в прошлом офисе настолько был захуйкан всем подряд что перестилали

хотя кстати после работы, под вечер, сабантуи всетаки бывают, по случаю др. пробкам от брюта уже нет места на серверной стойке😂

У нас до ковида одно время была "пивная пятница",
когда мы в ~14:00 ходили в бар - обедали и выпивали по 0.5 крафтового, а потом обратно работать.
Помню еще непьющая qa слегка бомбила что от нас алкоголем пахнет 😌

у нас традиция по понедельникам и пятницам скрам созвоны по 2.5 часа

Эх, а мы периодически на настолки собирались с алкоголем по вечерам и сидели до полуночи, а то и дольше.

у нас тоже ктото играет иногда, но мне не зашли настолки, да и вообще любая “мафия просыпается”

в крокодила играли еще вроде, подпивши прикольно канеш, а без алко нет😀

Не, по мафии я тоже не фанат. Я об играх, где игровая карта есть, или хотя бы многое вокруг игровых механик крутится, а не вокруг рандомных догадок (манчкин, цитадели, ужасы аркхама, мор: утопия, колонизаторы, ну короче я надеюсь направление ясно)

Господа, концептуальный вопрос. Не знаю где ещё спросить. Вот сделал ты API, пусть крудятину-рестуху. Сделал там модельки красивые типа User(id, name, email). А вот как бы теперь так сделать, чтобы email был виден не только лишь всем? Ну там, пользователь сам свои данные видит полностью, а чужие - только если у него права какие-нибудь есть. Вот это вот вообще как-нибудь общепринято называется/решается?

емнип рест не запрещает делать разный набор видимых данных для разных юзеров

вполне легально не отдавать user.email потому что "ты кто такой вообще"
в целом это все решается различными access control техниками

если попроще - rbac/abac
rbac - роли юзерам раздает админ, доступы зашиты в исходном коде, типа если есть роль - доступ есть
abac - голосование. в исходном коде зашиты возможные действия, типа "можно видет емайл юзера", а доступ либо вычисляется на месте по атрибутам сущности(сущностей) либо хранится в базе (админится администратором). голосовалка может быть типа "если запрашивающий user в той же группе что и target user - показать емайл", т.е. любые условия которые может реализовать прогер.
есть более сложные, где уже бизнес правила менеджатся через недо-языки для бизнес-аналитиков (user-driven), есть целые системы для записи этих штук в хмл, но не трогал такое

Вот я сейчас порезал себе представления на группы атрибутов и связал их с соответствующими правами на просмотр. Получилось, что сборка ответа происходит функцией (permissions, entity) -> response. И, в целом, оно работает и даже не доставляет проблем, но остаётся вопрос "а можно-ли лучше" и "что там у других". Судя по всему, у других тоже самое.

если упороться то можно дойти до аспектно-ориентированого подхода.
раздаешь над полями в классе @AccessControl(ROLE_ADMIN) или @AccessControl(USER_EMAIL_VISIBILITY_ACTION)
дальше в ебенях мидлваре кто то у тебя парсит аннотации и собирает AccessDecision движок - и по каждой проперти он решит пропускать ли значение либо заменить на null
но такая хрень должна быть в толстых фреймворках, наверняка в спринге есть аналогичная штука