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.
Related
We're having some serious issues with the mfbclient.exe tool that is part of the feedback platform of VSTS. Basically, our stakeholder's uploads are not being sent.
This is extremely frustrating as you can imagine, as the ability to take screenshots etc is a major benefit of using the tool.
Members of the development team who have VS2017 installed on their machines as well as the feedback tool, can access the feedback request via the email that is automatically sent out when you click on "Request Feedback". Everything works perfectly.
If we send the request to a stakeholder, they can click on the link and it opens up the tool correctly, they can step through the items and make notes etc., and when they submit, their responses come through into VSTS. However, none of their attachments come through. They all say '(Uploading) filename.png' in VSTS.
Upon looking at one of the stakeholder's machines, I can see the mfbclient.exe tray icon says '0MB of 10MB transferred'. Restarting the machine doesn't change this - the attachments don't get uploaded.
Upon further investigation, under %localappdata%\microsoft\team foundation\x.0\testmanagement\ i can see an XML file which contains the list of all the screenshots / attachments etc that are to be loaded. The screenshot files themselves also exist (so, the files aren't missing/deleted). For some reason, the files just aren't uploading.
If I remove the XML file, it clears the attachment 'queue', but as soon as more feedback is entered and a screenshot added, the same issue occurs.
I noticed there was an mfbclient.exe.config file, which I edited on one of the stakeholder's machines and changed the trace level to '4' (verbose), which I thought would shed some light on the issue. However, I can't see anywhere that the logs might be. Does anyone know?
I have tested this with the stakeholder being part of the exact same security group as myself and the team (as I thought perhaps it was a permissions error), but this doesn't change the behaviour.
The only real differences I can think of between myself and team, and the people who are having the issues (and there are quite a few users who have the same issue so it's not just 1 person's problem), is that these people are stakeholders rather than subscribers (shouldn't make a difference), and they don't have Visual Studio installed on their machines (also, shouldn't make a difference).
Can anyone please shed any light on this issue? Has anyone else had the problem? Can someone from MSFT help?
Just as Sebastian mentioned, the solution is changing the Access Level from Stakeholder to Basic.
Basic provides access to most features, except for Test and other premium features. Stakeholder access to those users who need to
enter bugs, view backlogs, boards, charts, and dashboards, but who
don't have a TFS CAL. See About access levels for details.
Basic provides most features, Stakeholders can use the Feedback Client since TFS 2013 Update#5 based on this user voice. Can't attach pictures seems a permission limitation for Stakeholders.
Whatever seems it's by design or a feature missed or an issue on current version of TFS and VSTS based on the Stakeholders license limitation. However the requirement make sense and I have submitted a new user voice here to suggest the feature, you can go and vote it up to achieve that in future.
UPDATE:
I agree with your point of view, it's more inclined to be a bug. And you have submittetd a feedback here: Feeback Client - Upload fails for Stakeholder
Whether user voice or bug, development team will take care of them. So, let's wait for the response. And for now, you can change to the Basic Level to upload the pictures.
I have the same problem with our VSTS.
The problem really is because of the Stakeholder-License.
If I submit a feeback with a stakeholder account the upload stays at 0%. When I change the user then to Basic in VSTS, the upload starts automatically and completes.
EDIT: this issue has been fixed, as per this forum post: Feedback Client - Upload fails for Stakeholder
Experience with Jira is based on what I have seen from clicking through the project. There is no knowledge transfer as all people who knew this customized system left over a year ago.
As for the Atlassian PDF guide, it is not able to assist because the feature to add users and manage the users in Jira have been removed. An external LDAP system is where the users are managed.
I can view the User Browser and see users and do some editing of a profile and even delete the user from a navigation link in the footer.
But the real question at hand is, what do I need to do in order to
A. Assign users to an Organization Role that only allows them
1: A view only mode of the users in that Organization
2: View the details of the user and that users permissions/roles given
I've been looking for a few days now and just keep running into brick walls.
Thank you.
The upgrading of the system to the new version is not an option due to the extensive undocumented modifications made to Jira. It has been tried 3 times in the past 2 years without success.
I am answering based on JIRA 5.2 and higher experience.
Only place to see list of users is User Manager and you need to be JIRA admin to access it. So it's not a solution for you.
I searched for addon doing this but no luck. Moreover your JIRA is too old to be supported by addon providers.
The same story with JIRA REST API. Looks like for JIRA 4.1 you need to use JIRA REST 1.0 (current is 2.0) and I can not find docs for it.
I believe it's possible to write the addon to accomplish what you need but again it's not smart to invest in obsolete JIRA.
The most right solution is still migrate to the newest version of JIRA. Maybe you need abandon the undocumented changes or rewrite them into JIRA addons. It will not be easy and it can be costly but looks like you do not have too many options.
Task has been abandoned.
No answer to bad implementation and poor engineering practices when one is to continue to follow them.
I'd delete the post entirely but I'd rather give credit to the few that tried to provide some insight. Thanks again.
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.
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 using Jira for organizing user stories for my project on Agile approach. When I tried to close a user story it shows the status as ' Resolved', rather than 'Closed'.
Can someone help me how to change the user story status to closed?
Please post your suggestions and help.
Its a bit hard to answer such a vague question - so if you can ellaborate a bit on the customization you have done in your JIRA instance, it can help.
Some pointers:
JIRA is using workflows to manage the flow an issue can use.
The default workflow that comes with an installation of JIRA is called "jira" and looks like this: https://confluence.atlassian.com/display/JIRA/Configuring+Workflow
Depending on the customization of your JIRA installation, you can either change the workflow to go from Open to Closed when you use the "Resolve" operation.
If you are not the JIRA administrator, different workflow transitions can have various properties and conditions and validators set on them, for example checking for permissions. So if you are a user that does not have permissions to do a certain transition - you can see if you can change it via the permissions administation panel, or again - in the workflow validations.