How the "Issue Workflow" action work?
"Issue Workflow" action allows to run any status transition on the issue that can be executed manually from JIRA issue view. It works the same as clicking on available workflow transition: 'Start Progress', 'Close', 'Reopen' or any other transitions defined in the workflow related with the issue.
It means for example:
There is simple workflow that allow for below status transitions:
- OPEN > IN PROGRESS (transition 'start progress')
- IN PROGRESS > CLOSED (transition 'close')
- CLOSED > OPEN (transition 'reopen')
Repeating Issues add-on allows to select one of this three transitions: 'start progress', 'close' or 'reopen' when set-up 'Issue Workflow' repeats. Choosing 'reopen' for 'Issue Workflow' action means the action will be executed successfully at selected date only if the issue will be in CLOSED status. It is not possible to 'reopen' issue if the issue has IN PROGRESS status because there is no such transition in simple workflow. Remember that also any other transition conditions must be satisfied if the 'reopen' transition has them configured in workflow definition.
How to set time when the repeating action is being executed automatically?
Just set the time in "Starts on" field. The repeating issue will execute automaticaly at defined time (from field 'Starts on") and with given recurrence rule.
The Repeating Issues add-on won't start after upgrade to Jira 8.x - what to do?
When you have the Repeating Issues add-on installed on Jira version 7.x, then two add-ons have been added to Jira instance:
- The core with name Repeating Issues App for Jira
- Compatibility layer for current Jira version with name Repeating Issues App compatibility layer for Jira 7
After upgrade from Jira 7.x to Jira 8.x there is need to uninstall above and install the Repeating Issues add-on again. This will add core and compatibility layer for Jira 8.
Uninstalling and installing of the add-on do not remove already configured repeatings.
Repeatings in status INTERRUPTED - what to do?
If you can find any error logs near the times when the repeatings occurred successfully last time, please create new support ticket with details. The logs are written to the log subdirectory of your Jira application home directory (or elsewhere if you have configured a different location). File: atlassian-jira.log.
If you can't find any related errors, there could be two use cases when you can see INTERRUPTED repeatings listed on add-on administration page (Jira Administration > Issues > Repeated Issues)
- Sometimes there are some problems with cached index for Jira search service during the add-on update process. This may cause that the repeated issues are not scheduled properly after add-on update (because issues are not found). Finally, the repeated issues may have properly calculated next occurrence date but their status will be INTERRUPTED. This happen in nondeterministic way and we did changes in the add-on version from 3.1.0 to try prevent such situations.
- When the add-on is temporary uninstalled, all issues to which any change are made will be indexed without data of repeated issues. After subsequent add-on installation such situations can either lead to repeatings with INTERRUPTED status, or repeatings may be not visible at all.
Solution
Go to add-on administration page (Jira Administration > Issues > Repeated Issues) and check if you can find any repeatings with INTERRUPTED status. If present, reset all repeatings using "more" menu (...) on add-on administration page. If you suspect there are some missing repeatings, please reindex the Jira and after finish, reset all repeatings on add-on administration page.
Also, make sure, you have always the the latest add-on version.
How to get more logs from Repeating Issues?
Please go to Jira Administration > System > Logging and profiling. Above the packages please click on "Configure logging level for another package" link to add new package com.codedoers with the DEBUG Logging Level.
Could not execute recurrence because of unexpected error - what to do?
If you see any kind of message like "Could not execute recurrence because of unexpected error. Please contact with your Jira administrator" or "Could not clone issue because of unexpected error. Please contact with your Jira administrator" please ask your jira administrator to check Jira logs at time when the repeating should occurs.
Here you can read how to get more logs
There should be more detailed messages what exactly happens and why the recurrence fails. Administrator should find for logs like this:
No Format |
---|
2016-06-10 17:17:00,045 atlassian-scheduler-quartz1.local_Worker-1 ERROR user@domain.com [jira.issue.clone.IssueCloningService] Could not clone issue TEST-408.
Error messages:
Errors:
1. The reporter specified is not a user.
2. User 'testUser' does not exist.
2016-06-10 17:17:00,045 atlassian-scheduler-quartz1.local_Worker-1 ERROR anonymous [jira.issue.recurrence.RecurringIssueExecutor] CloneIssue action failed for issue TEST-408.
Error messages:
1. Could not clone issue because of unexpected error. Please contact with your Jira administrator |
If you find problems that you can't solve with Jira proper configuration then create the ticket with logs details at https://codedoers.atlassian.net/projects/SUPPORT
Can't see repeating issue section on issue details view.
Repeating Issues require user to have issue edit permissions. If the user is not permitted to edit the issue the user will not be able to see repeting issue section in the right panels on issue details view. Repeat action in more menu will be not available also.
How to determine cloned issue due date?
Versions >= 0.7.0
User can schedule "Clone Issue" action for issue create date or issue due date by choosing proper "repeat by" option. There is also field where issue duration could be set in days.
When set-up new repating for issue add-on will calculate and set issue duration field based on original issue as working days between original issue create date and original issue due date. If original issue has not due date then issue duration field will have value equal 0. User can always change this value to other before save the repeating.
If issue duration will not be provided in repeating set-up screen and the original issue has valid due date then when new cloned issue will have duration calculated from original issue.
Versions < 0.6.2
The cloned issue due date is adjusted to reflect the new occurrence's dates and it is calculated on original issue created date and due date with following algorithm:
clonedIssue.dueDate = clonedIssue.createdDate + Duration.between(originalIssue.createdDate, originalIssue.dueDate)
Assume the original issue created date is 2016-11-07 and due date is 2016-11-18. If new cloned issue falls on date 2016-12-01 (it is created date) then its due date will be set to 2016-12-12.
Please note that both original issue created date and due date must be provided to set cloned issue due date when cloning.
How to add custom user group to add-on project roles in many existing projects?
Repeating Issues add-on project roles are configured with jira-users and jira-developers groups as default members. Admin can add new default members for each role as described in Jira documentation: Specifying 'default members' for a project role. Please note that changing a project role's default members does not affect the actual project role members for projects already created. It is only template when new project is created. Existing projects need to be updated following to this documentation Managing project role membership.
Admin can use Jira REST API to create changes in multiple projects using curl or using simple shell script (click to download). Just execute
No Format |
---|
./add-custom-project-role-actors --jira http://localhost:2990/jira --user admin --pswd admin --roleId 10100 --project PROJA,PROJB --actors '{ "group" : ["my-custom-group-name", "another-custom-group-name"] }' |
RoleId can be found in url when follow instructions to Specify 'default members' for a project role. E.g. http://localhost:2990/jira/secure/project/ViewDefaultProjectRoleActors.jspa?id=10100
How many times can I apply for an evaluation license?
For server apps, you can extend your app trial up to 5 times - in other words, for up to six months. Extend your trial by generating a new evaluation license key from Atlassian Marketplace. Click Try it free and you'll be directed to generate a new license. Paste this license key into the app listing in UPM from your Atlassian host product, and you're all set.
How can I extend/modify license for Repeating Issues?
All Atlassian add-ons licenses are managed by Atlassian - not by Codedoers. You should contact Atlassian Marketplace Support for more details and troubleshoting.
...
- Licensing & Purchasing FAQ - https://www.atlassian.com/licensing/purchase-licensing
- Atlassian Support - https://www.atlassian.com/company/contact
Generating a solution partner demonstration license
...
Child pages (Children Display) |
---|