NotesDocument.InitiallyModified

[Gandliar]

Всем привет!

Подскажите, использует ли кто, и каковы результаты.
Судя по всему, это дата-время модификации документа на диске.
По опытам получается как-то так:

1. Открывается документ на чтение первым пользователем.
2. В это время второй пользователь модифицирует документ, сохраняет на диск.

При нажатии кнопки редактировать первым пользователем, дата doc.Initiallymodified будет равна дате последней модификации документа на диске (в приведенном примере - дата время модификации вторым пользователем)

Таким образом при переводе ранее открытого документа в режим редактирования можно проверять

If Not doc.Lastmodified = doc.Initiallymodified Then
MsgBox "Документ отредактировал кто то другой!"
End if

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

Если кто использует, подскажите, все ли так?

Заранее благодарю.

 

[alexas1]

Всем привет!

Подскажите, использует ли кто, и каковы результаты.
Судя по всему, это дата-время модификации документа на диске.
По опытам получается как-то так:

1. Открывается документ на чтение первым пользователем.
2. В это время второй пользователь модифицирует документ, сохраняет на диск.

При нажатии кнопки редактировать первым пользователем, дата doc.Initiallymodified будет равна дате последней модификации документа на диске (в приведенном примере - дата время модификации вторым пользователем)

Таким образом при переводе ранее открытого документа в режим редактирования можно проверять

If Not doc.Lastmodified = doc.Initiallymodified Then
MsgBox "Документ отредактировал кто то другой!"
End if

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

Если кто использует, подскажите, все ли так?

Заранее благодарю.

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

 

[Gandliar]

Если кто то редактирует - то документ "блокируется" и другой на редактирование не откроет.
Тут вопрос в другом, первый пользователь открыл на чтение, а второй успел заблокировать, изменить, разблокировать.
При этом первый все еще сидит в режиме чтения.

И тут два варианта
а) выносить кнопку заблокировать в меню кнопок и всегда переоткрывать документ при блокировке
б) сделать проверку ласт = инициал, и если не равно - в этом случае переоткрыть и использовать обычное редактирование документа, естественно используя блокировку.

просто я раньше не использовал конструкцию б, так как про doc.Initiallymodified мало инфы. и неясно какие могут быть подводные камни.

 

[Gandliar]

Вот подводный камень нашелся, lastmodified бывает больше initialModified, так что проверка будет
если иницал>last значит переоткрывать

 

[VladSh]

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

При UI-сохранении Lotus выведет сообщение о конфликте. При BE-сохранении nd.Save(False, False) не сохранит документ и вернёт False.

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

 

[Gandliar]

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

 

[alexas1]

я только порассуждал "на тему...")

И вообще, зачем давать редактировать док сразу нескольким людям?

логично

а изменения вносить только с помощью диалогов.

ну, как один из вариантов
сохранять UI методом логично ток новый док, да и то, только, в клиенте

При BE-сохранении nd.Save(False, False) не сохранит документ и вернёт False.

Йес! вот тут и обрабатывай геморрой - предупреждай, переоткрывай или ещё чёнить))) раз позволяешь лезть в док толпой и не придумал бесконфликтную логику редактирования, а локи использовать - религия не позволяет)

 

[alexas1]

либо на основной док должны быть права у всех согласующих и т.п.

а как иначе, если они с доком работают, если совсем всё по-простому
а "согласование/ознакомление/исполнение ..." и прочая можно хранить в доке описывающем текущее состояние бизнеспроцесса, котрый правится, как раз, северным агентом
но то вопрос архитектуры СЭД

 

[Gandliar]

1. не всегда удобно редактировать диалогбоксами. например чел использует инфу частично из письма и надо чтобы можно было переключатся между письмом, доком
2. вопрос был не разграничить доступ, с этим прекрасно справляются всякие блокировки

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

 

[alexas1]

"При BE-сохранении nd.Save(False, False) не сохранит документ и вернёт False."(VladSh)
... Ну, сохрани (в памяти) копию дока перед переходом в редактирование и сохраняй док "по полям" (в бэке, естественно) с контролем "чё было", например. Тут ты любую логику придумать можешь, при возникновении гемора

 

[VladSh]

2. вопрос был не разграничить доступ, с этим прекрасно справляются всякие блокировки

