Open jonasraoni opened 3 months ago
Also, it was unexpected for me that the email editor is working differently from the one at the Workflow > Emails, where the variables are displayed in plain text and the icon to insert variables is different:
Assuming it's a work in progress.
@jonasraoni, is at an old template that should be replaced during upgrade?
Apart from it, reviewAssignmentUrl isn't exposed deliberately: https://github.com/pkp/pkp-lib/blob/3536404e545ef14ffed6fbe390916d74fc1c875c/controllers/grid/users/reviewer/form/ReviewReminderForm.php#L89
Also, it was unexpected for me that the email editor is working differently from the one at the Workflow > Emails, where the variables are displayed in plain text and the icon to insert variables is different
I recall variables are replaced before being sent
The new wording for the template is different: https://github.com/pkp/ojs/blob/main/locale/en/emails.po#L251 I assume, the old template had custom modifications and that's why it was preserved, right?
@Vitaliy-1 this is a mix of UI and backend issue.
The UI of the email editor is different, the email editor that appears when I click on the button Submission > Workflow > Review > Send Reminder
has:
+
button, which allows me to select variables, but only the URL
is available (it refers to the {$passwordResetUrl}
.On another hand, if I access the email editor of the template, at Workflow > Emails > Add and edit templates
, then it has:
+ Insert content
buttonBut I also had another issue in this part, I tagged you here: https://github.com/pkp/pkp-lib/pull/9151/files#r1636973735
I think it might need some extra review, so I just fixed locally by replacing the variable passwordResetUrl
by lostPasswordUrl
on the template.
One note about this template that might help clear up some confusion: For any templates that use access keys (3.4.0 and older) or invitations (3.5.0 and newer), we intentionally didn't present the full URL to the editor for viewing. That's because doing so would expose the secret key that goes out with the email. We need to prevent the editor (or anyone else) from intercepting these. Therefore they're coded so that the variable replacement happens right before the message gets delivered.
That said, it would be nicer to show something nicer than {$someVariableName}
in the interface while editing the email.
@jonasraoni @Vitaliy-1 @asmecher After a detailed review and attempts to recreate the concerns discussed about the email template behavior in OJS 3.4.0, I've observed the following: the Review Reminder functionality directly accesses predefined templates that include variables like {$recipientName}
, {$submissionTitle}
, and {$reviewDueDate}
. These variables are dynamically replaced with actual data in the editor and the template does not display raw variables but shows the actual data:
however when accessing template through Workflow > Emails > Add and edit templates
variables are shown in their placeholder form ({$variableName}) this approach seems to be by design which I think is intended for administrative purposes and allowing template customization and a clear understanding of what data will be dynamically inserted.
Describe the bug The email variable
reviewAssignmentUrl
for the template REVIEW_REMIND (review reminder) is not being passed to the UI.I also think the constants/classes should be renamed to "review reminder".
To Reproduce
What application are you using? OJS 3.4
Additional information