Виробництво конфігурації 1С 8.1

Доброе утро. Есть несколько вопросов:

- какая у вас конфигурация (название и версия);

- с какой целью вы хотите заменять названия документов.

Юрий Петров 14 листопада 2020

А названия менять, что бы и просто в списке не понятно было что за документ. Это как дополнение, готовы отказаться от этого

Может быть вам стоит перейти на УНФ базовую. Там уже реализован механизм блокировки (правда без редактируемых сообщений).

Здравствуйте, Юрий.

А не проще ли сделать, чтобы пользователи вообще не видели запрещенных им документов? Зачем весь этот "маскарад"?

Юрий Петров 14 листопада 2020

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

Подождите. При чем тут номенклатура к документам? Не путайте все в одну кашу.
Можно ограничить доступ к документам (чтоб эти документы пользователь видел, а эти нет). И с номенклатурой можно так же поступить - чтобы эту номенклатуру видел, а эту нет.
В том числе можно и по периоду доступ ограничить. Чтоб старых документов они и не видели.
Делается это элементарно - с помощью механизма РЛС (если я правильно все помню, то в 8.1 он уже был).

Кстати, еще один вопрос - а почему на такой древней версии работаете? На 8.3 обновиться не думали?

Юрий Петров 14 листопада 2020

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

"Каким образом будет ограничиваться доступ?"
В 1С есть такое понятие как RLS (Record Level Security). С ее помощью, для каждой роли, которую нужно ограничить (т.е. ограничивать можно не всех пользователей, а только пользователей с определенной ролью)... для каждого объекта (в нашем случае документа), доступ к которому нужно ограничить... прописывается "запрос-ограничение".
В Вашем случае, запрос может накладываться по дате. Что-то вроде "ГДЕ Дата >= ПРИБАВИТЬПЕРИОД(&ТекущаяДата, -31, ДЕНЬ)".
Где ТекущаяДата - это ПараметрСеанса (который тоже нужно будет добавить и устанавливать при запуске приложения).

Все. И теперь пользователи с этой ролью просто физически не будут видеть документы старше 31 дня.


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

Юрий Петров 14 листопада 2020

Хорошо, Сергей. Делайте вашу ставку если интересно будет этим заняться. Обсудим все дополнительно по телефону если нужно будет. 

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

Для этого мне от Вас понадобится:
- Файл Вашей конфигурации. Или даже лучше, если такое возможно, выгрузка базы с похожими на Ваши (но не обязательно настоящими) демо-данными для разработки.
- Более подробное описание того, каким ролям, какие документы и точно по каким критериям ограничивать? Например, "Нужно добавить роль Стажер, у которого должен быть доступ только к документам ЗаказПокупателя (и к связанным с ним справочникам - только просмотр). При этом документы, старше 31 дня ему доступны быть не должны."

- Вам результат в каком виде нужен? Файл конфигурации с изменениями подойдет? Или нужно будет обновить все Ваши три базы и сдать "под ключ"?

P.S.
Вот. Нашел статью про РЛС. В ней говорится, что РЛС появилась в 8.1 (так что Вам такое решение очень даже подойдет).
http://e-1c.ru/index.php/node/207

Еще один уточняющий вопрос.

"доступ к этому типу документов нужен, но не ко всем а к тем которые были созданы в течении последнего месяца"

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

Здравствуйте, Юрий.

Читая обсуждение задачи (в том числе с другими исполнителями), а также постановку задачи, у меня все больше закрадываются сомнения в том, что я правильно уловил суть Вашей проблемы, т.к. формулировку "чтобы пользователи не видели документы" можно понимать по разному.

Поэтому задаю ключевой вопрос:

Вам нужно чтобы ограниченные пользователи "не знали" о существовании более ранних документов?
Или просто, чтобы эти документы "не путались у них под ногами"?

чтобы ограниченные пользователи "не знали" о существовании более ранних документов?

Я имел в виду "чтобы пользователи не знали о существовании документов в закрытом периоде"

Юрий Петров 15 листопада 2020

чтобы ограниченные пользователи "не знали"  

По поводу настройки ограничений.

Настройки ограничений должный задаваться конкретному пользователю отдельно свои. В карточке пользователя Конфигуратор – Администрирование – Пользователи = Конкретный пользователь

В указанное окно мы никакие поля добавлять не можем (это чисто платформенное окно).

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

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

Юрий Петров 15 листопада 2020

"кроме ролей в список доступных пользователю ролей" значит создание дублирующей роли будет оптимальным решение. Но тогда вопрос где и как мы будем задавать период для этой роли?

