Решение разработчика в зависимости от опыта работы. Как ограничить отображаемый пользователю список и ничего не потерять

25.02.20

Администрирование - Роли и права

Решение разработчика в зависимости от опыта работы. Ограничение отображаемого пользователю списка без применения RLS.

Скачать файлы

Наименование Файл Версия Размер
Расширение для Управление IT-отделом 8, редакция 3.1 (3.1.3.15) (softonit.ru). Карточки номенклатуры
.cfe 16,32Kb
0
.cfe 16,32Kb Скачать

К этой публикации меня подтолкнула зависимость кода разработчика от опыта.

Вернее, обсуждение данной темы... 

С одной стороны оптимальное решение поставленной задачи и код, решающий её, это тот самый "бриллиант" и стремление к достижению "совершенной огранки" похвально.

И хорошо, что его нет, если бы этот "бриллиант" существовал, то все бы его "зазубрили" в начальной школе, и обсуждения бы не было.

Такие "технологические" обсуждения нужны и интересны, но...всё-таки отличие Junior'а от Oldschool'а в большей степени сказывается в подходе к решению других задач.

Собственно,  второй побудительной причиной к написанию, оказалась случайно  возникшая во время "неудачной" стажировки ниже описанная постановка задачи.

В "историческом прошлом" приходилось "решать" множество "непонятных мне хотелок" по 1С - от "добавления 5-ти знаков после запятой в цену" до печатной формы "Накладной на отпуск материалов на сторону (М-15)" для документа "Перемещение товаров", который из Управления торговлей потом должен перегрузиться в Бухгалтерию.

И спорить с инициатором в обоих случаях было бесполезно.

Оправдание им, только недопонимание "экономическими" специалистами сути их "хотелок", в первом случае упорствование в своём желании перенести свои "экселевские" достижения на другую "почву", без оглядки на очевидное, что у нас копейки, в США центы, и меньше просто не бывает.

Во-втором, непонимании логики применения того или иного вида документа, "неосознании" того, что М-15 подразумевает передачу материальных ценностей из одного предприятия в другое, а Перемещение как документ нет.

Вред от реализации таких "хотелок" не очень большой, со знаками после запятой вообще минимальный, так неудобство. 

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

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

 

Постановка задачи:

В компании используется "Управление IT-отделом 8", учёт ведётся по множеству организаций и множеству складов - территориально-распределенное торговое оборудование.

Есть проблема - стандартно для справочника "Карточки номенклатуры" никаких ограничений нет, каждый сотрудник видит все карточки.

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

 

Начинающий (Junior) и Уже с опытом (Middle) прочитав такую постановку сразу примутся за дело - ведь "ограничить" - это же "чистый" RLS.
 
Делов-то, добавим в карточку реквизит "Склад", сделаем его обязательным и задача нами решена. На вопрос - оператор будет его всегда выбирать? - сразу без раздумий звучит ответ - нет, мы его возьмём и заполним из настроек пользователя. Никаких сомнений - результат достигнут!
 
Ведущий разработчик (Senior), Эксперт (Expert) и тем более Огромный опыт (Oldschool) должны и поступят иначе. Зададут себе вопросы, чтобы оценить  последствия от выбора  того или иного варианта решения?
 
Первый вопрос - зачем карточки номенклатуры в конфигурации? Какова цель их применения?
 
 Описание справочника из помощи

Вроде всё однозначно - это номенклатура, обладающая уникальными свойствами, единичные экземпляры.

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

Второй вопрос - как часто карточка используется в конфигурации с "архитектурной" точки зрения. Поиск ссылок на объект поможет в этом.

Анализ показывает, что данный справочник связан с другими объектами: справочниками Местоположения и Шаблоны заданий, документами Задание, Изменение показателей оборудования, Инвентаризация, Наряд на работы, Начало обслуживания, Окончание обслуживания, Перемещение, Поступление, Продажа, Разбиение комплектации, Сборка комплектации, Списание, Учет денежных средств, регистрах сведений Бюджеты, Состояние карточек номенклатуры, Статусы карточек номенклатуры, Характеристики, Штрихкоды номенклатуры и в регистрах накопления Закупки, Комплектация, Обслуживание контрагентами, Остатки, Показатели оборудования, Продажи, Ремонты.

Как видим степень "вовлеченности" карточки в "архитектуру" значительна. Добавление нового реквизита возможно приведёт к необходимости изменений где-то ещё.
 
Третий вопрос - какова может быть "история жизни" в базе конкретного экземпляра карточки? 
 
