search

ljay79 / jira-tools

Project Aid for Jira - Google Spreadsheet Add-on for Jira Integration
GNU General Public License v3.0
112 stars 46 forks source link

Update Sprints from Add-On #150

Open paul-lemon opened 5 years ago

paul-lemon commented 5 years ago

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 commented 5 years ago

Brainstorm:

paul-lemon commented 5 years ago

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

  1. 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 commented 5 years ago

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

ljay79 commented 5 years ago

Yep, i think option 3 us best so far.

paul-lemon commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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 notifications@github.com 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 commented 5 years ago

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.