Период для этой роли будем задавать в карточке Пользователя (в режиме Предприятие). Технически, будет это реквизит в справочнике Пользователи или отдельный регистр сведений - не важно. С точки зрения пользователя-администратора - это будет где-то в карточке Пользователя.
Я больше к регистру сведений склоняюсь, но еще подумаю как лучше.

Юрий Петров 15 листопада 2020

Не будет ли пользователь иметь доступ к этой настройке, и возможность ее редактировать самостоятельно?

Естественно, что нет. Доступ к настройке будет только у Администратора (ПолныеПрава).

А у роли ПолныеПраваСОграничением будут права только на программное чтение таблицы настроек периодов (т.е. он их даже посмотреть не сможет - развче что запросом каким-то выковырять, чтобы увидеть). Но изменять настройки у него возможности не будет.

Юрий Петров 15 листопада 2020

Хорошо, это нам подходит

По поводу настройки периода.

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

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

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

Юрий Петров 15 листопада 2020

Я так понимаю вы ознакомились с обновлённой информацией, я не совсем понимаю о чем вы говорите. Мне допустим надо что бы пользователь не видел документы за март 2019 года. Я себя представляю это так: указываю дату начала ограничения 01.03.2019 и дату окончания 31.03.2019 как бы и все, за этот период документы не должны быть видны. Что касательно последних 30-60 дней и тд. Я понимаю что идёт смещение во времени и дату нужно будет редактировать. Каждый день, по событию изменения даты. 

Да. Я ознакомился с дополнением к задаче и приложенными файлами.
Я не совсем правильно понял. Мне показалось, что Вы хотите указывать период дат, в котором пользователю доступны документы. А получается, что у Вас обратная задача - "скрыть какой-то конкретный период".

Кстати, сразу следующий вопрос, уже с новой точки зрения: Такой "скрытый" период может быть только один? Или их может быть несколько (например, март 2019, сентябрь 2019 и "с 13.01.2020 по 21.05.2020")?

Юрий Петров 15 листопада 2020

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

Понял.
А что по первым двум вопросам: Ключевой вопрос и По поводу настройки ограничений.

По поводу ролей.
Если речь идет о том, чтобы документы не были доступны никакими способами (ограниченные пользователи "не знали" о существовании документов за пределами позволенного им периода), то...

Реализовывать эту задачу разумнее всего через РЛС. Так и надежнее (т.к. "спрятанные" документы будут недоступны пользователю никакими способами, включая запросы и отчеты), и технически проще.

Но РЛС вешается не к пользователю, а на какие-то роли.

Причем, если пользователю будет назначено две роли, одна из которых дает доступ к указанным документам, а другая роль пытается с помощью РЛС этот доступ ограничить, то сработает принцип "если одна из ролей позволяет, тогда пользователю позволено" и РЛС работать НЕ будет.

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

В предоставленной Вами тестовой базе - у всех пользователей ПолныеПрава.

  Если в Ваших Живых базах тоже у всех пользователей ПолныеПрава, то логично ограничение вешать на эту роль. Хотя, как на мой взгляд, крайне странно и не логично - роль ПолныеПрава, у которой права НЕ полные.

  Если ограничивать нужно пользователей, которым не назначена роль ПолныеПрава, а назначена роль Пользователь, тогда логично РЛС вешать на роль Пользователь. Правда, в этом случае, всем таким пользователям нужно будет настраивать доступные периоды. Хотя эту необходимость можно какой-то дополнительной галочкой в свойствах пользователя отключать (это так - раздумья на тему).

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

Тут нужно обсудить как Вам лучше.

Но в этом случае, мы получим необходимость в будущем поддерживать эту роль в случае дальнейших доработок конфигурации.

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

В-общем, нужно больше информации о том, каким образом Вы раздаете своим пользователям роли, и как Вы видите развитие своей политики раздачи ролей пользователям?

Юрий Петров 15 листопада 2020

Значит сделать дублирующую роль, аналогичную «Полные права» но назвать ее «Полные права_ограниченные» и для неё реализовать оговариваем функционал.

Понял.

По поводу поставки результата.

    Я правильно понимаю, что Вы предоставите три dt-шки Ваших Живых баз? И во время того, как я буду у себя обновлять в них конфигурацию, в Ваших базах никто работать не будет. А когда Вы получите от меня обновленные dt-шки, то самостоятельно развернете их у себя?

    Или, может, чтобы сократить время "простоя" баз, лучше пустить меня удаленно на Ваши машины, чтобы я обновил конфигурацию прямо на Живых базах? Естественно, бекап "До" и бекап "После" - в обязательном порядке :)

Юрий Петров 15 листопада 2020

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