В 2003-м мы уже добились, чтобы параметры активностей ("отправок" на согласование/ознакомление/исполнение) хранились вне самого документа отдельными доками в отдельной БД, а также добились абсолютно бесконфликтной работы СЭД. И вот мы такие приходим в одну контору, ставим свою СЭД, а потом нас вызывает один из директоров и, показывая на сообщение "Документ заблокирован пользователем ...", говорит «Что за х...?! Каждый документ, проходящий через меня, стоит сотни тысяч долларов, и я должен ждать, пока какая-то "уборщица" не отпустит документ? Вы совсем ...?!» После этого у нас была полная полугодовая внутренняя переработка архитектуры ядра.
Суть:
1. Все изменения любого документа в коде идут не напрямую в NotesDocument.ReplaceItemValue и т.д., а через наш класс ImageDocument + ещё туча методов к нему.
2. Непосредственное сохранение документа NotesDocument.Save(False, False) происходит лишь в одном месте всего СЭД(!) - в методе Save нашего класса.
3. Если документ не удалось сохранить, то все действия на этой кнопке (ImageDocument.ReplaceItemValue(...), ImageDocument.RemoveItem(...) и т.д.) сохраняются в документ-"транзакцию" для этого UNID, который обрабатывается собственным транзакционным механизмом на сервере раз в 5 минут.
4. При открытии документа в UI поднимаются все невыполненные на данный момент "транзакции" и вносятся в документ виртуально, т.е. не сохраняя его, и добавляя в документ несохраняемое поле с количеством найденных запросов по этому документу.
5. При инициализации класса производится анализ на поле с количеством запросов, если оно = 0, то далее документ пытается заблокироваться. При любом неблагополучном ответе все изменения сразу же пишутся в новую "транзакцию" для этого UNID.

Т.о. пользователь, открыв документ:
1). Никогда не видит дебильных "Документ заблокирован".
2). Всегда видит самую свежую ситуацию, хотя технически изменения ещё не внеслись, т.к. некий болван мог открыть документ и заблокировать его на длительное время.
На своём уровне мы постарались во всех случаях, где это возможно, уйти от этого:
- дав открывать документы, идущие по маршруту, только в режиме чтения;
- закрывая или переоткрывая документы после нажатия на кнопки управления маршрутом (отправки и действий) - учитывая баг Лотуса, когда при использовании Soft-lock документ блокируется при даблклике по нему, даже не перейдя в режим редактирования;
- ограничив возможность вносить изменения только в диалогах.

 

[alexas1]

В 2003-м мы уже добились, чтобы параметры активностей ("отправок" на согласование/ознакомление/исполнение) хранились вне самого документа отдельными доками в отдельной БД, а также добились абсолютно бесконфликтной работы СЭД. И вот мы такие приходим в одну контору, ставим свою СЭД, а потом нас вызывает один из директоров и, показывая на сообщение "Документ заблокирован пользователем ...", говорит «Что за х...?! Каждый документ, проходящий через меня, стоит сотни тысяч долларов, и я должен ждать, пока какая-то "уборщица" не отпустит документ? Вы совсем ...?!» После этого у нас была полная полугодовая внутренняя переработка архитектуры ядра.
Суть:
1. Все изменения любого документа в коде идут не напрямую в NotesDocument.ReplaceItemValue и т.д., а через наш класс ImageDocument + ещё туча методов к нему.
2. Непосредственное сохранение документа NotesDocument.Save(False, False) происходит лишь в одном месте всего СЭД(!) - в методе Save нашего класса.
3. Если документ не удалось сохранить, то все действия на этой кнопке (ImageDocument.ReplaceItemValue(...), ImageDocument.RemoveItem(...) и т.д.) сохраняются в документ-"транзакцию" для этого UNID, который обрабатывается собственным транзакционным механизмом на сервере раз в 5 минут.
4. При открытии документа в UI поднимаются все невыполненные на данный момент "транзакции" и вносятся в документ виртуально, т.е. не сохраняя его, и добавляя в документ несохраняемое поле с количеством найденных запросов по этому документу.
5. При инициализации класса производится анализ на поле с количеством запросов, если оно = 0, то далее документ пытается заблокироваться. При любом неблагополучном ответе все изменения сразу же пишутся в новую "транзакцию" для этого UNID.

Т.о. пользователь, открыв документ:
1). Никогда не видит дебильных "Документ заблокирован".
2). Всегда видит самую свежую ситуацию, хотя технически изменения ещё не внеслись, т.к. некий болван мог открыть документ и заблокировать его на длительное время.
На своём уровне мы постарались во всех случаях, где это возможно, уйти от этого:
- дав открывать документы, идущие по маршруту, только в режиме чтения;
- закрывая или переоткрывая документы после нажатия на кнопки управления маршрутом (отправки и действий) - учитывая баг Лотуса, когда при использовании Soft-lock документ блокируется при даблклике по нему, даже не перейдя в режим редактирования;
- ограничив возможность вносить изменения только в диалогах.

Именно! Аналогичный подход, с точностью "до идеи" (кроме "диалогов")
"Документ заблокирован" - зло по определению, этим обязан занимацца "Искусственный Интеллект Грефа"))))

 

[Gandliar]

Оч круто!

А можно ссылку посмотреть визуально как настраивается маршрут документооборота? Или пару картинок?

 

[lmike]

3. Если документ не удалось сохранить, то все действия на этой кнопке (ImageDocument.ReplaceItemValue(...), ImageDocument.RemoveItem(...) и т.д.) сохраняются в документ-"транзакцию" для этого UNID, который обрабатывается собственным транзакционным механизмом на сервере раз в 5 минут.

Ссылка скрыта от гостей

есть в ODA, там свои раперы для основных объектов домины, НО нужно использовать либо хэпаги либо др. двиг поддерживающий ODA