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

(87) тут другая проблема, менеджеры начинают грузить клиенту в долг, тот нихрена не платит, а менеджеру похер, он отгрузил - значит молодец. Выставляешь лимиты в договорах, а что мешает менеджеру зайти и их поменять, либо вообще другой договор указать без ограничения по лимитам? Вот для этого и нужны права, каждый должен делать свое дело, а 1с по возможности ограничивать ошибки пользователей

(88) Ты путаешь внедрение и сопровождение

Если у тебя такие проблемы на внедрении- это нормально, решаются организационно
Если в сопровождении- то меняйте руководителя сопровождения

(86) ну ты протестировал на пете, убрал/добавил им роль и чета не учел

(92) Ну конечно речь про внедрение (тогда же все реализуют регламент с правами?). И как организационно решать проблемы типа - убрать доступ к договорам у менеджров, а потом выясняется что все таки определенной группе менеджеров нужно иметь возможность его редактировать? Пытать жеще, чтобы на обследовании все рассказали?

(84) бред какой-то. профили групп пользователей и прочие привелегии (ограничения) настраиваются один раз вдумчиво

а дальше все просто: регламент (все ходы записаны) на заведение нового раба (работягу) в программу или изменение прав

ну если админов (полные права) в системе больше одного, иногда проверять конфликты в наборе прав, чтобы у раба (работяги) не было больше прав, чем ему разрешено

(93) ну и бардак у вас там

(95) Ну да и код надо сразу писать без ошибок. Ну чтобы сразу работало, без отладки. Зачем на отладку время тратить?

(95) Ты такой смешной)

(0)Геня, все просто: профили групп пользователей и прочие привелегии (ограничения) настраиваются один раз вдумчиво

(95) Еще раз спасибо, развеселил, домой пора)

(94) Ну конечно речь про внедрение (тогда же все реализуют регламент с правами?).

Нет конечно, отсюда все проблемы

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

(98) на здоровье

"слабоумие и отвага". некогда думать, работу работать надо

В типовых действительно есть масса спорных моментов: почему при таком наборе прав это сделать можно или наоборот нельзя? Да, можно сделать доп. роль, в которой можно изменить доступы к объектам, сделать профили пользователей (как в УПП 1.3). При внедрении все работает, а потом начинается: вот этому дать это, этому то, но чтобы этот не видел то и т.п. И все твои профили идут в эротическое путешествие, так как появляется профиль_1, профиль_2 и т.п.

Вот в УПП считай сделали универсальную вещь с настройкой доступов, и что? Все равно все приходит рано или поздно в раздрай.

С датами запрета тоже еще вопрос: есть у всех одна дата запрета, и ты или человек отвечающий за нее знает какое значение она сейчас принимает. Вводим даты запрета для разных организаций, для каждого пользователя, да еще и динамическую и что? Пока не посмотришь в настройку ответить на вопрос "а какая же сейчас дата запрета стоит и кто мог исправить сегодня вот тот документ?" не можешь.

(101) кто мог исправить пишется отдельно
С датами запрета немного интереснее. Некоторые юзеры их могут менять и этот лог уже нигде не пишется

ну а то что права наступают только при запуске 1с да еще и обновлять конфунужно - это конечно недочет платформы

(101) поэтому надо забить на типовые права и писать свои сбоку.

(104) что делать с типовыми отчетами без "РАЗРЕШЕННЫЕ" планируешь?

(105) а разве такое еще осталось в типовых? Это ж нарушает 1С-совместимо. Найти их расширениями и обработать. Не думаю, что их много.

Вспоминаю времена, когда гений удивлялся почему нет ограничений в регистре остатков не по измерениям

(58) речь про УТ10

(66) крутой нейминг

(87) в рознице не работает. Там продавцы мегаушлые. Пример из практики - ввести акт списания на 1.1.1980 и списать товар к инвентаризации. гггг.

Я вот много с Розницей работаю в последнее время.
Там странная типовая логика - для работы с кассой нужен доступ к чеками и ПКО/РКО.
При этом кассир может их интерактивно завести из Списка, не только из РМК. Ну и отредактировать. Вопрос - зачем?
Вот поэтому типовым правам у меня доверия нет. Их явно писали люди, оторванные от реальной жизни.

(111) а откуда уверенность, что реальная жизнь только одна и это именно твоя версия жизни?!

(2) >или "Регистры правил"
И к ним "Регистры не до конца поправил" :-D

(112) ну наверное из-за тех случаев, когда реальная жизнь не укладывается в типовые (нередких).

(114) Реальная жизнь укладывается в типовые на 90%

(115) откуда цифирка? Из твоей версии реальной жизни? ггг

(116) Да, из текущего соотношения нового функционала при проекте внедрения

