Лучшие практики: как внедрить систему приглашений в Zend Framework?

Question

Я реализовал большую часть функциональности, теперь я застреваю ...

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

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

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

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

Надеюсь, все это имеет смысл. Любые идеи будут оценены.

Answer 1

Я использую бумагу и ручку, чтобы представить, чего я действительно хочу Если поток ясен, я думаю, что вы можете сделать это;)

Answer 2

Я бы использовал валидатор внутри вашей формы, поэтому адрес электронной почты проверяется по вашим уже сохраненным электронным письмам. Так что не должно быть повторяющейся записи. Также я бы реализовал действие, которое перечисляет все ваши введенные учетные записи и время создания и активации в красивой таблице. Конечно, действие и представление будут поддерживать разбиение на страницы, так что вы можете легко перемещаться по вашим данным. Если запись еще не активирована, должна быть ссылка, возможно, и значок, на действие «Отправить по электронной почте» для этой специальной записи. И еще одно действие, которое отправляет письмо всем еще не активированным записям, было бы удобно. И последнее, но не менее важное: я бы реализовал действие по отчетности, чтобы я мог легко понять, что происходит.

Answer 3

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

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

Мне также нравится идея, что другие уже упоминали о «Переслать приглашение», особенно реализацию philipnorton42.

Answer 4

Хм, я бы создал представление, где видны все «Активации», с кнопкой, чтобы просто отправить приглашение? Без изменения записи внутри базы данных.

Answer 5

Я бы сказал, что Вальтер прав, вам, возможно, нужно нарисовать то, чего вы хотите достичь.

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