Status

()

enhancement
P2
normal
3 years ago
6 days ago

People

(Reporter: Silne30, Assigned: seban)

Tracking

({bmo-bug-quality, bmo-on-deck})

Production

Firefox Tracking Flags

(Not tracked)

Details

Reporter

Description

3 years ago
We need an HTTP POST request with the following data (preferably in JSON):

- unique id of the ticket 
- action taken (like ticket created, updated, closed, removed) 
- email address or gravatar hash of the author of the action 
- title of the ticket (optional) 
- permalink to this ticket (optional)  

Additionally, we can distinct between user story, bug and task/feature in our systems and treat those differently, but some systems (like Trello) do not support that distinction.
Reporter

Updated

3 years ago
Flags: needinfo?(dylan)
I misunderstood originally, that Silne30 wanted this for generic bugzilla. We can do this for BMO using the push extension (which, IMHO, should be ported to upstream bugzilla)
Assignee: general → nobody
Component: Bugzilla-General → Extensions: Push
Flags: needinfo?(dylan)
Product: Bugzilla → bugzilla.mozilla.org
QA Contact: default-qa
Version: unspecified → Production
Reporter

Comment 2

3 years ago
It's been a month and a half. Is there any progress on this?
Flags: needinfo?(dylan)
My apologies. in the preceding month we've been focusing on many other tasks. 

This request hasn't specified what initiative this is for, but if it is blocking
something and priorities need to be juggled it would best to square that with the manager of the BMO team, :mcote (transfering needinfo).
Flags: needinfo?(dylan) → needinfo?(mcote)
Assignee

Comment 4

3 years ago
Dylan, If approved, am ready to take this up.
Could you tell me more about what project this feature would support?
Flags: needinfo?(mcote) → needinfo?(jdorlus)
Reporter

Comment 6

3 years ago
Sure. We (cloud services)  are in the processes of migrating from badges.mozilla.org to testing out an external badging tool (Getbadges.io). They need access to some kind of API to be able to update, create and close bugs and stuff like that. Like a REST API. When I inquired in #bugzilla, I was advised that a bug would need to be created.
Flags: needinfo?(jdorlus)
(In reply to John Dorlus [:Silne30] from comment #6)
> Sure. We (cloud services)  are in the processes of migrating from
> badges.mozilla.org to testing out an external badging tool (Getbadges.io).
> They need access to some kind of API to be able to update, create and close
> bugs and stuff like that. Like a REST API. When I inquired in #bugzilla, I
> was advised that a bug would need to be created.

We already have a REST API that can be used by your site to create and close bugs.

https://bmo.readthedocs.io/en/latest/api/index.html

This bug is about configuring the Bugzilla system to send out data to external systems on certain events.

dkl
Talked to Silne30 and it does sound like he only needs the REST API.  We can keep this bug open for now, though, as having generic web hooks would be nice some day.
And to back up again, turns out getbadges.io does require web hooks for full integration, since they can award badges based on bug activity.

Having web hooks would be really nice, and is an expectation of modern systems, so we'll look into the effort required here and try to prioritize it.
Reporter

Comment 10

3 years ago
Thanks (In reply to Mark Côté [:mcote] from comment #9)
> And to back up again, turns out getbadges.io does require web hooks for full
> integration, since they can award badges based on bug activity.
> 
> Having web hooks would be really nice, and is an expectation of modern
> systems, so we'll look into the effort required here and try to prioritize
> it.

(In reply to Mark Côté [:mcote] from comment #9)
> And to back up again, turns out getbadges.io does require web hooks for full
> integration, since they can award badges based on bug activity.
> 
> Having web hooks would be really nice, and is an expectation of modern
> systems, so we'll look into the effort required here and try to prioritize
> it.

Thanks for talking to the GetBadges folks, Mark.
We'd like to set up this task as a Quarter of Contribution project, with me mentoring it and Sebastin being the mentee.

1. How self-service does this need to be? Do we need to have an API that allows an application to register to receieve these push events, or can it be a manual step initiated by the admins?
2. In either way, what is the filtering criteria? How do we know which bug updates to send? Obviously we will defer sending
any security bugs over the wire.
Flags: needinfo?(mcote)
Assignee: nobody → sebastinssanty
This will support some of bsmedberg's OKRs as well, because this would give us a hook into our email marketing systems so that we can communicate with contributors on the basis of their Nth bug. I'm cc'ing :mhoye on this since participation is his bailiwick.

Need to find out what Basket's needs are for Callbacks and if they need GET or POST, but we'd want to add the ordinality of the bug the callback is for. Which means I'll need to reopen the cardinality feature request.
Flags: needinfo?(mhoye)
Glad to have Sebastin aboard.  

As Emma mentioned, we've got pretty good metrics suggesting that after your fifth or sixth bug, you're likely to become a long-term contributor. To that end, we'd like to have some automated processes supporting, thanking and encouraging new contributors in those processes, including automatic mailouts.

I'm drafting proposals for the contents of those emails now, and will attach them to this bug no later than Monday.
Flags: needinfo?(mhoye)
I still haven't heard back from the GetBadges people.  Starting out with what emceeaich and mhoye need is probably the way to go.
Flags: needinfo?(mcote)
You need to log in before you can comment on or make changes to this bug.