I moved by mistake a issue from not started to DONE. Is there a way to move back the issue?
I would rather let it "in progress".
The answer is yes, but you may have to customize your workflow to add a transition from the DONE status to another status. Make sure to clear the resolution using a post function so that your issue key is not marked with a strike through
Yes! Or no, or maybe :)
It depends on your issue type's workflow, but you can usually re-open the issue and set it to in-progress.
This, of course, may also be dependent on
What version of JIRA you're using
If you're using GreenHopper/JIRA Agile
If you have a custom issue workflow/lifecycle
What your user permissions are.
Any additional details about your JIRA instance might be helpful! Is it a hosted ( ala Atlassian on-demand ) or on-prem, etc.
Related
I actually moved to Jira and to be honest, it is really helpful and effective tool. I wonder everything has limitations, What are the limitations in jira when an active workflow is being edited?
There has to be some things that the user should be careful about. Any guidance would be highly appreciated :)
Wel, I got this from a link.
If a workflow is active, you cannot edit the workflow name (only the description)
You cannot delete the workflow steps
A step associated status cannot be edited
You cannot add any new outgoing transition if a step has no outgoing transitions (Global transitions are not considered).
A step’s Step ID cannot be changed.
If any one can add anything on this, please go ahead
Currently I am working on a Jira project and in that project I have built a workflow. The workflow runs with a single issue and runs successfully.
This workflow mainly consists of 2 parts. In the 1st part, the authorizations are set and approved. In the 2nd part some assignments are being conducted according to the authorizations that have been set in the first part.
This workflow works well but I have been asked to implement this project with 2 different workflows which will be run by 2 different issues.
So my question is, how can I migrate data from the first issue to the second issue? Somehow I need to transfer the authorization info to the second issue so that the second workflow will be able to run.
Thanks a lot.
Once the authorization is complete you could change the issue type to a type which uses the second workflow. If you want to retain the authorization record, you could clone the first issue and then change the issue type of the clone.
A late respond: I achieved this by using the sub-task mechanism. I also used post-functions in the workflow which made me able to get the authorization data from the first issue.
I've been looking for a way to have a user acknowledge a
ticket after it has been assigned to them. I don't know if
this is a built in feature or if there is a plugin that
will create a state/button for a user to accept a ticket
after it has been put in there queue. I would expect to
see something like this from the ticket window around
workflow or start progress but no amounts of digging
through configuration settings has turned anything
relevant up.
Does anyone know about this added functionality in JIRA?
Much thanks.
I did this by a custom workflow step. After an issue arrived to an assignee (with status New) he/she should move it to another step (with status Open). Until he/she does it, the issue is considered as not noticed/reached the assignee. Also I have had a report showing issues with New status for more than a predefined period of time.
I'm not aware of a ready-made plugin which performs similar task (perhaps, I should dig into my posts on Atlassian answers to discover some clues for other solutions).
As #Stan says above, a custom workflow is the way to implement this. The workflow functionality in JIRA is very flexible and as a result has a bit of a learning curve, but Atlassian's documentation is pretty good. Post back here if you need help.
I am in need of replicating all kayako helpdesk tickets into TFS. This includes creation of the ticket, updates of the ticket, and closure of the ticket. I've looked around and I can't seem to find any elegant solution to this. Can any of you point me int he right direction?
You can roll your own integration by building on the TFS Integration Platform.
Does Kayako support webhooks? webhooks allow you to send data when it happens, so for example when a ticket is created or when it is resolved - you can then have your application process that data. This is far better than having to make repeated calls to an API to see if there are changes to a system.
For reasons I won't go into here I need to stop developers from changing the Fix Version in JIRA without preventing them from changing the Green Hopper Ranking.
This is slightly complicated as Greenhopper allows you to change whether you are using the Schedule Issues or Resolve Issues permission for this stuff.
I've tried the following:
Set GH to use the Resolve Issues permission and revoked the Resolve Issues permission. This prevents users from changing both fields.
Set GH to use the Schedule Issues permission and revoked the Resolve Issues permission. This allows editing of Ranking, and blocks changing the Fix Version in the JIRA screens, so far so good. However it is still possible to change the Fix Version in the Green Hopper Planning board.
I've also investigated removing the Fix Version field from the JIRA screens, however you can still always change it in GH.
I'm out of ideas, so I'm hoping someone out there has worked out the answer for me :)
Forgot to mention - I'm using JIRA 4.1.2 with GH 5.1
Out of the box, what you describe can't be done. Atlassian has made clear that they won't be providing field level security as outlined in JIRA-1330.
That said, control of who can and can't set the fixVersion field is controlled by the Resolve Issue permission as noted here, though it appears you have gone down that route.
My question to you: are you using the fixVersion field? If so, how are you using it and when is it set? The answer to that is key to figuring out the right way to go.
A few possible ways to address this issue:
Control it via a workflow as outlined in this article
Control it via a template as outlined in this article
See if the Field Security Plugin might meet your needs
Having worked with JIRA long enough, I do know that I could cobble something together to make this a reality. It just is going to take time. For example, you might be able to use the scripting plugin to reset the fixVersion field if it has been edited by anyone without the permission to change it.
Depending on how important this is to you, you might want to retain a JIRA Consultant to come up with a solution for your need.