Update Sprints from Add-On

[paul-lemon]

User need Setting the sprint on issues from the Spreadsheet is something that the folks in my team would like from this feature. The workflow would be

1. List issues from a filter -> populates the sheet
2. Issues edited and allocated to Sprints, copy and pasting Sprint Names or entering them directly
3. Update Jira issues -> data pushed back into JIRA

The BETA feature to update Jira Issues does only allows the Sprint to be updated by ID and not by name. Technical Challenges The Add-on feature to retrieve issues uses the sprint name so it's human readable The JIRA Rest API only allows the Sprint an issue is in to be set by its ID The JIRA Rest API does not have a clean way to retrieve a Sprint ID by name

Proposed Solution Update the "List issues from filter" feature to include the Sprint ID so that it can be read when updating the sprints. e.g. "Sprint 1 [ID:1234]" "Sprint 10 [ID:5678]" This would reduce the readability of the sprint names but would allow the add-on when updating the issues to parse the numeric ID.

Thoughts....

[ljay79]

Brainstorm:

• using same/similar custom field definition like i do with EPIC fields (has label+link) here it will need, label + id
• research feature to create dropdown selections on the fly (useful for multiple other issue fields as well)

[paul-lemon]

• using same/similar custom field definition like i do with EPIC fields (has label+link) here it will need, label + id The sprint ID's could be cached when retrieved from the API and then looked up when editing / updating. That could work.
• research feature to create dropdown selections on the fly (useful for multiple other issue fields as well) I don't fancy all that work - just yet - I like the simplicity of copying and pasting cells - its quick and easy to use and not as hard to develop. This I think would be a new feature down the line and not in the MVP for the "Update Jira Issues"

So options are

1. Use "Sprint ABC [ID:1234]" Pros:

• It will work and its simple to dev,
• The user can find IDs of sprints themselves in JIRA if they were not in the import from the filter
• It will be clear to users of the "Update Jira Issues" that the Sprint ID is required Cons:
• Adds user unfriendly IDs to the display of Sprints for users who do not use "Update Jira Issues"

2. Store the Sprint ID's in the user settings / google cache (like Epic) Pros:

• No IDs in the sheet - user friendly display of Sprint names
• reasonably do-able in terms of dev Cons:
• user cannot assign to a sprint that wasn't in the issues downloaded from the filter. (e.g. they create one in Jira while editing)
• If a sprint ID is changed or deleted in Jira between the download of the filter and the upload there will be an error

And additionally Option 3 - a Hybrid 3. Use option 2 above and allow Sprint to be entered by ID Pros:

• All the Pros of Opton 2,
• user can assign Sprints by ID if they are not in the sheet Cons:
• Harder to document for the user (could be done with Error messages "Sprint named 'xxxx; could not be found - check the spelling of the sprint name in your sheet. You can also enter the Sprint ID from JIRA into the field."

In terms of Effort Option 1 is simplest Option 2 is about twice the effort Option 3 is about the same effort as Option 2

[paul-lemon]

@ljay79 - I propose Option 3 - you ok with that?

[ljay79]

Yep, i think option 3 us best so far.

[paul-lemon]

@ljay79 - thinking about this some more

Option 4 When rendering the sprint use the ID of the sprint to form a hyperlink like you do for Epic Field =HYPERLINK('https://SERVERURL/secure/GHGoToBoard.jspa?sprintId=SPRINT_ID','Sprint Name')

Then the user can click on the link to go to the sprint in JIRA and the add-on can parse the sprint ID from the hyperlink....?

[ljay79]

Possible as well. We just need to keep in mind (incl. EPIC) every custom function to resolve Epic or Sprint (or anything else) are additional requests to Jira and for that a lot of Property get/set. Im becoming a little scared about the basic limitations and quotas of Google.

https://developers.google.com/apps-script/guides/services/quotas

[paul-lemon]

I think for this sprints we wouldnt to make an additional request as the Sprint Name and ID are available in the response already so it wouldnt need a custom function Is this not possible for Epic too? Fetch the Epic name when requesting the issues?

In terms of the quotas I think they are per user? Or are they per add-on?

On Mon, Mar 4, 2019 at 3:51 PM Jens [email protected] wrote:

Possible as well. We just need to keep in mind (incl. EPIC) every custom function to resolve Epic or Sprint (or anything else) are additional requests to Jira and for that a lot of Property get/set. Im becoming a little scared about the basic limitations and quotas of Google.

https://developers.google.com/apps-script/guides/services/quotas

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/ljay79/jira-tools/issues/150#issuecomment-469279710, or mute the thread https://github.com/notifications/unsubscribe-auth/AC0YXJUPy6KrkhHq53S1g-PjmdwBEH3dks5vTTLbgaJpZM4a6Vu1 .

[ljay79]

Yes, the quotas are per user.

Let suspend this for a little while until we have the current feature out and fixed and have the refactoring done. A few of your new code/classes is quite unautodox and not really matching our defined patterns.

Before going to much in detail, after your and my new feature, i like to spend a little more effort in analyzing and tweaking the calls under quota/limitations by Google. My stackdriver log is flooding of such quota errors and similar already - most likly due to "false" usage, but still.