Функционал Портала Ax2009

[Narayana]

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

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

[nikos2001]

Эта система регистрации досталась в наследство еще с портала AX 3.0, когда еще не было входа через домен. С годами микрософт ничего там не меняла, и весь этот сумбур так и перешел в 2009. Потому и документации не существует. Короче без серьезной доработки "все это" использовать нельзя.

[Narayana]

Цитата:

Сообщение от nikos2001

Эта система регистрации досталась в наследство еще с портала AX 3.0, когда еще не было входа через домен. С годами микрософт ничего там не меняла, и весь этот сумбур так и перешел в 2009. Потому и документации не существует. Короче без серьезной доработки "все это" использовать нельзя.

Стало быть, документация отчасти должна существовать в Ах 3.0?
А на Ах2012 переделали, не знаете?

[nikos2001]

На AX2012 не знаю, но там и сам процесс регистрации пользователей отличается (для входа можно использовать не только домен). Документация из AX3, если она есть, будет релевантна только в части создания клиента в аксапте, который уже привязан к пользователю. Процесс создание самого пользователя в 2009, естественно, отличается от 3.0

[Narayana]

Цитата:

Сообщение от nikos2001

На AX2012 не знаю, но там и сам процесс регистрации пользователей отличается (для входа можно использовать не только домен). Документация из AX3, если она есть, будет релевантна только в части создания клиента в аксапте, который уже привязан к пользователю. Процесс создание самого пользователя в 2009, естественно, отличается от 3.0

Ну, да... ну, да.
То есть, насколько я понял, есть два разных пункта меню с одним названием "Регистрация". Один для создания клиента, - он работает. То есть, дает возможность отправить заявку на регистрацию.
А второй отображает ту же страницу, но с названием "Создать нового пользователя".

При этом, в одном случае используется Managed content EPCSSCustSignUpGuest, в другом EPCSSCustSignUpUser.
Но, оба они как объект используют контрол EPCSSCustSignUp.
Разница только в том, что у Guest есть конфигурационный ключ EP, а у User никакого нет.
Интересно, что бы это значило?
То, что User должен появляться при самых малых правах при заходе анонимом?

[nikos2001]

Идея в том, что с помощью EPCSSCustSignUpUser запрашивается первичный доступ в AX. Администратор AX должен будет вручную создать пользователя в AD и AX, и с помощью формы ECPCustSignUpRequest привязать его к создаваемому на этой же форме клиенту и контакту.

С помощью EPCSSCustSignUpUser запрашивается доступ клиентов на получение дополнительных логинов. Например, если клиент имеет несколько филиалов и каждый филиал должен иметь свой логин. В этом случае Администратор AX должен вручную создать пользователя в AD и AX и с помощью формы ECPCustSignUpRequest и сделать привязку пользователя к создаваемому там же новому контакту.

[Narayana]

Цитата:

Сообщение от nikos2001

Идея в том, что с помощью EPCSSCustSignUpUser запрашивается первичный доступ в AX. Администратор AX должен будет вручную создать пользователя в AD и AX, и с помощью формы ECPCustSignUpRequest привязать его к создаваемому на этой же форме клиенту и контакту.

С помощью EPCSSCustSignUpUser запрашивается доступ клиентов на получение дополнительных логинов. Например, если клиент имеет несколько филиалов и каждый филиал должен иметь свой логин. В этом случае Администратор AX должен вручную создать пользователя в AD и AX и с помощью формы ECPCustSignUpRequest и сделать привязку пользователя к создаваемому там же новому контакту.

А вы не знаете, где хранится пароль для нового пользователя, который генерится системой? Отдельной таблицы, вроде, нет.
При этом система генерит пароль, который высылает пользователю по почте со словами "смените при первом входе", но место, где пользователь может сменить пароль, я так и не нашел. Тем более, что, для того, чтобы сменить пароль традиционным способом, нужно лезть на контроллер домена.
Удобнее, конечно, чтобы перед отправкой письма пользователю регистратор вводил бы пароль доменной учетной записи в поле заявки на регистрацию и из него бы система отправляла пароль вместе с логином.
А так получается, что пароль без логина высылается первым письмом, а логин вторым.

И еще одна очень неприятная вещь...
У пользователей интернета нет культуры ввода логина в окошке запроса логина винды вместе с именем домена. Тем более, что отдельного поля для имени домена в форме запроса логин-пароля сейчас нет (было в 2003 сервере).
Соответственно, это вызывает у пользователей смущение.
А если человек не айтишник, то, вообще, не догадается, что запись должна быть "домен\логин" или логин@домен.
Я решил переделать письмо новому пользователю, чтобы логин представлял собой уже запись с доменом, но боюсь, что это все-равно вызовет какой-то процент отказов от регистрации.