Обсудим "Автомобиль ВАЗ 2107 гос. номер: К117ВТ 123 RUS" из справки.
Когда-то он нами был куплен и определен на место хранения "Склад 1".
Эксплуатировался ежедневно, и в какой-то момент возникла необходимость в ремонте.
У нас крупная организация и есть подразделение, которое выполнит такой ремонт - машина поехала туда и через некоторое время вернулась на своё первоначальное место хранения. Через какое-то время головное руководство приняло решение купить нам новый автомобиль, а этот переместить в другой филиал, где через несколько лет он был продан или списан.
"Жизненный путь" может быть долгим и местонахождений объекта в течении этого цикла может быть множество.
 
 
Теперь давайте вернёмся к нашим действующим лицам, к тем кто уже решил поставленную задачу и не видит в ней никакой сложности.
 
Зададим им вопрос, который обязательно зададут те, кто будет эксплуатировать базу после доработки.
 
Что нужно сделать с реквизитом карточки "Склад", когда машина поехала на ремонт?
Поменять на место ремонта, но тогда здесь карточка из списка "пропадёт".
Оставить как есть, но тогда она в ремонтном подразделении не "появится".
 
Значит и тем, и тем дать доступ к этим складам.  Ремонтное подразделение конечно может желать видеть с чем им придётся иметь дело. А зачем lдругим видеть всё, что оприходовано в ремонтном подразделении? 
 
А если её передали в другой филиал?
Тогда точно поменять "Склад" на новое место. А что тогда мы увидим в документе первоначального поступления её в организацию?
 
То есть, выбрав такое решение, "бизнес" получит "потери":
 
Про автомобиль переданный в ремонт кто-то может "забыть", а ремонтники по этой причине будут не торопиться его вернуть. Никто же не торопит с возвратом.
 
Открыв документ из прошлого окажемся в ситуации - искать бумажные версии документов в которых можно найти, что же было в них - в базе же, там где должна быть карточка -"белое пятно".
 

Вывод: Решение лежащее на поверхности - добавление реквизита и RLS - приведёт к новым проблемам.

 

А как же решать:

Найти то, единственное в данном случае место, в которое нужно внести изменения.

Локализуем код, который будем править, в форме списка "Карточки номенклатуры" используется динамический список

 
 с произвольным запросом

 

Вот его-то и надо исправить для достижения требуемого результата.

Сразу заметим, в запросе левое соединение с регистром "Остатки", который участвует в RLS, и уже одно исправление левого соединения на внутреннее ограничит список карточками номенклатуры, которые есть на остатках на доступных пользователю группах доступа мест хранения. И, собственно, это уже практически тот же результат, что и у "начинающих" программистов.

Но для полноценного решения этого недостаточно.

Следующими доступными пользователю карточками должны стать те, которые в истории "побывали" на доступных пользователю местах хранения. На форме списка они выделяются красным цветом шрифта.

И, наконец, наши созданные, но ещё не использованные карточки.

Собственно, всё это в прилагаемом файле - технология, доступная всем от .Junior'а до Oldschool'а.

Лишь пару примечаний:

В динамическом запросе используется основная таблица "Справочник.КарточкиНоменклатуры", поэтому изменяя запрос можно получить "Обнаружено дублирование...", если не обеспечить одну запись справочника единственной записью при дополнении данных соединением.

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

 

Работа расширения проверена на Управление IT-отделом 8, редакция 3.1 (3.1.3.15) (softonit.ru).

В заключение:

Надеюсь, данная публикация поможет начинающим в деле становления по пути к экспертам.

И всем тем, кто "ощущает" себя уже "сеньором", но всё ещё выбирает "добавить Склад".

 

Мои публикации:

Код для поиска номенклатуры в конфигурациях 1С. Использование мнемоники по первым буквам как вариант применения

Анализ оборачиваемости для УТ 11.4

RLS список ограничение

См. также

SALE! 20%

Infostart Toolkit: Инструменты разработчика 1С 8.3 на управляемых формах

Инструментарий разработчика Роли и права Запросы СКД Платформа 1С v8.3 Управляемые формы Запросы Система компоновки данных Конфигурации 1cv8 Платные (руб)

Набор инструментов программиста и специалиста 1С для всех конфигураций на управляемых формах. В состав входят инструменты: Консоль запросов, Консоль СКД, Консоль кода, Редактор объекта, Анализ прав доступа, Метаданные, Поиск ссылок, Сравнение объектов, Все функции, Подписки на события и др. Редактор запросов и кода с раскраской и контекстной подсказкой. Доработанный конструктор запросов тонкого клиента. Продукт хорошо оптимизирован и обладает самым широким функционалом среди всех инструментов, представленных на рынке.

13000 10400 руб.

02.09.2020    122275    673    389    

715

