When creating the "Message body" for the "OPAC_REG_VERIFY" email template, the only available options should be <<OPACBaseURL>> and <<borrower_modifications.verification_token>>
Created attachment 144731 [details] [review] Bug 32500: Show only relevant message body option for OPAC_REG_VERIFY This patch changes the "Message body" options for the OPAC_REG_VERIFY notice so that only the relevant "borrower_modifications.verification_token" appears as an option. Tables like branches, biblio, biblioitems, items, borrowers, and issues aren't passed to OPAC_REG_VERIFY at processing time. The only table passed is "borrower_modifications", and only the token is the relevant field there.
Created attachment 144846 [details] [review] Bug 32500: Show only relevant message body option for OPAC_REG_VERIFY This patch changes the "Message body" options for the OPAC_REG_VERIFY notice so that only the relevant "borrower_modifications.verification_token" appears as an option. Tables like branches, biblio, biblioitems, items, borrowers, and issues aren't passed to OPAC_REG_VERIFY at processing time. The only table passed is "borrower_modifications", and only the token is the relevant field there. Signed-off-by: Frédéric Demians <f.demians@tamil.fr>
Why not add_fields on borrower modifications? Maybe you want to change the notice and show some of the fields that have been entered? This seems too drastic?
(In reply to Marcel de Rooy from comment #3) > Why not add_fields on borrower modifications? Maybe you want to change the > notice and show some of the fields that have been entered? This seems too > drastic? Upon reviewing the borrower modifications table, I'm not sure why I thought verification_token should be the only field. It doesn't really make much sense. My concern about add_fields() is that it would have access to the "password" field. It looks like it's the hashed password rather than the clear text password, but it should probably be excluded. But it looks like we could modify the "get_columns_for" function in letter.pl to exclude that field. I'll have another think about this one another time!
I haven't reviewed bug 32221 in context but I think it might cover off the issue here...