Закрытие документа и организование раздельного доступа

[FEDAZzZ]

Всем привет=)

У меня две проблемки возникло.... Может кто знает и поможет как решить их

1) Есть action - по нажатию, сохранятеся документ-ответ и закрывается, активным становиться родительский документ через который создавался ответ. Так вот хотелось бы и его тоже закрыть из того action (из документа ответа, чтобы закрилиь и ответ и родительский документ) это можно как-нибдуь сделать на @-формулах?

2) Как орагинзовать доступ к документам Privrate и общедоступный? я тут чуть запутался....
В АЦЛ для всех пользователей ставлю Editor....
ограничиваю кодом доступ к редактированию....
Родительский документ должны видеть все пользователи которые указаны в его полях Author, а документ ответ также должны вижеть только те пользователи которые указаны в полях Author... а получается что видят все кто указан в родительском документе... :huh: это верно?

 

[NickProstoNick]

Не уверен что на формулах можно закрыть чужое окно...
Но вот на скрипте можно попытаться
Закрыть можгно только UI-шный документ.

А по второму вопросу.... Private - это зло!
Переходи на обычные виды и разграничивай Authors/Readers полями.

а документ ответ также должны вижеть только те пользователи которые указаны в полях Author

Одним Author-полем не обойдешься. Author - это те кто могут править документ
Readers - те кто может видеть

 

[FEDAZzZ]

Одним Author-полем не обойдешься. Author - это те кто могут править документ
Readers - те кто может видеть

То есть... Те кто в Author видят и редактируют документ, те кто в Readers только видят, но не редактируют. А как же тогда на это влияют значения в ACL листе? если у человека стоит пункт Editor, он же должен видеть все документы? Или он видит только те документы в полях Readers и Authors которых он стоит. :blink:

Зы. Спасибо, за ответ на первый вопрос =) хотел вот убедиться что правда нельзя, а не то что мне не хватает знаний :Р

 

[FEDAZzZ]

не хотел открывать новую тему, напишу в эту....

Я что-то опять запутался в полях Ридер и Автор.

Автор - видит все документы? Или только тех в которых он четко прописан?

Если в документе (в базе, где есть разограничение по авторам и ридерам) нет полей ридер/автор - то его видят все? И могут редактировать те, кто имеет уровень доступа автар и выше ?

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

 

[nvyush]

не хотел открывать новую тему, напишу в эту....

Я что-то опять запутался в полях Ридер и Автор.

Автор - видит все документы? Или только тех в которых он четко прописан?

Если в документе (в базе, где есть разограничение по авторам и ридерам) нет полей ридер/автор - то его видят все? И могут редактировать те, кто имеет уровень доступа автар и выше ?

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

Совет первый и банальный - внимательно читать хелп. По существу:
1. Если в ACL ставить уровень доступа editor, то использование полей authors теряет смысл, поскольку эти поля влияют только на пользователей с уровнем доступа author. Editors могут править ВСЕ документы, которые они видят.
2. Если в документе нет полей authors/readers, его видят все, в т.ч. пользователи с уровнем доступа в ACL reader. Если поля есть, то документ видят только те, кто в них перечислен явно, через группы либо через роли. Кто не указан - не видит. В частности, если в них не указан сервер, то документы он не увидит и не будет их реплицировать.

 

[Alexander (Criz)]

1. если нет полей Reader, то док видят все.
2. поле Author не заменяет поле Reader, а только указывает что имеет право на редактирование, даже если уровень доступа ниже Editor
3. Автор видит все документы, где указан в Reader поле, либо указана его роль, либо его OU (*/Sales/Company/Ru). Также те документы, которые из п. 1

 

[FEDAZzZ]

Спасибо ) Теперь разобрался )

 

[K-Fire]

Плюс если в ридерском поле пустое значение "", то это тоже воспринимается как будто поля нет.

 

[nvyush]

Плюс если в ридерском поле пустое значение "", то это тоже воспринимается как будто поля нет.

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

 

[PaVaP]

2. поле Author не заменяет поле Reader, а только указывает что имеет право на редактирование, даже если уровень доступа ниже Editor
3. Автор видит все документы, где указан в Reader поле, либо указана его роль, либо его OU (*/Sales/Company/Ru). Также те документы, которые из п. 1

2 и 3 не верно.
Поля Authors имеют функциональность полей Readers.
Поэтому если есть не пустое поле ридерс и юзер в нем не указан,
но при этом юзер указан в поле авторс, то юзер увидит документ.

 

[susinmn]

Совет первый и банальный - внимательно читать хелп. По существу:
1. Если в ACL ставить уровень доступа editor, то использование полей authors теряет смысл, поскольку эти поля влияют только на пользователей с уровнем доступа author. Editors могут править ВСЕ документы, которые они видят.
2. Если в документе нет полей authors/readers, его видят все, в т.ч. пользователи с уровнем доступа в ACL reader. Если поля есть, то документ видят только те, кто в них перечислен явно, через группы либо через роли. Кто не указан - не видит. В частности, если в них не указан сервер, то документы он не увидит и не будет их реплицировать.

1. По-моему, смысл не теряется. Если в ACL LNAddress*у ставить уровень доступа editor, то LNAddress видит и редактирует только public документы. т.е. если в документе в поле типа readers и authors прописать не LNAddress(если поле типа readers будет пустым или "*" или в нем будет прописан один из элементов @UserNameList или роль даной бд, которая есть у LNAddress либо поля типа readers не будет, то LNAddress будет видеть этот документ;
если поле типа authors будет ..., то LNAddress будет редактировать этот документ), ну а скажем "1"<>LNAddress, то LNAddress не увидит и не услышит)
2. Если в ACL LNAddress*у ставить уровень доступа reader, то максимум что он сможет, это почитать public документы, если поле типа readers будет...

 

[nvyush]

1. По-моему, смысл не теряется. Если в ACL LNAddress*у ставить уровень доступа editor, то LNAddress видит и редактирует только public документы. т.е. если в документе в поле типа readers и authors прописать не LNAddress(если поле типа readers будет пустым или "*" или в нем будет прописан один из элементов @UserNameList или роль даной бд, которая есть у LNAddress либо поля типа readers не будет, то LNAddress будет видеть этот документ;
если поле типа authors будет ..., то LNAddress будет редактировать этот документ), ну а скажем "1"<>LNAddress, то LNAddress не увидит и не услышит)
2. Если в ACL LNAddress*у ставить уровень доступа reader, то максимум что он сможет, это почитать public документы, если поле типа readers будет...

По поводу 1 - если у пользователя в ACL уровень доступа Editor, а в документе он есть в поле Readers, но его нет в поле Authors, то он всё равно сможет редактировать документ. Ограничение доступа на редактирование документов с помощью полей Authors действует только на пользователей с правами в ACL на уровне Author, поэтому я и говорю, что использование полей Authors для пользователей с правами Editor теряет смысл.

 

[ToxaRat]

вообще-то можно реализовать всё что угодно и закрыть любой документ
Например повесив на формы таймер + УИ, и по опросу таймера закрыть что угодно - делал так в примере когда у меня какой нить пользователь зависал в доке в режиме редактирования на пол часа, когда другие тоже хотят что нибудь рихтануть - установка таймера на запрос раз в пол часа решает данную проблему на ура

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

 

[PaVaP]

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

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