Переименование учетных записей пользователей Axapta

[vesna dba]

Есть ли возможность переименовать учетную запись пользователя Axapta?
Если да, то как?

[mazzy]

Цитата:

Сообщение от vesna dba

Есть ли возможность переименовать учетную запись пользователя Axapta?
Если да, то как?

К сожалению, корректного способа нет.
Код пользователя записывается во многие места - кто одобрил, кто ответственный, прва на счета и т.п.
Но самое главное, код пользователя записывается в поля Created By, Modified By

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

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


Что можно попробовать в ax3.0:
Способ 1. принудительно применить метод renamePrimaryKey на таблице UserInfo (не пробовал, за последствия не отвечаю)
Способ 2. В параметрах пароля указать Идентификация входа в систему = Имя пользователя (вместо стандартного Пользователь). В этом случае в окошко с логином пользователи должны вводить не код, а то, что написано у них в поле Имя (в параметрах можно установить и Сетевое имя пользователя).

В ax4.0 используется только windows Authentication. Поэтому менять особо нечего. Но код пользователя и в 4ке изменить нельзя.

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

[vesna dba]

Спасибо за ответ!

Да, знаю что во многих местах код пользователя фигурирует.
Было бы удобнее чтобы разработчики сделали учетки через SID например, как в ActiveDirectory.
Но не всегда удобнее - значит лучше.

Ок. Извращаться не будем. Не критично.

[mazzy]

Цитата:

Сообщение от vesna dba

Было бы удобнее чтобы разработчики сделали учетки через SID например, как в ActiveDirectory.

Так сделали в 4ке.

Нафиг! SID привязаны к домену.
Чтобы без неудобств работать с SID'ами нужно две вещи:
1. чтобы все входили в домен (и внутренние пользователи, и консультанты, и внешние)
2. чтобы домен не менялся (т.е. никаких домашних заготовок и т.п.)

В общем, не уверен.
Я как только начинаю читать стоны пор то как перенести пользовательскую информацию из домена в домен...
Как только начинаю понимать, что и мне это предстоит...

[vesna dba]

Без работы не останемся!

[AndyD]

Я бы не сказал, что переименование ключа для таблицы пользователей в тройке запрещено.
По крайней мере, если посмотреть код метода renamePrimaryKey формы SysRecordInfo, то видно, что такая возможность предусмотрена

if (common.TableId == tableNum(UserInfo))
{
	password = element.newPassword(dialogField.value());
}
...
if (common.TableId == tableNum(UserInfo))
{
	common.(fieldNum(userInfo, password)) = password;
	common.update();
}

Если посмотреть метод Info() той же формы, то увидим такой код

dictField2  = new DictField(tableNum(userInfo), fieldNum(userInfo, password));

if (... ||
	(common.tableId == tableNum(UserInfo)	  && common.(fieldNum(UserInfo,	  Id)) == #AdminUser) || ...
	(common.tableId == tableNum(UserInfo)	  && dictField2.rights() < AccessType::Delete) || ...
	(common.tableId == tableNum(UserInfo)	  && !domainAccess()) || 
	...)

Т.е. переименовывать ключ для таблицы userInfo можно для любых пользователей, кроме Admin. Делать это может пользователь с правами не ниже права на удаления для поля Password (???) с включенным доменом.

Самое непонятно для меня - как установить право на удаление для поля Password.

Что касается четверки, то там такого требования нет (там и поля-то такого нет, оно теперь del_password) и переименовывать в домене можно свободно