Deliver notifications to users

[jtotht]

Currently the only way to get to know notifications is to open bead.inf.elte.hu and check if there’s a number after the Notifications item in the top menu bar. This is a sub-optimal user experience; it would be great if the notifications could be sent out in email or at least could be queried by a browser extension through some API.

(By the way, I wrote a browser extension that periodically loads the page, reads the menu bar and reports the result in the browser toolbar. I can open-source it or share it otherwise if someone wants it; however, even though it made my life a lot easier, it does screen scraping and thus can break at any time. Also I don’t want to share it without permission from @poor-a as it kind of works around BE-AD, which is not a nice thing.)

[andorp]

I don't know of the current funding of the BE-AD project. But when I worked on it, it was a voluntary work. We considered implementing the notification system you described, but decided against it. To maintain such a notification system needs a software architecture that needs to be overlooked and maintained. For the user experience part, if the users are not responsible for receiving their notifications, when something goes bad (e.g. unsent notifications) the blame will be shifted to the developers and maintainers of the BE-AD. If one does the maintenance voluntary it is not a great position to be to receive thousands of angry complaints, just because somebody plugged off the mailing server at 3 in the morning.

Unless if somebody wants to pay a full time DevOps engineer for such activities around the BE-AD I don't think this initiative would go forward.

@poor-a : Any thoughts?

[jtotht]

And what about a pollable API, at least to report the number of unread notifications? That doesn’t seem to be architecturally that different, and a bit of outage doesn’t make much harm. By the way, as far as I know, https://tms.inf.elte.hu (formerly https://assignment.elte.hu) led by @mcserep is able to send email notifications, despite of being a university “pet project” as well. (Unfortunately it’s closed-source, but at least it proves that mailing is not impossible.) Also, I don’t think the maintainers will ever get thousands of angry complaints, simply because most students have no clue who maintains this. ;)

[mcserep]

On TMS we use an official university mailing server (the one available on Caesar cluster) to send the notifications.
If Caesar fails to send the emails, they will not be sent of course, which is a risk, but I think it is a minor one.

[andorp]

| And what about a pollable API, at least to report the number of unread notifications? That doesn’t seem to be architecturally that different, and a bit of outage doesn’t make much harm.

We also thought of that. A pollable API needs authentication at the user side. Which is not that different from logging in the UI. Yes I understand that this is tedious and not that user friendly. But I don't have a saying here any more, @poor-a has.

[andorp]

| Also, I don’t think the maintainers will ever get thousands of angry complaints.

History proved otherwise. Not thousands, but we got constant complaints on minor things, despite that the system worked for 24/7. In general there will be always some people complaining about things.

[poor-a]

Thank you for your idea for improvement. E-mail notifications are indeed badly missing. I have already reserved bead at inf.elte.hu for this purpose, although no further progress has been made.

I barely have time to work on BE-AD, so any contributions are welcome. ;)