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.
Related
We are migrating from an in-house tool to Jira for managing our scrum board, and we have concerns that I have been unable to resolve by searching the Internet. But you folks are smart, right? ;-)
Our current scrum board shows the usual swim lanes across state columns (for todo, progress, review, done). Each swim lane represents a user story, and has a link to (and a snippet of) the user story description in Jira. It also has a number of 'tickets' (these would be subtasks in Jira lingo) that start in 'todo' and move across to eventually end up in 'done'.
So far, Jira can do all of this, too (although creating sub-tasks is rather a lot more work in Jira than in our in-house tool). However:
When we commit code, we include a ticket ID in the commit message, and thus each ticket displays a list of commits that were done to complete that particular ticket / partial story. I haven't been able to find out how to do this in Jira -- if it's possible at all. Instead, it seems one must open a sub-task to see if there are any commits on it?
Each commit also shows its review state, which gives us an excellent overview of how close to done a ticket really is. I haven't been able to find out how to do this in Jira -- if it's possible at all. Instead, it seems one must open the sub-task, and drill down further into Fisheye(?) in order to see the review state?
In total, our tool provides a one-screen overview of the state of each user story, ticket, commit, and review state; and it's very lightweight to pull in new stories (from Jira) and add tickets. We fear that Jira is not able to provide such a one-screen overview, forcing us to open Fisheye in order to know whether a given commit has passed review.
Is it really true that Jira must be this cumbersome?
For reference, here is what a single ticket (subtask) looks like in our system:
And if you look at the whole scrum board, it's actually quite easy to get a feel for the number of commits on individual user stories and tickets, and the ratio of pending/passed/failed code reviews:
I agree with your fears when you say
We fear that Jira is not able to provide such a one-screen overview
In my experience (7+ years with Jira/Agile) I've not seen a such condensed view of information about a sigle user story even on a swimlane with relative cards.
Also in the Atlassian marketplace there seems to be no good plugin to solve your issue, even partially.
To make such move from your in-house tool to Jira retaining all you have there, I fear you should develop a custom Plug-in using Jira SDK to integrate with the agile boards.
It may be enough to start by developing a custom field to show what you need from a "ticket" (ie sub-issue) and trying to insert it into one of the three "slots" available for cards (I mean Rapidboard card layout configuration screen).
If you wanna try, start from here.
Another option to create a new custom field would be the Adaptavist Scriptrunner plugin. It will ease the building of custom fields: your new field can be written also in Groovy rather than plain Java. I've used it to build an extended status custom field (just to give the user an immediate big picture of it) that informs him in plain english and with stylish css colors why an issue is blocked or anything else relevant, getting data from other fields or linked issues that are not immediately visible to the user. IMHO, it is very similar to your problem.
Currently working with JIRA 5, I was looking for information about the handling Scrum in JIRA 6 with JIRA Agile (formerly Greenhopper). I saw, the there is now 3 statuses: To Do, In Progress, Done.
I find the 3 above statuses not enough. Particulary, we want to know if a story is still beeing clarified with the project owner, if is it a draft, if it has been approved by the customer. For a task, we also want to differenciate different steps in the "done" process: development done, review done, testing done, etc.
I'm looking for experience or any hints about this. My questions are: should I customize the workflow for my needs? Is there any standard workflows which already better supports Scrum? am I completly wrong and should I only use the basic concepts of JIRA for a Scrum process?
Any ideas/hints/experiences/links are welcome. Thank you.
You can customize the JIRA workflow (https://confluence.atlassian.com/display/JIRA/Configuring+Workflow) and then map the new statuses into Agile columns
In case if you already have a configured workflow go to your Agile board, go to its configuration and navigate to tab "Columns". On this screen you can add your custom column name, change its position and drag&drop status to a new column in order to map issues with this status to a column. If you use standard flow and need more customized one which better fits to your process then the link provided by mdoar above explains how to do this in details.
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've been reading some feature request-style threads in Atlassian's own JIRA install on how to disable (not remove) users in JIRA, and their suggested solution involves a series of UI actions. For the number of users that our organization supports, this needs to be automated with the rest of our employee account provisioning logic.
I've been looking in the JIRA database and found the membershipbase table, but simply removing records from here WHERE USER_NAME="$username" doesn't seem to have a completely successful outcome. When I go to the User Browser in the Administration section and look up that user, groups still appear for the user.
Does anyone have any experience with this that could point me in the right direction on any other tables I need to modify?
Thanks in advance,
-aj
Maybe you should take a look at Atlassian's Crowd. Even if you don't use SSO, it may help you to integrate with your existing infrastructure for handling authentication and authorization (i.e. groups) centrally. It also provides an administrative frontend that is designed for the corresponding tasks.
You could have a look at the EditUserGroups.setGroupsToLeave() method. As far as I remember, users need to be in the jira-users group to log in. So, if you remove this group from the user, it may be effectively what you need (not delete but deactive user acount).
If this does not help, I'd look into the source code of JIRA (which is available for all types of licenses afaik) to see which tables are modified by the above method.
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.