Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature/email secretary after decisions #582

Merged
merged 6 commits into from
Nov 23, 2023

Conversation

EdoStorm96
Copy link
Contributor

Some fixes for a two small issues.

the fix for #581 is pretty self explanatory.

For the issue #563, I updated the update_go() of Review, as Ty suggested. Please check if this is in the correct spot ... In my testing this works as expected.

Furthermore, I'd appreciate feedback on the text of the e-mail. It's pretty bare bones, but gets the job done, with an overview of all decisions.

PS. I accidentally blacked review_utils.py, but undid it, because it made the diff unreadable.

Copy link
Member

@tymees tymees left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice quick turnaround lol :)

Two small errors, otherwise: looks great!

About the email: looks fine; during the meeting we all agreed the contents should not matter that much, the subject is more important.

"decisions": review.decision_set.all()
}
msg_plain = render_to_string("mail/all_decisions_notify.txt", params)
send_mail(subject, msg_plain, settings.EMAIL_FROM, [secretary.email])
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As per #563:

[..] FETC npm (not users!) [..]

Thus, the recipient should be the general fetc email ;)

Comment on lines 312 to 314
subject = _("FETC-GW {}: alle beoordelingen toegevoegd").format(
review.proposal.committee_prefixed_refnum(),
)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're translating the string, but not adding any translations...

Honestly, as the email is not translated, I'd just drop the _([..]) tag altogether

{% for decision in decisions %}
Beoordelaar: {{ decision.reviewer.get_full_name }}
Beoordeling: {{ decision.get_go_display }}
Opmerkingen: {{ decision.comments|default:"geen"|safe }}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewer comments can be hundreds of words. I think this table is a really cool addition, but the actual comments might be a bit much.

Rather, I would include a link to the review detail page, and also a link to the decide close review page.

"proposal": review.proposal,
"decisions": review.decision_set.all()
}
msg_plain = render_to_string("mail/all_decisions_notify.txt", params)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any translations existing in this input, e.g. decision.get_go_display, will render to the currently selected language.

If the user who triggered the update_go() happened to be set to English, all translations in here will also turn into English, which is a bit weird.

See proposal_utils.notify_local_staff() for an example of how we manually activate a language for email sending, and then reset it afterwards.

@EdoStorm96 EdoStorm96 requested review from miggol and tymees November 21, 2023 15:21
Copy link
Member

@tymees tymees left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One tiny tweak left, and then it's GTG

You don't have to re-request review from me if you fix that tiny detail

Comment on lines 329 to 330
send_mail(subject, msg_plain, settings.EMAIL_FROM, ["[email protected]"])

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I should've clarified; you should use settings.EMAIL_FROM as the recipient.

It's kinda weird, I know, but EMAIL_FROM is the NPM email. Hardcoding this is a bad idea, as names (and thus, emails) in the UU tend to change. It's better if we only have to change the one value when that happens

@EdoStorm96 EdoStorm96 merged commit 198d1f4 into develop Nov 23, 2023
2 checks passed
@EdoStorm96 EdoStorm96 deleted the feature/email_npm_after_decisions branch November 23, 2023 12:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Use fullname for reviewers on the 'Details' page Warning assessments complete
3 participants