(115) только вот конфигурация достается из под деятелей, которые и на 50% не знают типовой функционал и начинают лепить велосипеды...Имхо, отсюда и основная масса проблем.

(115) эмммм. а 10% - это что? халф-лайф?

(118) еще б было бы внятное описание конфигурации...
но, похоже, сложность конфигураций достигла такого уровня, что описание сложнее написания.

(119) а 10% видимо отказались прогибаться под написанные "для всех" механизмы :)

(121) это не отменяет "реальности" той жизни
ну и, в общем, что плохого в том, что механизмы "для всех" работают не для каждого?

(121) Дописки, переписки, и прочие писки, не являются проблемой, так как можно проектировать свою архитектуру и спокойно ее сапортить, в большинстве случаев, ни один автор не заботится ни о документации- идите в код, там все документировано, ни описанием архитектуры системы

(123) дядь, это ты сейчас что сказал?

(124) Я сказал, что проще написать новое чем разбираться в типовом

Гений хоть об этом явно пишет.

Типовые права не подходят, там сложно да и разбираться надо, давай зафигачим свои с блеком и офименеджерами

(123) в молодости был у меня "учитель\наставник", так вот он всегда говорил "если код требует "описания\комментария" - это плохой код. Зачем писать сложный код, что бы потом в комментарии\описании написать как он работает?! Поэтому код я переписывал до тех пор пока с одного взглда на него - было бы понятно, что он делает.

(127) проблема же не в коде, проблема же понимания "почему он написан именно так"

(125) а...
ну да...
"то, что один человек построил - другой завсегда поломать сумеет!"©
-----------
но типовые пишут же, чьорт подьери, такие-же люди... если разве только "под веществами".

(125) нда...Был тут до меня прогер, который не знал как в 11 торговле резервы товаров отражаются и не долго думая запилил свой регистр с блекджеком и косяками. Люди пол года херачили резервы в его регистр, написано было множество отчетов с этим регистром, а потом понадобился другой типовой функционал, связанный с контролем отмененных срок, с товарами в пути и т.д. Тот прогер уже ушел. В итоге проще было использовать типовой механизм, а его регистр запихнуть куда подальше, чем дальше усугублять конфу и доламывать остальной типовой функционал. Я прост порой не понимаю таких решений, человек столько времени убил, ковырнул весь документооборот, чтобы добавить то, что итак есть с коробки...

(129) Ты не путай, у типовой конфы-задача отражения операций, там нет задачи производительности оператора, и прочее

(131) эммм. это как - "нет задачи производительности оператора"?
а как же "прогрес-сифная новая платформа", новый модный интерфейс такси, все эти котики и прочая, извиняюсь, асинхронность?

(130) вот в том и вопрос...
типовые ЖЖК - жуткое зрелище. итс - не лучше. (собственно, это те же ЖКК, только сбоку)

(133) ЖЖК? Жизнь железного коня?))

(132) по поводу производительности, тут скорее всего речь идет по заточку 1ски под конкретные нужды предприятия, обрезая все лишнее, чтобы пользователи не косячили и заполняя/создавая автоматом всю рутину, где это возможно

(134) ЖКК помнишь? ну а это - желто-желтые книжки

(136) по поводу итс не соглашусь, более менее внятно пишут, поиск работает, в общем не такой уж плохой портал и советы порой дельные

Гм, Вселенная меня услышала и сразу два клиента, один под УНФ, другой под УТ 10.3 запросили оценку ТЗ по универсальной системе прав доступа (думаю, правда без RLS на чтение). Так что, с божией помощью, универсальная система ПД увидит свет, надеюсь.

(137) Да, ИТС неплохая штука. Я про маркировку там многое почерпнул.

(126) дело не в сложности, дело в том, что они закрывают какой-то один участок и видение методистов. Они не универсальны. Если надо что-то свое добавить, типовые в мусорку и пишешь свои. Так не лучше ли сразу типовые в мусорку?

К тому же я органически не понимаю смысл использования RLS на запись. Думаю, это придурь методистов 1С - типа, раз есть механизм, надо использовать.

(138) вселенная прикалывается над тобой. у клиентов ограниченный бюджет, поэтому х@р им, а не  универсальная система ПД

(142) у меня разные клиенты есть

(141) есть доступ на функционал, есть на просмотр. Пересечение даёт уникальность прав доступа

(144) объясни по русски. Не догоняю.

2 кладовщика, каждый видит свой склад, набор прав идентичен

Это разделение к данным, разделение к функциям ты наверное лучше знаешь и без меня ;-)

Меня смущает в типовых, что я не могу сделать "роль" из пользовательского интерфейса, хотя доступ к объектам всей системы, у меня есть

Или например, 2 уровня пользователя- рук отдела продаж, и продажник, соответственно 2 профиля,

а вот групп видимости мы можем сделать в зависимости от менеджеров

