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

"sending unseen notifications as email" admin option(s) #1260

Closed
EngelPika32 opened this issue Aug 29, 2022 · 7 comments
Closed

"sending unseen notifications as email" admin option(s) #1260

EngelPika32 opened this issue Aug 29, 2022 · 7 comments

Comments

@EngelPika32
Copy link

EngelPika32 commented Aug 29, 2022

NC23 provides an email notification for unseen notifications (see #1058 and #1074).
But there is no option for admins to set defaults and/or enable/disable it.

Currently, it is enabled by default (after visiting settings once; see #1173 ).

IMHO it should be disabled by default unless an admin said differently.


Additionally, I noticed, that the EMail gives you a neat overview of your notifications. Is there any way to view the same without receiving the Mail (eg. accessing manually)? Sure, you can click on the bell and scroll a bunch, but that's not the same.

As a follow-up, it might be useful to checkmark a notification, instead of dismissing it. But I don't think a notification history is kept or is there?
I personally just look at the notifications but never push the X, as that's an unnecessary action for me. And it helps to view some of the most-recent notifications again, even if I've already checked them out. Sometimes they act as a 'shortcut' for me too.

Should I create another issue/request for this?

@nickvergessen
Copy link
Member

Additionally, I noticed, that the EMail gives you a neat overview of your notifications. Is there any way to view the same without receiving the Mail (eg. accessing manually)? Sure, you can click on the bell and scroll a bunch, but that's not the same.

That is basically exactly the same. I don't think that we will go through the effort of rendering them in a second place a second time. But when the below topic would be different I could see where your request comes from.

But I don't think a notification history is kept or is there?

No, that's correct. The API call is called "Mark processed" but for performance and optimisations and ease of API use we always deleted them.

@nickvergessen
Copy link
Member

To the actual issue:

it should be disabled by default unless an admin said differently.

This was done as a design decision and is a sensible default.

But there is no option for admins to set defaults and/or enable/disable it.

That is correct. The biggest issue is the technical limitation which also causes the bug from #1173
But I have it on my (long) todo list to have a look at that bug and maybe we can then also add an option for the admin to set a default.

@EngelPika32
Copy link
Author

[…] is a sensible default.

mmh, okay. Well, receiving such notification emails isn't wanted by anyone on our instance. It's just an inconvenience. (Especially when they are triggered while you're out-of-office anyway)

The regular mail notification is more than enough. It just doesn't fit our use case.

But I have it on my (long) to-do list to have a look at that bug and maybe we can then also add an option for the admin to set a default.

I guess that might take a while. (Though, it depends on what "long" is for you.)
Could you add an option similar to profile_enabled_by_default (settings app), which can be set to 0 via occ, for disableing it instance-wide in the meantime? I think that's done much quicker than the full thing. But I could also be mistaken.

@natoponen
Copy link
Contributor

Hello @nickvergessen!

I'm currently working on the admin setting page for new user defaults. And I'm wondering why did you say in #1173 that defaults should be inserted on LoginEvent? Isn't it better to set them on UserCreatedEvent, so that once user is created, if he has e-mail, his colleagues can mention him and he will get the email without even signing into account once?

@nickvergessen
Copy link
Member

LoginEvent? Isn't it better to set them on UserCreatedEvent

We can also do both. LoginEvent means it would recover existing users as well. So yeah, maybe subscribing to both is the best idea.

@natoponen
Copy link
Contributor

@nickvergessen any thoughts on #1266?

@nickvergessen
Copy link
Member

Fixed with #1266

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

No branches or pull requests

3 participants