Автоподбор ролей для профилей и групп доступа в любых типовых базах 1С УТ 11, КА 2, ERP2, Розница 2/3, УНФ 16/3, БП 3, ЗУП 3 и подобных (УФ, Платформа 8.3.14+)

Инструменты администратора БД Роли и права 8.3.14 1С:Розница 2 1С:Управление нашей фирмой 1.6 1С:Документооборот 1С:Зарплата и кадры государственного учреждения 3 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х 1С:Зарплата и Управление Персоналом 3.x 1С:Управление нашей фирмой 3.0 1С:Розница 3.0 Платные (руб)

Роли… Вы тратите много времени и сил на подбор ролей среди около 2400 в ERP или 1500 в Рознице 2, пытаясь понять какими правами они обладают? Вы все время смотрите права в конфигураторе или отчетах чтоб создать нормальные профили доступа? Вы хотите наглядно видеть какие права дает профиль и редактировать все в простом виде? А может хотите просто указать подсистему и дать права на просмотр и добавление на объекты и не лезть в дебри прав и чтоб обработка сама подобрала нужные роли? Все это теперь стало возможно! Обновление от 15.12.2023, версия 1.1.

12000 руб.

06.12.2023    2990    15    1    

34

Запрет доступа к данным по зарплате для БП 3.0 и КА 2.5

Зарплата Роли и права Платформа 1С v8.3 Бухгалтерский учет Управление правами 1С:Бухгалтерия 3.0 1С:Комплексная автоматизация 2.х Молдова Россия Казахстан Бухгалтерский учет Платные (руб)

Расширение позволяет максимально полно ограничить доступ пользователей к данным по заработной плате, а именно закрывает доступ к документам начисления и выплаты заработной платы, не позволяет просматривать бухгалтерские отчеты по счету учета зарплаты а также убирает зарплатные проводки из журнала проводок. Расширение запрещает просматривать платежные документы на выплату зарплаты, так же не доступны регламентные отчеты в ПФР и ИФНС. Расширение предлагает готовые настроенные профили "Бухгалтер без зарплаты", "Только просмотр без зарплаты".

5700 руб.

27.05.2021    32752    204    89    

165

SALE! 20%

Infostart УДиФ: Управление данными и формами

Инструменты администратора БД Инструментарий разработчика Роли и права Платформа 1С v8.3 Конфигурации 1cv8 Россия Платные (руб)

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

10000 8000 руб.

10.11.2023    3570    11    1    

34

Расширение для разграничения доступа к контрагентам и обработка для группового назначения доступа для Бухгалтерии (RLS) 3.0.143.42

Роли и права Платформа 1С v8.3 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Платные (руб)

Расширение предназначено для Бухгалтерии предприятия (версии ПРОФ и КОРП). Типовая конфигурация остается на поддержке. С помощью расширения менеджер по продажам будет иметь доступ к контрагентам и списку их документов только в случае, если он является для них ответственным. Пользователю с полными правами также доступна обработка «Назначение ответственных» для группового добавления/удаления ответственного в карточке контрагента. Есть версия данного расширения для клиентов Fresh - в магазине расширений (Fresh)

9360 руб.

14.09.2022    5761    7    4    

9

Роли для кладовщика

Логистика, склад и ТМЦ Роли и права Платформа 1С v8.3 Бухгалтерский учет Управление правами 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Управленческий учет Платные (руб)

Расширение, которое позволяет использовать отдельные роли для доступа к складским документам, для доступа к документам раздела "Производство" и для доступа к документам раздела "Покупки".

2520 руб.

21.05.2019    1692315    552    192    

133

Универсальная система оповещений в базе или по почте по произвольным условиям, расписанием, ролям и пользователям (Расширение / конфигурация для платформ 8.3.6+, для ЛЮБЫХ баз)

Роли и права Платформа 1С v8.3 Конфигурации 1cv8 1С:Управление торговлей 11 Платные (руб)

Данная система разработана как альтернатива стандартной системе напоминаний. Но имеет ряд существенных преимуществ: отображение в базе или с отправкой по почте, свое расписание, возможность фильтрации по ролям и пользователям, формирование своих запросов и макетов, шаблоны писем, работа в фоне. А также может блокировать работу пользователей при заданных условиях. Может работать в составе любой конфигурации. Имеется справка с описанием возможностей. (Обновление от 20.02.2024, версия 2.2, расширение)

18000 руб.

29.11.2019    24695    13    8    

33
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. VmvLer 25.02.20 10:41 Сейчас в теме
Заголовок дает претензию на то, что в теме будет понятный сравнительный анализ вариантов решения
с четкой детализаций разниц.

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

Полагаю, пора уже в форме создать ветку "О боже, как я прекрасен".
В эту ветку перемещать подобные темы. Тогда, в кофе-тайме можно будет
поломать мозг о том, что хотел сказать автор и каков его мир.

