Имеется документ (профайл), который править может только пользователь с правами менеджера. Но существует вероятность, что потребуется данная возможность для пользователя с правами автор. Поэтому сохранение документа (профайла) осуществляется агентом. Но столкнулись с такой проблемой, что изменения профайла отображаются пользователю только после переоткрытия клиента. Как можно решить данную проблему?
-
15 апреля стартует «Курс «SQL-injection Master» ©» от команды The Codeby
За 3 месяца вы пройдете путь от начальных навыков работы с SQL-запросами к базам данных до продвинутых техник. Научитесь находить уязвимости связанные с базами данных, и внедрять произвольный SQL-код в уязвимые приложения.
На последнюю неделю приходится экзамен, где нужно будет показать свои навыки, взломав ряд уязвимых учебных сайтов, и добыть флаги. Успешно сдавшие экзамен получат сертификат.
Запись на курс до 25 апреля. Получить промодоступ ...
Профайлы кэшируются. Если нужно взять не из кэша, то можно так:
Set Doc = db.GetProfileDocument("ProfileName", "UserName")
Set Doc = db.GetDocumentByUNID(Doc.UniversalID)
Set Doc = db.GetProfileDocument("ProfileName", "UserName")
Set Doc = db.GetDocumentByUNID(Doc.UniversalID)
Я использую формулы
lProjectCode:=@GetProfileField("DbProfile"; "PrfDbPrjCode");
Вставляется старое значение
Если я не ошибаюсь, где-то ToxaRat приводил код "правильного" сохранения профайла. Смысл в том, чтобы старый профильный документ удалить, скопировав все его поля в новый.
Можно попробовать создать в профиле вычисляемое поле "UNID" с формулой @DocumentUniqueID и получать поля из профиля формулой вида:
@GetDocField(@GetProfileField("имя профиля"; "UNID"); "имя поля"). Но это будет работать медленне, чем @GetProfileField
@GetDocField(@GetProfileField("имя профиля"; "UNID"); "имя поля"). Но это будет работать медленне, чем @GetProfileField
я сейчас пошел еще дальше
всё "системное" храню в иконке базы, так же как ИБМовцы, нотеИД у неё постоянное поэтому трабл нету и она не кешируется
А разве иконка - не элемент дизайна? В таком случае нужны как минимум дизайнерские права на изменение в ней чего либо.
Имеется 2 базы.
В сопраженной базе имеется профайл, некоторые поля которого берут свое значение из документа текущей базы.
Но если править документ текущей базы я разрешить пользователям могу, то напрямую давать доступ править профайл в сопряженной базе не хочется, т.к. приходится предоставлять права как Manager. Поэтому переносом значений полей из документа текущей базы в профайл сопряженной занимается агент, у которого есть все права. Но его изменения во второй базе видны пользователю после переоткрытия документа.
Данный подход не помогает. Приходится открывать профайл вручную и пересохранять, тогда работает.
Смысл в том, чтобы сохранить unid профайла в поле, а сделать это можно разными способами, хотя бы так
profiledoc.ReplaceItemValue("UNID", profiledoc.UniversalId)
Если профайл не создаётся динамически, то это вообще однократная операция.
Агент сохраняет в данном полу UNID, но все же пользователь не видит изменений, даже этого поля UNID пока не пересохранит профайл (если Пользователь Manager) или не переоткроет клиент.
Профайл один или их много? Они "живут" постоянно или создаются агентом? Если профайлы постоянные, то достаточно один раз прописать в них UNID и перезагрузить Лотус, потом всё будет работать как надо.
Обучение наступательной кибербезопасности в игровой форме. Начать игру!