В дате запрета включено применение дат по пользователям, разделам учета и по объектам.
В каком порядке они применяются, с какой приоритетностью? Если общая дата разрешает, а более детальная запрещает - какой результат? А если наоборот, общая дата запрещает, а пользователю разрешено?

Есть ли внятная документация по логике установки и применения дат запрета редактирования в КА2.4? А то непонятно ничего...

Вот что нашел в общих модулях.

    // Приоритеты дат запрета изменения.
    // 1. Для раздела, объекта и пользователя.
    // 2. Для раздела, объекта и группы пользователей.
    // 3. Для раздела, объекта и любого пользователя.
    // 4. Для раздела, любого объекта (объект = раздел) и пользователя.
    // 5. Для раздела, любого объекта (объект = раздел) и группы пользователей.
    // 6. Для раздела, любого объекта (объект = раздел) и любого пользователя.
    // 7. Для любого раздела (пустой раздел), любого объекта (объект = раздел) и пользователя.
    // 8. Для любого раздела (пустой раздел), любого объекта (объект = раздел) и группы пользователей.
    // 9. Для любого раздела (пустой раздел), любого объекта (объект = раздел) и любого пользователя.

Циферки - приоритет. Запятые - объединение.

Более низкий приоритет не действует, если подходит более высокий

(3) То есть, применяется более детальное ограничение, если есть еще менее детальное?

(4) Да, если оно подходит по комбинации пользователя, раздела и объекта. Например, задан отлуп Пупкину и общая дата запрета. Для Пупкина будет действовать отлуп для Пупкина безотносительно того, какая там общая дата запрета установлена.

Там же запрос есть - его посмотреть достаточно

По факту получается, что если у пользователя не указаны разделы, но указано своё ограничение - то применяется общее ограничение для всех пользователей, если там разделы указаны. А ограничение пользователя в этом случае игнорируется. Как-то не очень это удобно...

(7) "если у пользователя не указаны разделы, но указано своё ограничение - то применяется общее ограничение для всех пользователей, если там разделы указаны" // Да. С циферками (приоритетами) приходится считаться.

(8) Получается, что для "суперпользователей", которым нужно дать доступ всегда и везде, придется явно задавать ограничения по разделам, если для "всех пользователей" эти ограничения тоже заданы по разделам. А не так чтобы поставить пользователю один раз "без ограничений" и всё бы работало.

(9) Кажется так, но ты проверь на всякий случай - вдруг есть какая-нибудь удобная лазейка для реализации такого "суперпользователя".

(10) Да попробовал, в том и дело, что только так получается. Неинтуитивный интерфейс там вообще, а документации по сути нет. А главбух удивляется, чего это продажники правят документы задним числом..

(11) Ну это дело привычки, наверное. В типовых на ОФ было по-другому - там точечный пользователь в датах запрета имел приоритет всегда. Но и не было такой детальной настройки. А сейчас точечный отлуп имеет приоритет над "для всех пользователей" только в пределах уровня детализации, коих как видим три (раздел указан + объект указан, раздел указан + объект не указан, раздел не указан + объект не указан).

(12) Еще неудобно что нельзя просто задать дату в разрезе организаций. Только с разделами в нагрузку... Всё-таки жесткий приоритет не очень удобен, лучше было бы, чтобы его можно было задавать самому.

Еще не определено поведение, когда указаны разные даты для двух групп, если пользователь входит в обе.

(14) Проверь четыре возможных комбинации (дата1 группы1, дата2 группы2 и дата проверяемого объекта) и отпишись, сделай доброе дело)

(15) Неопределено, я же говорю. Ни в одном запросе к регистру нет УПОРЯДОЧИТЬ ПО, так что как СУБД захочет так и будет)

Так может до принятия решения там упорядочивание кодом есть

(9) почему ты не можешь для пользователя назначить по разделам доступ на все?

(18) Да всё можно, вопрос удобства и эргономики.

(18) (19) Не только удобства: появится в очередном релизе новый раздел учета и в системе никак нельзя, получается, один раз задать "этому пользователю болт по всем разделам безотносительно того, есть они сейчас в системе или появятся в будущем". Придется задавать два ограничения - второе из группы 7-9.