Рекомендации: как реализовать систему приглашений в Zend Framework?

Question

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

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

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

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

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

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

Answer 1

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

Answer 2

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

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

Answer 3

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

Answer 4

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

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

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

Answer 5

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