КАК из запроса обратится в общий модуль

[Dethmontt]

blackmoon89, могу пожелать только успехов.

[Dethmontt]

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

З.Ы.Ы.Ы. Не создавайте составные типы для разделения доступа к записям, это полный бред!!! На очень больших объемах и интенсивных чтение\запись вы только проиграете в производительности!

[blackmoon89]

З.Ы.Ы.Ы. Не создавайте составные типы для разделения доступа к записям, это полный бред!!! На очень больших объемах и интенсивных чтение\запись вы только проиграете в производительности!

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

Нами проверено в продакш среде 500+ пользователей и мы с уверенностью заявляем, что вы пишите глупость.

Добавлено: 04 апр 2015, 06:51

чтение\запись

Запись при выборке

[vitasw]

ОГО! - чет я рано спать ушел. Какой тут экшн развернулся.
Если полемика касается моего примера, то мне НЕ НУЖНО разделение доступа к записям. ВСЕ записи РС читают ВСЕ роли. Нужно только в отчете не отображать суммы. В отчете все суммы видеть нельзя, а вот открыть каждый элемент и просомтреть - можно.
Собственно поэтому я и не понимаю, как предложенная оптимизация от blackmoon89, может помочь в этом вопросе.
Если же рассматривать идею разделения доступа к записям через составной тип без привязки к моему примеру, то на первый взгляд криминала я не увидел и думаю, что будет работать достаточно быстро. Я по-моему даже сталкивался с таким решением когда-то давно, и чего-то такое решение нам не понравилось, естественно суть не вспомню. Сама идея очень хороша, я даже возьму ее на вооружение. НО каким, е-мое, боком это поможет в моем конкретном примере?!?!?!?

[blackmoon89]

НО каким, е-мое, боком это поможет в моем конкретном примере?!?!?!?

Если объекта нет, то 0
Посмотрите как объект отображается, если к нему нет доступа. Не забываем, что можно сделать вторую играющую роль роль, сорри за тавтологию

[vitasw]

С этим конкретным примером разобрались. Давайте посмотрим на вопрос ширше изменим пример. Теперь разделяем доступ к записям по ролям, как предлагаетblackmoon89, по доп. измерению. В прикрепленным файле база пример на скорую руку. В списке РС погасил записи с "объект не найден" отбором. Но сдается мне что есть какие-то еще варианты. В самих запросах - выбираем разрешенные объекты доступа и получчаем нужные записи. А вот что делать с фомрой списка?...

[blackmoon89]

А вот что делать с фомрой списка?

там еще проще, откройте форму, станьте на реквизит формы "список" и посмотрите его свойства, там есть настройка списка, смотрите условное оформление

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

Добавлено: 04 апр 2015, 19:16

Если полемика касается моего примера, то мне НЕ НУЖНО разделение доступа к записям. ВСЕ записи РС читают ВСЕ роли.

вот это как раз не доходило до уважаемого Dethmontt несколько страниц подряд

[vitasw]

Так вопрос то не стоял в том какой из способов лучше. Все 6 листов полемики заключались только в том как привязать ваш метод к моему частному примеру и вы же сами подтвердили что ваш метод к моему частному примеру никак не привяжешь
Имеется 2 абсолютно разные задачи:
1.Проблема отображения данных исключительно в отчете - это очень частный случай, который я привел как пример возможности использования общего модуля в СКД.
2.Проблема разделения доступа к записям.
Не скрою использвание доп реквизита в сравнении с традиционным РЛС имеет ряд приимуществ. У меня правда возникает ряд вопросов:
1. Получается под каждую роль (будем утрировать) создаем отдельный справочник к которому имеет доступ только 2 роли: урезанная и полные права.
2.Как быть когда к одной и той же записи должны иметь доступ несколько урезанных ролей.
3.Сами справочники (которые входят в состаной тип доп. реквизита) не содержат данных или по одной записи.
4.Этот метод будет иметь достаточно большое приимущество на больших объемах данных с большим числом пользователей, но сложнее в реализации и требует больше кода, включая разарботку форм списка.

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

[blackmoon89]

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

Тогда зачем вы его приводили и приводили решить данную задачу? Он уже очень частный?

1. Получается под каждую роль (будем утрировать) создаем отдельный справочник к которому имеет доступ только 2 роли: урезанная и полные права.

Вовсе нет, один справочник, и распределение нескольких ролей по нему.

2.Как быть когда к одной и той же записи должны иметь доступ несколько урезанных ролей.

Смотрим ответ выше.

3.Сами справочники (которые входят в состаной тип доп. реквизита) не содержат данных или по одной записи.

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

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

Ну уж извините

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

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

[vitasw]

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

Да боже упаси! я нигде ни в одной строчке всей этой темы не утверждал такого! А говорил только что не нужно увидев 2 фразы рядом: "СКД" и "общий модуль" сразу кричать "ересь" и "костыль" и привел частный случай, где использование общего модуля правомерно. И "да", общий модуль в вычисляемых полях - это как езда на ручнике, ездить можно, но почему-то все показывают пальцами. Ну или когда ты пришел в чужие результаты и работаешь с тем что есть.

Вовсе нет, один справочник, и распределение нескольких ролей по нему.

Т.е. РЛС по этому справочнику?