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

Assignment email notification registration #2028

Merged
merged 3 commits into from
Jul 19, 2024

Conversation

thecalcc
Copy link
Contributor

SDBELGA-818

@thecalcc
Copy link
Contributor Author

Merge after client-core is updated, and package-lock.json is updated in planning

notifications: {
'assignment:notification': {
type: "email",
label: superdesk.localization.gettext('Send Assignment notifications')
Copy link
Member

Choose a reason for hiding this comment

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

We should phrase it better. Notification name shouldn't have verbs in it. Also I'm thinking it would be good to have a description where we'd specify under what circumstanced does the notification gets sent.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It's not a name, rather a label. We display that label in settings view

Copy link
Member

Choose a reason for hiding this comment

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

It should be a name though. I use the word name and label interchangeably. Extension point may expose the available notifications and their names, but the extension should not be concerned about where will that name be used. Thus we should try to use a universal name like "assignment" and then we could use it in various different cases e.g.
gettext('Send {{type}} notifications', {type: 'assignment'}),
gettext('Pause {{type}} notifications', {type: 'assignment'})
etc.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

got it, that makes sense considering name and label is different. But for your example, it doesn't make sense in general, because actual label data is coming from the backend - registered for each notification type, so I'd even say it's future proofing to have name/type since we have all necessary data from the BE.

Copy link
Collaborator

Choose a reason for hiding this comment

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

gettext('Send {{type}} notifications', {type: 'assignment'}) would not get a translation for the word assignment

Copy link
Member

Choose a reason for hiding this comment

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

I am future proofing a bit you could argue, but this is the point with the extensions API. To keep it small and well designed and change it rarely. The label is not a huge thing though, let's go with your version.

You're correct @MarkLark86. Here's the translated placeholder ;)

gettext('Send {{type}} notifications', {type: gettext('assignment')})

Copy link
Member

@tomaskikutis tomaskikutis left a comment

Choose a reason for hiding this comment

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

fix CI

@thecalcc thecalcc merged commit 3303157 into superdesk:develop Jul 19, 2024
12 checks passed
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.

3 participants