Can prepared emails get the section the submission was sent to?

Hello @asmecher,

Thanks again!!
That’ll do it…

As I’m creatively using sections as Book Titles, it help automate even more the process…

Hi @asmecher, the {$sectionName} token is no longer working in prepared e-mails. We’re in OJS 3.1.2.4. It used to work, but now is not rendering the appropriate section name in emails sent from the system. Any idea why?
thanks
Christie

Hi @Christie_Hurrell,

What email template are you editing? The {$sectionName} variable won’t be available to all email templates – just the ones that are always used with respect to a specific submission. (That excludes, for example, the NOTIFICATION template, which is used sometimes in regards to a specific submission, and sometimes not.)

Regards,
Alec Smecher
Public Knowledge Project Team

Thanks @asmecher – this is the Review Request template.
Christie

Hi @Christie_Hurrell,

The {$sectionName} variable should work without problems in the REVIEW_REQUEST email template. Is it not being replaced at all, or being replaced with a blank, or something else?

Regards,
Alec Smecher
Public Knowledge Project Team

Hello all,
@Christie_Hurrell,

I believe that if section names are hidden, the template may not get it??
@asmecher may answer this with more propriety, but I believe that may be the case.
Check your section configurations and hide it from the About pages only and see if the {$sectionName} variable appears.

Thanks @asmecher and @ramon for your responses. The variable is not being replaced at all. And the relevant sections are not hidden.
Christie

Hello @Christie_Hurrell ,

Strange… have you checked for any typos?
I usually find I mistype variable names constantly. There may be a space or missing letter, but we read it correctly…

Also, check if you have added the variable to the correct e-mail template.There are multiple REVIEW_REQUEST templates in OJS 2. I’m not sure about OJS 3…

Any news on this? I’m seeing the same: in the SUBMISSION_ACK template, {$sectionName} is just resolving to the empty string. Yet, no sections have been hidden. At least, not that I’m aware of: none of these boxes are ticked:
2020-09-10 08_57_10-Journal Settings

Unless the “hiding” happens at another place I should check?

I’m sure this used to work before, but apparently, it doesn’t any longer in 3.2.0.3?

Best,

Ron

Hi @rvdb,

What version of OJS are you using? (Please include this in your posts.)

Regards,
Alec Smecher
Public Knowledge Project Team

Hi @asmecher,

I thought I had mentioned it, apologies is it wasn’t clear: I’m running OJS-3.2.0.3.

Best,

Ron

Hi @rvdb,

Sorry, I missed that in your above post.

This has already been fixed in Submission::getSectionTitle doesn't return any value · Issue #6102 · pkp/pkp-lib · GitHub for release in OJS 3.2.1-2. For OJS 3.2.1-0/3.2.1-1, you should be able to apply pkp/pkp-lib#6102 Remove broken/little-used section data fetches from … · pkp/ojs@e536fd7 · GitHub – I suspect it could also be applied to 3.2.0-3, but YMMV.

Regards,
Alec Smecher
Public Knowledge Project Team

Hi @asmecher,

After having applied pkp/pkp-lib#6102 Remove broken/little-used section data fetches from … · pkp/ojs@e536fd7 · GitHub, I can confirm that {$sectionName} now resolves correctly in the SUBMISSION_ACK template. Before, it resolved to the empty string, so this seems to be solved.

Yet, in the REVIEW_REQUEST template, this variable isn’t resolved at all: {$sectionName} just comes out literally as {$sectionName} in the email text.

Notice, how this template seems to behave differently: whereas SUBMISSION_ACK previously tried to resolve {$sectionName} (which failed and produced an empty string), in the REVIEW_REQUEST template, no resolution seems to take place at all for the {$sectionName} variable. All other variables in that template ({$reviewerName}, {$submissionTitle}, {$contextName}, …) are resolved correctly, though.

This was tested on my dev instance, running OJS-3.2.0.2.

Best,

Ron

Hi @rvdb,

Could you look over the template closely for typos, e.g. capitalization differences or extra spaces? The same code should be responsible for populating {$sectionName} in both cases.

Regards,
Alec Smecher
Public Knowledge Project Team

Hi @asmecher,

I don’t see any difference. To make sure, I’ve pasted the same text in both templates:

Thank you for submitting the manuscript, “{$submissionTitle}” to the {$sectionName} section of {$contextName}.

…and this is what I get:

…in the SUBMISSION_ACK email:

Thank you for submitting the manuscript, “test” to the review section of TestJournal.

…in the REVIEW_REQUEST email:

Thank you for submitting the manuscript, “test” to the {$sectionName} section of TestJournal.

Best,

Ron

Apologies for bringing up an old conversation, but I am wondering if this issue has been resolved? I am having the same issue.
For our Review_Request email, I type
Thank you for submitting the manuscript, “{$submissionTitle}” to the {$sectionName} section of {$contextName}.

…I get

Thank you for submitting the manuscript, “test” to the {$sectionName} section of TestJournal.

We are currently using OJS 3.2.1.4.

Hi @hickeygamez,

I don’t think the content of that message is right - you note that it’s for review request but the text is clearly for submission acknowledgement - can you clarify which template you mean?

-Roger
PKP Team

Hi Roger,

This is for the review_request template.

I was just using that as an example to show that all the other variables seem to work, just not {$sectionName}

When I type the same message in the in the SUBMISSION_ACK template, {$SectionName} displays the appropriate section. However, when I copy and paste it to the review request template, the variable i{$sectionName} doesn’t change. It literally says {$sectionName} in the email text.

We’d like reviewers to know if they are being asked to review a submission for a large section (Major Contributions, Review Papers, etc) or a smaller one (Brief Reports, Commentary, etc) as it tends to deter reviews from even clicking the link if they feel overwhelmed by the task.

Hi @hickeygamez

I spoke with one of our developers who had this to say:

…that would only show up if it was used in the default language of a template. A variable may be supported but not used in the default template.
(And before you ask, no there’s no easy way to know what variables are supported for what template. That’s what we’re working on for 3.4!

So, effectively, you can’t just use the variables in any template - they have to have been part of the default template, so that may explain why this isn’t working. But, as noted, there may be better support for this in a future version.

Best regards,

Roger
PKP Team