Пишу базу

  • Автор темы Автор темы phantom76
  • Дата начала Дата начала
P

phantom76

Всем привет,
пишу базу для отчетов..
появились вопросы: (заранее спасибо за помошь!!)

1. Возможно ли реализовать механизм разграничения доступа к полям? т.е. один пользователь может редактировать в документе только одни поля, другой только другие, третий все.
как я понял это все можно реализовать создав соответствующие формы для каждого типа пользователей и через роли им назначить. Чтобы с данной формой редактировать могла только нужная роль пользователей , в свойствах формы выставляю на последней закладке права - "кто может создавать док по этой форме" - этого будет достаточно или есть другой способ (например на уровне полей или секций !?) ?
2. В случае если в разных репликах пользователи будут редактировать один документ , но разные поля, в итоге не приведет это к конфликту репликаций?
 
1. В принципе нет. Можно только шифровать поля. Остальное делается в UI и создаёт только иллюзию разграничения прав.
2. Да. Но можно изменить свойтво формы Conflict Handling или соответствующее поле $ConflictAction в документе.
 
1) разграничение доступа к полям можно по-разному реализовать, это могут быть и Controlled Access секции, и скрытие, и другие варианты :)

2) приведет :) но, можно постараться уменьшить вероятность конфликта - свойство обработки конфл. ситуаций на форме; потом, желательно максимально уменьшить возможность редактирования дока разными пользователями в одно и то же время или разграничить между ними поля, которые они могут редактировать (это к пп1)

Medevic сказал(а):
1. В принципе нет. Можно только шифровать поля. Остальное делается в UI и создаёт только иллюзию разграничения прав.
Нажмите, чтобы раскрыть...
см. isProtected
 
спасибо за ответы!!

т.е. в итоге в итоге я смогу построить архитектуру при которой, все данные хранятся в одном документе, а 4 разных пользователя заполняют каждый свою часть полей? , т.е. что это будет все-таки 1 документ а не 4 ?
 
Akupaka сказал(а):
см. isProtected
Нажмите, чтобы раскрыть...
Как мне кажется, это практически бесполезное свойство. Не получится это сделать:
phantom76 сказал(а):
один пользователь может редактировать в документе только одни поля, другой только другие, третий все.
Нажмите, чтобы раскрыть...


phantom76 сказал(а):
т.е. в итоге в итоге я смогу построить архитектуру при которой, все данные хранятся в одном документе, а 4 разных пользователя заполняют каждый свою часть полей? , т.е. что это будет все-таки 1 документ а не 4 ?
Нажмите, чтобы раскрыть...
Ну а почему бы не сделать в 4-х документах?
Еще можно дать всем права Readers, а поля через агент менять.
 
Medevic сказал(а):
Как мне кажется, это практически бесполезное свойство. Не получится это сделать:




Ну а почему бы не сделать в 4-х документах?
Еще можно дать всем права Readers, а поля через агент менять.
Нажмите, чтобы раскрыть...

алгоритм работы базы должен быть такой:

есть менеджер базы - он имеет право на создание шаблона отчета с заданными параментрами для подразделений, есть 4 ответственных лица в подразделениях, которые должны заполнить соответствующие разделы в этом отчете.
и в итоге отчет должен быть предоставлен руководителю как единая форма.
соответственно если это будет уже 4 документа, то нужно будет или по ним построить 5-ый итоговый и предусмотреть механизм переноса начальных данных введенных менеджером в документы подразделений, вот пока размышляю как логичнее построить этот процесс?
 
в программировании нельзя руководствоваться терминами "кажется" и подобными :)

указанное свойство итемов isProtected небезполезно, если им правильно пользоваться...
а свойство формы Conflict handling = Merge Conflicts очень даже хорошо справляется, если пользователи изменяли разные поля...
и то, что требуется phantom76 можно сделать, правильно все организовав, и с помощью единого документа...

зы: а еще можно не использовать лотус :)


phantom76 сказал(а):
алгоритм работы базы должен быть такой:

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

я бы выбрал, все-таки, отдельные документы, т.к. здесь предусматривается одновременная работа с документом, т.е. вероятность одновременной правки документа стремится к 100%

т.е. к примеру, Ваш менеджер создает документ, устанавливает его статус "жду ответа", остальные заходят в этот документ и нажимают на княпку "ответ", при этом создается ответный документ, в котором пользователь заносит данные... каждый отвечает, в итоге получается документ и дочерние к нему...
эти дочерки можно различными способами обработать:
- можно просто отображать их в виде как связанные доки;
- можно серверным агентом поместить данные из ответов в родительский, а дочерние убить;
- можно отображать данные из дочерок в открытом родительском в виде встроенного вида, либо в какие-то поля засовывать данные при открытии;

либо другим способом...
 
какой лучше функцией восспользоваться для проверки наличия\отсутствия у пользователя определенной роли, с целью скрытия секции на форме?
 
спасибо! :)
я так понял на локале @UserRoles не работает?

Text list. Each item in the list is the name of a role that the current user has in the current database. The role names are enclosed in brackets. Returns an empty string ("") if the current database is local and "Enforce a consistent Access Control List across all replicas" is not in effect.
 
понял-то правильно, но есть ведь и вторая часть ответа - Returns an empty string ("") if the current database is local and "Enforce a consistent Access Control List across all replicas" is not in effect
так что, можно сделать чтобы работало

эта галка находится на закладке дополнительных параметров ТУД
 
еще вопросик, глюк какой-то..

на форме пытаюсь спрятать секции в зависимости от роли, соответственно в опции: Hide paragraph if formula is true: ставлю "галку" и пишу формулу: @If(@IsMember("[user1]"; @UserRoles);@True;@False) , но заметил такой глюк, что зачастую скрывает только имя секции, если она развернута на форме..

как правильно реализовать этот механизм?
 
ну, либо сделать так чтобы секция не раскрывалась, либо добавить в скрытие того, что внутри секции ту же проверку на роль...
к стати, достаточно написать @IsMember("[user1]"; @UserRoles) , она сама вернет @True
 
вот еще вопросик:

хочу в документе дополнительно контролировать модификацию определенных полей по последнему изменению,: дату и автора
для чего на форме созданы соответсвтующие поля, сначала использовал в вычисляемых полях фомулы вида :
@If(@IsMember("[Roles1]"; @UserRoles);@Name([CN];@UserName);"");
@If(@IsMember("[Roles1]"; @UserRoles);@Now;"");

но в этом случае, пользователь с другой ролью, очищает поля по "иначе" (может присваивать полю свое текущее значение?! )
поставил все эти формулы в QuerySave на форме,

@If(@IsMember("[Roles1]"; @UserRoles);@SetField(Updatedby1;@Name([CN];@UserName));"");
@If(@IsMember("[Roles1]"; @UserRoles);@SetField(Updated1;@Now);"");

но почему-то не работают они там..
 
а где кавычки-то ? вроде не забыл..
@SetField( fieldName ; value ) имя поле идет разве в кавычках?


понял.. имя поля должно быть в кавычках :rolleyes:))
 
Для ответа нужно войти/зарегистрироваться
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!

Верх Низ