И в полях карточек, где был указан данный сотрудник, теперь отображается "Значение недоступно", а задания, в которых он является исполнителем, вообще не открываются.
Пересоздание сотрудника ситуацию не исправит, так как в карточках хранится ссылка на запись сотрудника в справочнике, т.е. его идентификатор, а идентификатор нового сотрудника пусть даже с такой же фамилией и учетной записью будет совершенно другим.
К счастью, помимо перевыбора сотрудника во всех тысячах карточек, есть другое решение. Порядок действий следующий:
1. Найти идентификатор старого сотрудника. Это можно сделать, открыв xml карточки (Экспорт и печать - XML карточки) и из поля, в котором был указан данный сотрудник, скопировать идентификатор. Например, если сотрудник был указан в поле Зарегистровал, в xml нужно искать RegisteredBy в секции MainInfo.
Названия полей карточек вы можете узнать из документа "Описание полей стандартных карточек", входящего в комплект разработчика.
2. В базе DocsVision в таблице dvtable_{DBC8AE9D-C1D2-4D5E-978B-339D22B32482} найти вновь созданного сотрудника и заменить идентификатор в столбце RowID на ID, скопированный из xml.
Либо можно сделать то же самое, выполнив SQL запрос
UPDATE [dvtable_{DBC8AE9D-C1D2-4D5E-978B-339D22B32482}]
SET RowID='Старый ID'
WHERE LastName='Фамилия сотрудника'
где Старый ID - скопированный из xml идентификатор.
(Данный запрос подойдет только в том случае, если сотрудник с такой фамилией один. Если их несколько, необходимо использовать другое условие WHERE).
Позвольте вопрос про сотрудников. Как можно вытащить такую информацию:
ОтветитьУдалитьвыбираем подразделение DV и должны получить : всех его сотрудников (включая внутренние отделы) и группы в которые входит каждый сотрудник.
БП опубликован в одном из паков http://dvprofessionals.blogspot.com/2009/03/1.html
ОтветитьУдалитьА чем система оперирует при разграничении доступа на объекты с использованием локальных групп, таких как DocsVision Administrators например?
ОтветитьУдалитьНигде в базе не нашел записи данных групп, ни в справочниках ни в таблицах с настройками системы.
Очень часто при переносе ДВ с сервера на сервер и наличии разграничения доступа на объекты через эти локальные группы, от них остаются на новом сервере ДВ только нераспознанные системные SID.
Была идея в самом сиквеле сменить старые SID на новые, и восстановить работоспособность розданных прав, но менять то собственно и негде оказалось.
Должны же они как то отождествляться внутренним идентификаторам для хранения настроек доступа на объекты ДВ в дескрипторах безопасности?
Если подмена GUID сотрудника помогает, значит разрешения на объекты для сотрудников базируются на их GUID-ах, и именно они внедряются в дескрипторы безопасности в колонке SecurityDesc в таблице dvsys_security а не системные SID учетных записей?
Если в домене пересоздать учетную запись (в результате чего поменяется ее SID) то как на это отреагирует ДВ? Для чего исползуется значение SID-а в поле AccountSID в справочнике сотрудников?
И как разграничиваются функции таблиц dvsys_users и dbo.[dvtable_{dbc8ae9d-c1d2-4d5e-978b-339d22b32482}] которые хранят данные о пользователях? Судя по вашей статье "Некоторые системные таблицы в базе данных DocsVision" - dvsys_users это просто перечень-лог обращавшихся к навигатору пользователей?
Каждый объект, на который можно назначить права имеет т.н. дескриптор безопасности - описатель прав на него. Дескриптор - это объект типа CommonSecurityDescriptor (http://msdn.microsoft.com/ru-ru/library/system.security.accesscontrol.commonsecuritydescriptor.aspx). Все права в нем хранятся для SID'ов учетных записей. Поэтому, естественно, что если учетная запись удалена и создана с таким же названием новая, то поскольку у неё будет новый SID прав она иметь на старые объекты не будет. Механизм аналогичен правам на объекты в операционной системе.
ОтветитьУдалить