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

Отличный момент для перехода на снеговика.

(1) Хорошо бы. Но, увы, пока исключено.

(0) "ограничить .... видимость старых договоров и контрагентов". Какой смысл в этом?

(0) полного аналога RLS добиться сложно.
Частично в списке справочников можно заюзать "использоватьСписок" когда мы 1С отображает только нужный список. Это не спасет от доступа через отчеты и не спрячет документы. Т.е. если нужно ограничить чисто в момент выбора/просмотра списка то самое то

(0) только писать.... долго и нудно...

замумукаетесь

В типовых типа ТиС можно довольно просто и быстро вывернуться. Благодаря активному использованию глобальных процедур и функций. А с самопиской... некоторые написаны так, что проще похоронить с переходом на 8ку, чем развивать и поддерживать.

по трудозатратам это сопоставимо с переходам на 8-ку.

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

И все равно останется системное меню через которое можно посмотреть спрятанное. Т.е. от "дурака" спрячешь. Кто-то серьезнее легко все равно увидит (к примеру тупо запустит свой отчет или какой нибудь универсальный)

самый простой вариант поднимите УРБД и сделайте отдельную базу под сотрудника, откуда будет инфа сливаться в общую

>Но, увы, пока исключено.

на переход денег нет

на решение этой задачи средствами клюшек - трудозатраты тоже будут весомые

забить

> Т.е. от "дурака" спрячешь. Кто-то серьезнее легко все равно увидит
Можно и в 7.7 неплохо спрятать. Только для этого нужно обложить её несколькими внешними компонентами и кучу мест переписать. Процесс оправдывает себя только если в качестве фикси сидишь несколько лет на этой базе и понемногу допиливаешь в рабочем порядке.
Брать и переписывать самописку... Можно, конечно, глянуть. Глядишь уложатся трудозатраты в тысяч пятьдесят...

База доживает свой век. Но приходят новые сотрудники и руководство хочет, что бы они не видели данные заведенные до них.

> и руководство хочет, что бы они не видели данные заведенные до них.

а колесо от троллейбуса оно не хочет?

пусть в новой пустой базе тогда сидят

Гипнотизера пригласить дешевле

(12) чем (9) не устраивает? помимо того что лицензия УРБД стоит отдельных денег. но может она у вас уже есть.

(15) УРБД это интересно, но дело даже не в лицензии.
Эту конфу видно разрабатывали с нуля, и там вообще ничего нет - ни одного типового объекта.

(16) А УРБД все равно есть там типовые объекты или нет.
кстати, а что такое "типовый объект"?

(16) тем лучше. УРБД так-то без разницы что есть в базе.
делаешь базу-дочку и ставишь правила миграции по объектам, "периферия-центр" если я правильно помню. общие необходимые справочники - "все базы".

Вариант: журнал с отбором по пользователю.

(18) и как это коррелирует с: "Нужно новому сотруднику ограничить видимость старых договоров и контрагентов"?

(16) для УРБД это не принципиально... но, для сокрытия элементов справочника с помощью УРБД писать придется не намного меньше, а геморроя получишь побольше....

(20) самым прямым образом. в новой базе для сотрудника данные отсутствуют. все что он наделает с обменом уедет в центр. из центра соответственно по правилам миграции в периферию старые данные не едут.
ничего там сложного в настройках УРБД нет.

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

ИМХО, самый лучший вариант: журнал с отбором по пользователю. Но только смысла в этом не вижу. Зачем ограничивать видимость?  Сдается мне, задача неправильно озвучена, либо неправильно понята.

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

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

Если только договора.
Сотруднику свой интерфейс и формы, в них данные из запроса.
Так же заменить форму выбора и в ней замутить свой RLS
Не сильно долго делается.
Но вот если и документы должны быть не видны в которых старые договора - уже сложнее и больше писать.

История из личного опыта. Была у меня одна контора на обслуживании. Небольшая организация, продажи + мелкое производство. Работали на самописной 7.7. Так вот, руководство поставило задачу "Сделать так, чтобы пользователь не видел где лежит база". Сколько я с ними бодался, что нельзя так сделать. В общем, отказался это делать. Решение этой проблемы они нашли сами. (Внимание! Приготовьтесь, сейчас будет гениальное решение!) Они поставили в пути к файлам базу точку (".")! Точку, Карл! Всё! Проблема решена! Базу никто не найдет...

Так что, не всякая задача руководства имеет смысл. Пусть сами сначала разберутся, чего хотят.

