ProcaWeb.ConfirmController (proca v3.4.1)
Controller processing two kinds of confirm links:
- supporter confirm (double opt in in most cases)
- generic Confirm
Link to this section Summary
Functions
Handles a generic accept/reject of a Confirm.
Handle a supporter confirm link of form: /link/s/123/REF_REF_REF/accept
Link to this section Functions
confirm(conn, params)
Handles a generic accept/reject of a Confirm.
Link of form: /link/1234567/accept
Optionally with query params:
- email - if this Confirm was created for a recipient with email
- id - if this Confirm was created for particular object id (schema determined by Confirm operation)
- redir - query param to redirect after accepting/rejecting.
double_opt_in(conn, params)
redirect_url(action, args)
supporter(conn, params)
Handle a supporter confirm link of form: /link/s/123/REF_REF_REF/accept
Optionally can contain: ?doi=1 - for a double opt in
This is a special case where we do not use Confirm model. Instead, we use the ref known to supporter. This way we do not have to create so many Confirm records when org is using double opt in.
This path optionally takes a ?redir query param to redirect after accepting/rejecting.
Handle double opt in link of form: /link/d/1234/REF_REF_REF
It will double opt in Supporter email_status. This will just change the email_status, and possibly send the supporter_updated event. Can be useful to do a double opt in when we have actually already processed the action.