Open paul-lemon opened 5 years ago
Brainstorm:
So options are
Use "Sprint ABC [ID:1234]" Pros:
Store the Sprint ID's in the user settings / google cache (like Epic) Pros:
And additionally Option 3 - a Hybrid
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
@ljay79 - I propose Option 3 - you ok with that?
Yep, i think option 3 us best so far.
@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....?
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
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 .
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.
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
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....