Остальные проф темы будут в своих профильных разделах.
paybaseme; Ta_Da; user764477; Diversus; +4 Ответить
2. user633166 12 25.02.20 11:05 Сейчас в теме
(1) Ваше право написать лучше, детальней, прозрачней, детальней, удобней...

А я вашу критику приму к сведению и буду стараться изложить следующий раз понятнее.
3. Diversus 2307 25.02.20 11:10 Сейчас в теме
А ваше решение действительно "senior-ское"?
Вы используете в запросе левое-соединение с подзапросом к регистру остатков.
Но вот тут: Типичные причины неоптимальной работы запросов и методы оптимизации говорят, что это не правильно.
user764477; wowik; +2 Ответить
5. user633166 12 25.02.20 14:56 Сейчас в теме
(3) Отвечу так - если я правильно понял то вы руководствуетесь данной фразой ИТС "Оптимизатор сервера СУБД (независимо от того, какую СУБД вы используете) не всегда может правильно оптимизировать подобный запрос. В данном случае, проблемой для оптимизатора является выбор правильного способа соединения. Существуют несколько алгоритмов соединения двух выборок. Выбор того или иного алгоритма зависит от того, сколько записей будет содержаться в одной и в другой выборке. В том случае, если вы соединяете две физические таблицы, СУБД может легко определить объем обоих выборок на основании имеющейся статистики. Если же одна из соединямых выборок представляет собой подзапрос, то понять, какое количество записей она вернет, становится очень сложно. В этом случае СУБД может ошибиться с выбором плана, что приведет к катастрофическому падению производительности запроса."

Два момента:
Дата публикации 07.12.2015 Типичные причины неоптимальной работы запросов и методы оптимизации - считаете, что производители СУБД 5 лет не работали.
И второй, я не пытаюсь реализовать "оптимальное решение", поскольку "Выбор того или иного алгоритма зависит от того, сколько записей будет содержаться в одной и в другой выборке."
4. Liogon 8 25.02.20 14:36 Сейчас в теме
А на каком уровне у разработчика возникает вопросы типа "А какую проблему вы хотите решить этой доработкой?" и "Почему это является проблемой?" Из контекста постановки я предполагаю, что пользователям тяжело работать с большим списком данных, большая часть которых для него вообще не актуальна. Но тогда возникает другой вопрос. "Что такого у пользователя произошло в жизни, что ему этот список потребовался?" Ответ будет лежать в плоскости бизнес-процессов, а не конфигурации. Но оттуда уже будет ясно, что разумнее будет не переделывать динамический список и крутить РЛС, а сделать отчёт, который покажет только нужные карточки. Либо настроить один из типовых. Либо сделать форму подбора в документ. И с точки зрения поддержки это будет более "удобное решение". Все изменения лежат на поверхности. А то и вообще в справочнике доп.обработки.
6. user633166 12 25.02.20 15:03 Сейчас в теме
(4) Вы правильно понимаете, что у пользователя проблема работы со большим списком карточек номенклатуры, в общей массе не актуальных для него. И представьте себе, он зачем-то этот список открывает. Вероятно у него такой бизнес-процесс. Тогда вопрос к Вам - отключить у пользователя возможность открыть такой список? А в форме подбора(выбора) Вы что собираетесь поменять, чтобы ограничить список?
7. Liogon 8 25.02.20 15:17 Сейчас в теме
(6)
И представьте себе, он зачем-то этот список открывает. Вероятно у него такой бизнес-процесс.


Так вот в этом то и вся суть. Зачем-то это зачем? Тут, навскидку, есть 2 варианта:
1) Это форма выбора, а не форма списка. Соответственно этот список открылся из какой-то другой формы.
2) Если это форма списка, значит пользователь какие-то действия может делать либо только в ней, либо оттуда проваливается в форму элемента, и какие-то действия совершает там. Такие вещи решаются созданием АРМ, которое в общем случае можно просто приставить к основной конфигурации, не изменяя логику её работы.


(6)
отключить у пользователя возможность открыть такой список?


Лишить его причин туда заходить и он сам перестанет это делать. К тому же наверняка уже есть, или появится в обозримом будущем категория пользователей, которым нужен этот список целиком.
8. user633166 12 25.02.20 15:54 Сейчас в теме
(7) "Хотелка" возникла по форме списка, рассуждения по теме как сделать "хорошо" пользователю, чтобы он не просил эту "хотелку" - сделать вместо этого ему АРМ, не тема этой публикации, я просто продемонстрировал разные подходы к решению.
Категория пользователей с административными правами на весь список была с самого начала, и будет всегда даже в необозримом будущем.
Оставьте свое сообщение