Народ. Это самоделка на 7.7, даже не возьмусь определить бухгалтерия это или торговля, все подчищено. Новый пользователь должен пользоваться всем функционалом что и старые пользователи, но при этом не видеть данных введенных до него. Ни о каком отдельном интерфейсе речи нет. Если только в писать в каждый док и спр и отчет вызов ПриОткрыти со ссылкой на проверку текпользователя и его прав - разрешено не разрешено.

(29) "Не видеть данных" - речь про документы и отчеты? В справочниках должно ограничение работать?

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

(29) На сколько "не видеть данных, введённых до него"?
Самое простое, что приходит в голову:
1. во все журналы вставить ПриУстановкеИнтервала и не давать пользователю устанавливать период просмотра ранее определенной даты.
2. во все отчеты вставить проверку даты перед формированием и не давать формировать отчеты с начальной датой ранее указанной.
3. В каждый документ вставить ПриОткрытии проверку даты и не давать просматривать документы до определенной даты.

Блокирование внешних и встроенных обработок, которые могут показать запрещённую информацию - отдельный вопрос.

на SQL если база RLS можно сделать. но придется повозиться.

а дату задавать константой с правами админа

файловая

(31) ИМХО, такую задачу нужно ставить ДО написания ПО. А теперь - пилить: документы, справочники - отбор, отчеты - дата. В общем, работы - непочатый край...

> все договоры, контрагенты, объекты и прочие справочники должны фильтроваться
А какой смысл в фильтровании "старых контрагентов" ? Могу понять, когда контрагентов разносят по менеджерам/кураторам. Но что такое понятие "старого контрагента"? С которым уже не работаем? Тогда и у других пользователей таких контрагентов можно припрятать под фильтр, что бы глаза не мозолили.

(24) ты на каждого пользователя будешь свою константу заводить? )))))

если скл - то можно . есть компонента перехвата и модификации запросов
что-то типа 1chook.тк id назначаются последовательно,
то для данного пользователя и вида метаданных добвавить условие по id > n.

все эти переписывания и настройки - охрененные трудозатраты без понятных перспектив развития когда понадобится для другого нового сотрудника еще что-то похожее сделать но не такое.
когда на УРБД задача решается за 15 минут.
и спокойно масштабируется, хоть 50 новых сотрудников.
каждый получает свою новую базу куда вносит данные. в центре имеем итоговую базу.
из которой можем еще и выгрузки сделать в произвольное количество "только получателей", в которых будут смотреть отчеты те, кто тоже будет иметь ограниченные права.
и туда уже выгружать фильтруя по ИБСозданияОбъекта, или как там его.
все. универсальнейшее решение, минимум трудозатрат по реализации и поддержке.

(40) Да не решается она на УРБД и не масштабируется

Пробовал включить УРБД на копии - выдало:
"Для работы с центральным узлом распределенной информационной базы необходимо установить компоненту "Управление распределенными информационными базами". У кого-нибудь есть эта компонента на 7.7?

(42) забей в УРБД ты получишь чистую базу, без остатков, без цен, без взаиморасчетов. Даже справочников не будет

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

Для доков в 7.7 есть общие реквизиты, а для справочников?
Есть предложение - в каждом справочнике создать реквизит типа "дата", заполнить его во всех справочниках групповой обработкой, далее как говорил (32)   vcv
32 - 04.09.17 - 12:58
Самое простое, что приходит в голову:
1. во все журналы вставить ПриУстановкеИнтервала и не давать пользователю устанавливать период просмотра ранее определенной даты.
2. во все отчеты вставить проверку даты перед формированием и не давать формировать отчеты с начальной датой ранее указанной.
3. В каждый документ вставить ПриОткрытии проверку даты и не давать просматривать документы до определенной даты.

Блокирование внешних и встроенных обработок, которые могут показать запрещённую информацию - отдельный вопрос.

но тут резонный вопрос как быть с каждым последующим новым пользователем? как задать свойство конкретному пользователю с какой даты ему разрешено видеть данные

(45) "2. во все отчеты вставить проверку даты перед формированием и не давать формировать отчеты с начальной датой ранее указанной." - этого недостаточно. В отчет по долгам, например, вылезут все "старые" контрагенты.

Самое веселье начнется позже... Вот ты сделаешь эту байду. Потом руководство скажет: "Товарищ Иванов теперь занимается клиентской базой Сидорова. Сделай, пожалуйста, ему доступ как у Сидорова. Т.е. разрешенный период просмотра, клиенты и все прочее должно быть как у Сидорова".

(47) А вот тут ты прав, это будет шило.
Сейчас я добавил в спр.Пользователь реквизит "ДатаОграниченияВидимости" и каждому конкретному пользователю буду назначать свою дату.

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

