Running Scriptrunner escalations one 1 node in Jira data center

[Tom Towkach]

Can Scriptrunner's built in script for escalations be configured to only run on one node in Atlassian Datacenter?

[Martin · Accepted solution]

Thanks for your detailed reply.

Editing in the Rapid Board has an approach that would probably better suits your needs (when all fields are editable) but I assume for your Scrum usage it doesn't have everything you need just yet.

[Dmitry Nechayev]

... besides, I am no longer able to work with Jira client because of https://jira.atlassian.com/browse/GHS-4297. This 5.8 upgrade is increasingly looking like a wrong choice

[Dmitry Nechayev]

We just upgraded to GH5.8 and I was eager to see how Rapid Board addressed all those issues. So far I did not find a way how, at least, to get an equivalent level of functionality to what we have been using with Planning and Task boards. I did not find how to configure Rapid Board cards, how to view epics'content, how to make a compact list. Overall it seemed more counterintuitive and less usable. I wonder if it would be possible to address most critical concerns with existing functionality (like having URLs for specific views/contexts) rather than inventing new functionality of dubious purpose

[Martin]

Dmitry,

1. Have you tried editing the issues in the Planning Board? The issue cards (3 different ways to view card, summary, list) can be customised to show the fields you are interested in viewing/editing. If the field on the issue is editable then this can be done in-place using inline-edit, just click the field and edit. This would be the preferred way to edit or view an issue within GreenHopper without the round-trip to JIRA's pages.

https://confluence.atlassian.com/display/GH/Using+Planning+Board+Views

2. Have you tried working with Epics while using the Scrum template? This has benefits in the way Epics are handled. When clicking an Epic 'label' all the children are shown in a dialog and so changes can be made without losing your viewing context.

https://confluence.atlassian.com/display/GH/Working+with+Epics

3. The behaviour of the boards is to show the last used project/context and the Planning/Task boards do not have permanent links. This is one of the features we have added to the new Rapid Board, where all states can have permanent links (to bookmark/favourite/share).

https://confluence.atlassian.com/display/GH/Using+the+Rapid+Board

[Dmitry Nechayev]

Thank you for your reply!

1. Yes, we are using inline editing in the Planning Board. It does help in certain cases, but most heavily edited fields are multi-line Description and Acceptance Criteria field and editing them inline is not really usable

2. Yes we are using Scrum Template. The problem with Epic children window is not in the context change though. Consider the use case: during a release planning, Product Owner opens epics one by one and for each epic enters child stories. Child stories are being edited from the same Epic children screen. Completion of an Edit session brings a user to the View screen from which it is only possible to return to the original list on the Planning Board. Then the current epic should be located again, Children window invoked and the next story in the list taken for editing. Not really usable. I understand that this hits the same navigation limitation that exists between Jira and GH screens

3. I understand that Rapid board will address this and have no more questions. Will wait for GH 5.8 to be deployed

Thank you

[NikE]

There are a lot of new features and functionality being added in Greenhopper v.5.8.x, but I'm thinking that the issues you are describing might be browser related. If you are using Firefox 3.5/3.6 or IE7 - there are some pretty serious navigation and performance issues. If you are using one of these browsers you will very likely find everything works much faster and more smoothly if you switch over to a newer Firefox or Chrome.

Greenhopper will be updated to v.5.8.x in the OnDemand suite in the near future, although I do not have a date/window for when that will happen.

[Dmitry Nechayev]

Thank you. Will wait for GH 5.8 to be updated to see whether it fixes these problems. One thing is sure is that the problems listed above are not browser related - these are purely functional problems related to a lack of clear navigational path between GH screens - as described above