[DZHETIGAPA]

вопрос в названии темы. Как сделать регистрацию-авторизацию по имейлу? Конечно есть варианты, например, вместо логина писать имейл.

Но как это сделать правильно?

[kroxa]

была тема востановить пароль по логину
собственно это уже внедрили в последнею версию уми, можете сами подправить нужный файл Авторизация в системе как по логину, так и по адресу e-mail прозрачно и незаметно для пользователя
смотрите тут: http://www.umi-cms.ru/files/hotfixes/18124.patch

[DZHETIGAPA]

Спасибо. Обязательно гляну.

[DZHETIGAPA]

Мне нужно было организовать еще и регистрацию, где нет поля логин. Это сделал путем корректировки файла __register.php.

Вопрос: как сделать, чтобы мои корректировки не затерлись при обновлении?

[admin]

просто сделай, js заполнение скрытого поля логин, который заполняется одновременно с полем email

или скопируй макрос register_do, переделай его, положи его в __custom.php модуля users пропиши на него права в созданном тобой файле permissions.custom.php в этом же модуле и при обновлении он не перезатрется

[DZHETIGAPA]

Укажите, что я делаю не так.. В файл class/midules/users/__custom.php заношу отредактированный метод register_do. Создаю файл permissions.custom.php в этой же папке, пишу  туда след строку:

Код: [Выделить]

<?php
	$permissions = Array(
		'registrate' => Array('registrate_do'),

	);
?>

Но регистрация по имейлу в таком случае не происходит. Где мой косяк?

[admin]

попробуй назвать свою кастомную функцию не так как системную, например registrate_do_cust

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

[Vladimir]

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

Лично я обычно в таких случаях просто отправляю автора идеи регистрации по email по известному котокому адресу с основанием "в ЮМИ логин обязателен и не равен email. Без вариантов". В конце-концов, если этого не было в ТЗ (а в моиз случаях этого не было указано как обязательное требование), то вы не обязаны этого делать.

[Vladimir]

Пока писал ответили.
Логика такая: ЮМИ ищет запрашиваемый метод в class.php. Если не находит, проверяет подключаемые абстрактные классы и ищет там. __custom подключается в последнюю очередь

[admin]

к слову стоит сказать что с версии 2.8.4.4 добавлена такая вещь

Авторизоваться в системе теперь можно как по логину, так и по e-mail прозрачно для пользователя (решение из коммьюнити UMI.Hub).

[Vladimir]

Авторизация и регистрация не одно и тоже.
Что-то я не помню в 2.8.5 в методе регистрации таких вещей. логин - отдельно проверяется, почта - отдельно, и оба - обязательные.

[admin]

Лично я обычно в таких случаях просто отправляю автора идеи регистрации по email по известному котокому адресу с основанием "в ЮМИ логин обязателен и не равен email. Без вариантов". В конце-концов, если этого не было в ТЗ (а в моиз случаях этого не было указано как обязательное требование), то вы не обязаны этого делать.

Владимир, нельзя же так к клиенту, для них же стараемся)
Это изменение совсем не криминальная вещь, все что нам надо это, написать 3 обработчика событий

один будет срабатывать после регистрации (событие "users_registrate")
второй после изменения настроек пользователя (событие "users_settings_do")
третий при создании или изменении настроек пользователя в админке (события "systemCreateObject" и "systemModifyObject")

все обработчики будут дублировать email в поле логин.

Шаблоны для регистрации и редактирования настроек надо немного изменить. сделать поле логин скрытым и подставлять в него:
1.при регистрации: уникальное значение (например текущее время в миллисекундах), чтобы система не ругалась
2. во всех остальных случаях уже существующее значение из объекта пользователя

вроде ничего не забыл, и такой вариант предусмотрел все возможные вопросы и проблемы на пути регистрации только с email'ом

[DZHETIGAPA]

Честно говоря не вижу никаких сложностей в редактировании методов settings_do, registrate_do. Если вы не можете удовлетворить минимальные требования клиента, то зачем тогда браться за разработку вообще?

Насчет переопределения методов. В большинстве админок есть определенные файлы или папки, где переопределяются методы, при этом не надо менять название метода. Но в юми видимо другая система. Тогда, админ, у меня вопрос. Например, сделаю все как ты говоришь, назову метод по-другому. но откуда юми узнает, что при регистрации нужно вызывать мой метод с моим названием, а не стандартный метод registrate_do? Вот этого как-то не понимаю. Фактически мне надо переопределить два метода: settings_do, registrate_do

Как сделать такое? Что-то не понимаю...

[admin]

ты можешь переопределить их и ссылки в шаблонах переделать руками (ссылку то на регистрацию ты в шаблоне прописываешь)

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

[Vladimir]

ЮМИ ничего сама не узнает, пока вы явно не укажете ей какой метод вызывать.Т.о. ссылка на страницу регистрации у вас будет не /users/registrate/, а /users/new_registrate/  Аналогично заменить везде название системного метода на свой.

Ну а что считать минимальными требованиями - вопрос дискуссионный.