Description of problem: RFE: Email notify the user when the language team permission change It will be especially useful for new user applying for translation permission. Version-Release number of selected component (if applicable): 3.5 How reproducible: Always Steps to Reproduce: 1. Language coordinator check the translator checkbox for user A and save the change. Actual results: No email notify user A. Expected results: Email to user A that say: "You have been grant the translator permission on language team <languageCode>' Additional info:
*** Bug 1117684 has been marked as a duplicate of this bug. ***
Note that the notification may not necessarily be an email. When the notification system is in place, users may choose to receive notifications by email or check them on the server. See https://bugzilla.redhat.com/show_bug.cgi?id=1117633
Related to https://bugzilla.redhat.com/show_bug.cgi?id=1120461
+1 for this. I am manually replying emails right now and this is quite annoying. I think for the time being (before all users are fully aware and used to the yet to build built-in notification system), an email will be sufficient and necessary.
+1. This is standard feature in Transifex if my memory serves correct. It is meaningless but just wasting admin time. auto reply email is sufficient. On fedora.zanata instance, we are expecting over a thousand of translators to join. Replying manually for each join will kill admins and coordinators. Could you please raise the priority?
We could start by adding a list of "pending applications" to the language teams, and then automatically trying (but not failing) to send a notification to approved team members once it's done (initially just an email, but later tied to the notification framework). We would need to let team coordinators (or admins if there are no coordinators for a particular language) know when there are pending language team applications so they can act on them.
Notes from developer discussion: This would benefit from a UI redesign and proper notification system, but the initial implementation should aim to quickly fix the current pain-point of having to manually send emails. Initial implementation should have: - persistent queue for emails - stale queue notification - document standalone.xml changes required for queues - email is sent to user when checkbox on manage language page changed - email sent when confirmation button on add team member page is clicked Emails should include information about which user was responsible for the permission change. Note that the persistent queue can be monitored using JBoss console. There were a number of points brought up in the discussion that will not be included in the initial implementation. They should be tracked in separate bugzilla items: - The user interface should be updated to avoid the issue with emails being generated when a coordinator or admin toggles a checkbox on and off. - A proper notification system will allow better visibility of queue errors by administrators, and allow users to choose batching options to avoid getting more emails than they want.
https://github.com/zanata/zanata-server/pull/639
Merge verified