И общую на просмотр всего пула контрагентов для рука

(146) я уже писал, что в RLS на изменение нет смысла. Оно видится осмысленным только адептам NoCODE и расстановкой галочек. В реальной жизни нежизнеспособно.

(151) Ты спросил, я ответил, спорить тут бессмысленно

а упарываться в код, когда права доступа должен раздавать админ, ну такое

(141) как предлагаешь делать ограничения на запись?

Проблем же нет сделать 1 пользователь, одна роль и все там редактировать, вопрос ценника на такие работы и стоимость обслуживания

но лучше всего понимание приходит когда будет бюджет с фикс прайсом на настройку прав по какой-нить организации человек на 50-100

(154) подпиской на события.

(152) я не понял твой ответ. Мотивировку

(157) Ждем решения, интересно будет посмотреть

логика такая - в RLS возможны только конструкции языка запросов, в подписке - языка программирования, т.е. шире возможностей.
Понятно что RLS на чтение должен быть быстрым, а вот в RLS на изменение нет ограничений по скорости. Поэтому по сути RLS на запись - это WORTHT PRACTICE, которые нам выдают за стандарты для подражания.

(159) дык вот не знаю, согласуют или нет. а так да, у одного клиента регистр правил уже на мази, буду делать.

(160) ну что на запись скорость не важна это конечно неправда.

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

Ну и кодом запись тоже чекается например в датах запрета

(15) надеюсь тебе за эти 4 месяца работы заплатили?

Такие простыни нужно внедрять так.
Закрываешь все и садишься с юзером и потихонечку открываешь.
Потом следующий

(162) Rilly? Why?

(163) Не вижу никакого смысла в дублировании

(167) потому что транзакции на запись должны быть как можно более короткими

(169) кому должны, прощают. Эта экономия на спичках выливается в дороговизну сопровождения этого механизма.

(169) Погоди, БРО, а что ПередЗаписью - это уже транзакция? гыгыгыыг, опять соврамши.

(171) событие объекта ПередЗаписью выполняется в транзакции. Ну хватит уже позориться

(172) Ну это уже косяк платформы. Позор тут не при чем. Должно быть событие контроля разрешения записи. В любом случае, экономия на спичках. Потому что приложение для автоматизировано-роботизированного склада пишется так же, как для оптового. Это идиотизм. Если в конторе проводят одну реализацию в 5 минут, тут время проверки не критично.

(173) с тобой забыли посоветоваться разработчики платформы, где им транзакцию начинать
в любом непонятном случае ты пишешь "экономия на спичках" и "из пушки по воробьям"
1С стоит не только в ларьках и окно "Конфликт блокировок при выполнении транзакции" это к сожалению не мифический единорог

(174) не оправдывайся, твои оправдания имеют бледный вид

(174) модуль проведения работает на порядок дольше, чем перед записью, отсюда и конфликт блокировок, например

(174) Кстати, надо предложить в стандарты 1с:совместимо чтобы модуль проведения делался только на запросах, это ж сэкономит время записи, дыа? давай доведем идиотизм до абсурда

Кстати, а в ПередЗаписью формы транзакция начинается или еще нет. Тогда можно в ПередЗаписи формы рассчитать есть доступ или нет и передать в ДополнительныеСвойства. Если такое разрешение пришло, оно не рассчитывается. Т.е. из формы будет проводиться быстрее. Но думаю, там экономия будет 1%, смысла городить нет. Как раз "на спичках". Ибо модуль проведения намного затратнее

(175) (176) (177) (178) пока оправдываешься в незнании механизмов платформы ты

(168) как раз таки дублирования нет

(179) я не про незнание, а про рацио. Не выгораживай платформу. И?

(181) ты с темы не уходи - не знал про транзакции - честно признай, а незнание механизмов транзакций может привести к серьезным архитектурным ошибкам

(182) не щнал нюансов, а не механизмов. Теперь ответь про свой базар за скорость

(183) базар-вокзал у тебя в уютненьком, где ты комменты редактирует

А рассказывать тебе про проблемы конкурирующих транзакций в многопользовательской системе бесплатно не желаю

(184) ага, слился, оно и понятно. Надо статью написать, а то не всем понятно, что рлс на запись это идиотизм

(184) ты если бесплатно не хочешь аргументировать свою позицию, то бесплатно не вступай в споры, ггг

Геня, ты бы хотя бы не гыгыкал тупо, когда тебе подсказывают направление, в котором копать надо. Мало того, что демонстрируешь свою некомпетентность, так ещё и ведёшь себя как подросток-дебил.

(185) давай, давай
Только комментарии к ней не редактируй. Если сможешь

(185) Читать не буду, но осуждаю

(187) мне не подсказывают, 0 бит. Я буквоедство не понимаю.
Если есть что сказать, всегда говорю, а не делаю умный вид