(47) >> Сделай, пожалуйста, ему доступ как у Сидорова
Да фигня вопрос. В контрагента реквизит с указанием пользователя/менеджера/куратора. Реквизит с отбором и сортировкой. В справочнике контрагентов отбор по этому реквизиту и, например, закладки наверху формы для переключения отбора. В отчетах по контрагентам допилить фильтр по реквизиту контрагента (если конфигурация не на бух.учёте построена). Если пользователь исполняет обязанности за кого-то, в справочнике у него несколько закладок "Контрагенты Васи", "Контрагенты Пети". А в отчётах фильтр по списку менеджеров.

(49) недостаточно для решения ТЗ - "всех документов, отчетов и прочия... где используются договоры и контрагенты)"

а ведь есть еще косвенное использование. Например партии и поступление ТМЦ

(51) Конфа  самописная. Партий может и не быть. А мысля верная.

Партий нет. Разбивка по менеджерам, не предусмотрена спецификой работы. Клиенты не закрепляются конкретно за каким-либо сотрудником. Да и механизм контроля практически одинаков по сути: сопоставление Клиент - Менеджер и сопоставление Клиент - ДатаВидимости. В справочник встраивается доп. реквизит и сверяется с критерием.

Ведомость по контрагентам с группировкой по кредитным документам может показать старых контрагентов

(22) До тех пор пока тетка не жмакнет кнопку ОК в старом элементе.

(53) Что будем делать с дублями?

(40) Насчет поддержки ты не прав... сильно не прав. Настраивать правила для всего этого - то еще удовольствие. Как и решать затыки УРБД с десятком узлов...

(53) Ты, как специалист, должен был сказать: "Имеющимися средствами данная задача не решается." Т.к. ничто не мешает стащить файлы базы и увидеть там всех-всех-всех.

(58) я пока еще тоже сотрудник "новенький" :-))

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

(53) Задача довольна не тривиальная...
ИМХО: все завязать на пользователя. Справочники, документы - реквизит "пользователь" - все отборы только по пользователю. Отчеты - период только с даты создания пользователя. Итого: пользователь + дата создания. Дата создания - для отчетов, пользователь - для отборов.
(56) Вот тут - большой вопрос... Специфику деятельности нужно знать.

Попытался сделать через "УстановитьОтбор" по доп. реквизиту "ДатаОграничения", но пользователь на форме списка справочника интерактивно может такой отбор отключать. совсем заблокировать ему делать отборы нельзя.
Как спрятать конкретный отбор по конкретному реквизиту?

Увы. УстановитьОтбор использовать не получается - он срабатывает только на равенство значению отбора.
ИспользоватьСписокЭлементов(Список) - хоть и отбирает нужных, через ВыбратьЭлементы и Сравнение на >=, но при этом отключает все другие возможности работы со списком.
Что тоже не айс.

(63) Значит предложение перейти на восьмерку выглядит уже интереснее?

(63) Вот и я говорю: к чему все эти нелепые телодвижения?

(62) по-моему есть возможность не давать менять отборы. 7ки к сожалению под руками нет. но вроде было можно

(63) Правильно. Т.е. нужно стандартные функционал реализовывать ручками. Т.е. отдельная кнопка и вперёд

я же говорю "по трудозатратам это сопоставимо с переходам на 8-ку. "

(28) Что за "точка" позволила скрыть местоположение файлов базы? Не пойму... База-то с точкой запускается?

(69) Пример: D:\Грохать\Новая папка\.Новая папка

Ничего там не скрылось. Мне так объяснили: "враг не заметит точки и не найдет базы!".   Рукалицо....

(0) На sql возможно сделать: http://catalog.mista.ru/public/74613/

Но перспективнее делать на v8.

Кто-нибудь знает как запретить пользователю изменять отбор, или сделать так, что бы пользователь мог делать только разрешенные ему отборы, а другие не мог отключать?

(71) это работает для документов, как быть со справочниками и проверкой на >= ДатаОтбора?

(73) это работает для чего угодно.

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

(75) фигня это имхо
Сопрут инфу лпр, которые к ней имеют доступ потдолжностным обязанностям, а не рядовой манагер

делали, к пользователю прикрепляется справочник с просмотром , вот только все ништяки придется отрубить, включая табло и формульный калькулятор )))
ЗЫ допиливать муторно но можно , через свой справочник типа прав , только потом всё переписывать в приоткрытии и в сформировать ,

ЗЫ   проще базу ВАЩЕ обрезать и при необходимости нарисовать отчеты одновременно к двум базам и уж на них права выдавать

в таких случаях делали аркадную базу (да и на скуле) - НО изначально, вплоть что каждый работает в своей базе ))) но это уже часности )))