Update Contact config as Bugzilla User IDs

[bsieber-mozilla]

Yeah, not sure what it is--was pulling this from the firestore config; we'll have to reach out to Julien to go through the config together and update this file with contact and description info.

I'll make it an issue to track here.

_Originally posted by @bsieber-mozilla in https://github.com/mozilla/jira-bugzilla-integration/pull/57#discussion_r871541838_

[bsieber-mozilla]

• [x] AMO - https://people.mozilla.org/p/mixedpuppy
• [x] FIDEDI - https://people.mozilla.org/p/amir
• [x] FIDEFE - (+) https://people.mozilla.org/p/yshash
• [x] flowstate - (+) https://people.mozilla.org/p/pluk
• [x] fxatps - https://people.mozilla.org/p/pbz
• [x] fxcm - https://people.mozilla.org/p/abuzali
• [x] fxsync - https://people.mozilla.org/p/janet
• [x] gv - (Gecko View)
• [x] mv3 - https://people.mozilla.org/p/mixedpuppy
• [x] nimbus - https://people.mozilla.org/p/janet
• [x] proton - (Julien suggests to remove tag)
• [x] relops - https://people.mozilla.org/p/dhouse
• [x] snt - https://people.mozilla.org/p/cbellini

[bsieber-mozilla]

Is there any reason we'd not want to put their addresses in the config...?

I feel like we should inform all these users and request an address for their flows; instead of just using their listed ones.

@mozilla/jbi-reviewers thoughts?

[bsieber-mozilla]

Is this data planning on being used for automation? (automated email alerting?)

[bsieber-mozilla]

Can we migrate configuration to an alternate repo? (@grahamalama had mentioned this pattern previously)

[bsieber-mozilla]

Frida Hello Bryan, how are you? we received a security report related to the integration between Jira and Bugzilla, are the below endpoints intentionally public? https://prod.jbi.prod.cloudops.mozgcp.net/whiteboard_tags/ https://prod.jbi.prod.cloudops.mozgcp.net/jira_projects/ https://dev.jbi.nonprod.cloudops.mozgcp.net/whiteboard_tags/ https://dev.jbi.nonprod.cloudops.mozgcp.net/jira_projects/ I don’t see a lot of sensitive data, but wanted to confirm with you in case the endpoints are not meant to be public

7:39 AM bsieber Hi @Frida , the @syseng (#jbi) team is aware of these endpoints (others not listed can be seen here on the /docs endpoint). The same data presented on those endpoints can be visible in the public github repo’s config.ENV.yaml here (keys: whiteboard_tag and jira_project_key): https://github.com/mozilla/jira-bugzilla-integration/blob/main/config/config.prod.yaml The jira_projects endpoint is for users of JBI to understand which projects JBI has permissions for; if they need to request additional Jira projects--that aren’t listed; they are to reach out to JSM to request the additional permissions. Is there a possible concern with this data that we might not be aware of? Any and all suggestions or insights are welcomed!

8:50 AM Frida thanks Bryan for your message, I guess the only thing I would be concerned about is the employees emails included in the config 8:51 AM Frida would it be possible to use their bugzilla user IDs instead?

[bsieber-mozilla]

Use bugzilla user_id instead of email_address for contact field.

Maybe... -> This allows for JBI to create bugzilla issues and assignee contact field when an erring message needs to be cleared. -> On erring message (after X attempts -- how to calculate? Maybe webhook API?) take event message and create bugzilla bug with unprocessable webhook event

[bsieber-mozilla]

@mozilla/jbi-reviewers, we have the concept of "Invalid-Ignore" Exceptions; but I think we may want an "Unprocessable-Alert" Exception; I think the latter should be under a boolean flag--possibly an "error" step in the config in which we can make steps to handle certain errors.

Sometimes the webhook queues can be backed up it's unclear the best process for resolution--currently it's a manual purge of the erring events until the queue is running; if this occurs when we migrate to #21 all actions could be stuck when we get errors. There should be a process to alert the erring party that events are not being processed. This might be too noisy for most; but could be an angle for self-serve debugging? Maybe this isn't the right bug for discussing this.

[bsieber-mozilla]

440 Address this issue, but not necessarily the above comment--which is being discussed in recent comments in #415