Есть набор документов, и в каждом есть информация об отделах, к которым он относится, как сделать представление, которое бы показывало пользователю документы, относящиеся только к этому отделу? Есть вариант show single category в embedded view, есть вариант создавать отдельные вьюшки для каждого отдела - но это как-то через попу. Может быть использовать Readers? В общем подскажите, есть-ли какой-нибудь хороший вариант для решения данный задачи? Спасибо за внимание.
-
15 апреля стартует «Курс «SQL-injection Master» ©» от команды The Codeby
За 3 месяца вы пройдете путь от начальных навыков работы с SQL-запросами к базам данных до продвинутых техник. Научитесь находить уязвимости связанные с базами данных, и внедрять произвольный SQL-код в уязвимые приложения.
На последнюю неделю приходится экзамен, где нужно будет показать свои навыки, взломав ряд уязвимых учебных сайтов, и добыть флаги. Успешно сдавшие экзамен получат сертификат.
Запись на курс до 25 апреля. Получить промодоступ ...
Мы сделали так, но у нас для сотрудников:
Вьюха с категорией, категория у нас LotusName, а точнее поле где оно содержится.
Встроили эту вьюху на страницу, ключ для категории @UserName.
В аутлайне агент, который открывает эту страницу.
Как результат пользователь видит документы только где он: Визирующий, исполнитель, автор.
Вопрос что именно нужно.
В случае с отделами... Можно сделать тоже самое, но ключ для отдела прописывать в Notes.ini и подтягивать для обрезки категорий.
С Readers своя деталь: если сотрудник одного отдела прописан в документах другого, то он их увидит.
А если будет смотреть только категорию своего отдела - нет.
Вьюха с категорией, категория у нас LotusName, а точнее поле где оно содержится.
Встроили эту вьюху на страницу, ключ для категории @UserName.
В аутлайне агент, который открывает эту страницу.
Как результат пользователь видит документы только где он: Визирующий, исполнитель, автор.
Вопрос что именно нужно.
В случае с отделами... Можно сделать тоже самое, но ключ для отдела прописывать в Notes.ini и подтягивать для обрезки категорий.
С Readers своя деталь: если сотрудник одного отдела прописан в документах другого, то он их увидит.
А если будет смотреть только категорию своего отдела - нет.
А можно динамически определять отдел пользователя, например через компьютед филд документа, куда будем встраивать вид или напрямую в формуле категории исходя из данных о структуре отделов? А если через Notes.ini то как туда лучше прописывать данные, при старте базы, агентом или только ручками? Ручками меня не устраивает, раньше просто Notes.ini не использовал и хотел бы продолжить традицию...
Если страницу заменить на форму, в форме сделать поле "отдел", то можно на уровне агента.
В show single category ключ поле "отдел".
В агенте создаете документ по этой форме, прописываете в "отдел" отдел пользователя и открываете.
Только тут момент: если этот документ будет открываться во фрейме, то его надо будет предварительно сохранить, следовательно таких документов будет скапливаться много. Надо будет их с течением времени удалять.
Вариант со страницей... На странице нельзя создавать поля, так что там только notes.ini
Я бы так же прописывал значение агентом, можно удалять значение при закрытии базы.
Возможно профайлы, но кажись @GetProfileFields не работает в show single category, тут я точно не скажу, проверять надо.
В show single category ключ поле "отдел".
В агенте создаете документ по этой форме, прописываете в "отдел" отдел пользователя и открываете.
Только тут момент: если этот документ будет открываться во фрейме, то его надо будет предварительно сохранить, следовательно таких документов будет скапливаться много. Надо будет их с течением времени удалять.
Вариант со страницей... На странице нельзя создавать поля, так что там только notes.ini
Я бы так же прописывал значение агентом, можно удалять значение при закрытии базы.
Возможно профайлы, но кажись @GetProfileFields не работает в show single category, тут я точно не скажу, проверять надо.
Категорически поддерживаю. Тем более что наверняка есть база, которая содержит орг структуру. Прикрутить к ней синхронизацию с АК легко.
Вариант: наименование отдела = группа доступа (READERS).
Такой структуры нет, доступ ограничен только по уровням (уровень управления, уровень отдела и т.п.) Поэтому и группы такие. В общем сейчас расскажу как я сделал.
Такой структуры нет, доступ ограничен только по уровням (уровень управления, уровень отдела и т.п.) Поэтому и группы такие. В общем сейчас расскажу как я сделал.
Поделюсь ка я полной информацией, может кому будет интересная такая организация программы. Итак, в базе есть документы и у каждого документа есть список исполнителей, назначенных на его исполнение, и в каждом исполнителе есть информация о том, к какому отделу, к какому управлению он относится, а также UserName пользователя связанного с этим исполнителем. Все эти исполнители прикрепляются к документу в виде респонсов. Затем при сохранении информация о всём списке исполнителей заносится в скрытые поля самого документа, чтобы можно было работать именно с документом, а не исполнителями. Итого имеются поля типа "Первые исполнители", "Исполнители уровня отдела", "Исполнители уровня управления" и другие уровни. По такому же принципу были сделаны поля "Все управления" и "Все отделы". Затем я создал два вида с категоризацией по этим полям с галочкой "Show multiple values as separate entries" (ну естественно...). Далее созданы две формы, с встроенными вьюшками, ссылающимися на только что полученные. Также в базе есть справочник, в котором хранятся все сотрудники в соответствии со структурой управлений, отделов и т.п. Именно оттуда берутся сотрудники, программно копируются, превращаются в исполнителей, делаются респонсами на документ при добавлении в него новых исполнителей. Есть также инструменты, чтобы переписывать в каждом таком исполнителе во всех документах информацию, если она меняется в справочнике пользователей, ведь каждый исполнитель просто копия сотрудника. Да здесь куча излишней информации, но иначе там похоже никак 
Главное работает и неплохо. Дак вот, я создал ещё одну вьюшку "(Для определения подразделения)" в которой сопоставлены все UserName сотрудников с их отделами и управлениями. Вот, а далее в формуле Show single category embedded view тех двух документов с помощью @DBLookUp во вью "(Для определения подразделения)" находится название отдела или управления, что как бы и нужно. Затем в аутлайне создана кнопули, использующие команду @Command([EditProfile] ; "Документы отдела"; @UserName), можно по идее использовать и обычный [Compose], но так мне почему-то больше нравится. Если кто не знал, то @Command([EditProfile]) открывает документ пользователя, который есть по одному на каждого юзверя с помощью определённй формы. Таким например способом у меня работает фильтр, который является формой с параметрами поиска и встроенной вьюшкой, которая указывается на папку, у которой при создании был поставлен параметр "Shared, private on first use", что в совокупности позволяет хранить параметры поиска и его результат для каждого пользователя отдельно. И каждый раз когда пользователь заходит в фильтр он видит свой последний запрос и его результат.
Главное работает и неплохо. Дак вот, я создал ещё одну вьюшку "(Для определения подразделения)" в которой сопоставлены все UserName сотрудников с их отделами и управлениями. Вот, а далее в формуле Show single category embedded view тех двух документов с помощью @DBLookUp во вью "(Для определения подразделения)" находится название отдела или управления, что как бы и нужно. Затем в аутлайне создана кнопули, использующие команду @Command([EditProfile] ; "Документы отдела"; @UserName), можно по идее использовать и обычный [Compose], но так мне почему-то больше нравится. Если кто не знал, то @Command([EditProfile]) открывает документ пользователя, который есть по одному на каждого юзверя с помощью определённй формы. Таким например способом у меня работает фильтр, который является формой с параметрами поиска и встроенной вьюшкой, которая указывается на папку, у которой при создании был поставлен параметр "Shared, private on first use", что в совокупности позволяет хранить параметры поиска и его результат для каждого пользователя отдельно. И каждый раз когда пользователь заходит в фильтр он видит свой последний запрос и его результат.
тогда к чему описание в вольной форме, без абзацев/стр-ры/привязки к требованиям
такую простыню трудно оценить и понять
вот такбы вам документацию выдавали
Ну извини!
А как на счёт резайза? Работает? Или у вас у всех пользователей разрешение на мониторах одинаковое?
Там есть Fit to window и у Width и у Height, а если открывать во фреймсете то вообще от вью неотличимо, разве что не получилось добиться, чтобы новое окно не открывалось...
Может я не правильно выразился, я имел ввиду новую вкладку. А код супер прост: @Command([EditProfile]; "Документы отдела"; @UserName), а уже в форме в параметрах указано в каком фреймсете его открывать
Вот из-за этого новая вкладка...
Можно использовать @SetTargetFrame( targetframe ), надо вызвать до момента редактирования.
targetframe - имя фрейма во фреймсете.
Как это будет в совокупности с @Command([EditProfile]) не скажу, но с @Command([EditDocument]) работает точно.
Тогда профайл откроется не в новой вкладке, а текущем фреймсете, в нужном фрейме.
Только из свойств формы уберите открытие во фрейме.
Ой, а я так пробовал, но писал имя фреймсета, а не фрейма
, поэтому подумал, что это всё работает только со вьюшками ). Спасибо большое! Кстати c @Command([EditProfile]) не работает...Обучение наступательной кибербезопасности в игровой форме. Начать игру!