Learn more about these different git repos.
Other Git URLs
There could be different types of events for notifications:
While one can setup mail filters based on the content via system of regexp, it would be much more reliable and simply to have a predefined reason for each notification (may be multiple), and expose this info in a proper format.
For example, if you are subscribed to the issue and also someone directly mentions you in the comment, the header should be:
x-pagure-reason: mention, subscribed
I like the extra header but I am not yet sure I agree with the semantics, I believe I would like to filter/distinguish all new messages based on these conditions:
- I created the ticket
- I subscribed to the ticket explicitly
- I was mentioned in this comment
- I was mentioned in any comment in this ticket
- I commented on the ticket
(less important reasons)
- I am subscribed to all tickets of the project
- A group I am part of is subscribed to the ticket
I think actual values and labels for the notification should come from the internal implementation of the notification in Pagure, rather than from external user request. Pagure app itself knows which event triggered the notification. And has it all encoded, with certain names(types, classes,.. whatever) and priorities (order of execution).
So the header should only expose that information with as little remapping as possible. This way we won't need to keep a separate database for that information, and won't need to maintain it as a separate entity.
I believe this partly overlaps with https://pagure.io/pagure/issue/2396 which makes me wonder if we should close this ticket as duplicate.
Metadata Update from @pingou:
- Issue tagged with: RFE
Closed as duplicate
Metadata Update from @wombelix:
- Issue close_status updated to: Duplicate
- Issue status updated to: Closed (was: Open)
to comment on this ticket.