Not sure if this is possible but I'm trying to find out the most recently created project in JIRA. I'm not talking about issues created in a project but the project itself.
The reason I'm asking is because we've got some people creating projects with really poor workflows and I want to see if the newly created ones are being stuck to the guides.
I don't let development teams create projects; this is the preserve of the full JIRA system administrator.
Project managers/administrators can add versions, components, project specific field options and configure users to roles in the project.
Allowing these folks to mess with workflows and other parts of the configuration is a recipe for chaos IMHO
Yup. Admin rights should be limited to a tiny handful of admins who work closely together so they don't make a mess. Yes, it's a bit of a bottleneck for them to create projects, but its far worse when you let too many people have admin, because they *will* make a mess.
Yup, what I'm seeing is the result of exactly this situation. What I think I'll have to do is set up some training to show the people who do have the rights how to do it. I'm reading this with a view to remove the ability to create projects/workflows from the administrator role: https://confluence.atlassian.com/display/JIRA/Managing+Global+Permissions#ManagingGlobalPermissions-sysadmin I'm not sure how to do it though - will do some more digging but I may ask for some help later on today if I can't work it out.
Alrighty, do you mind if I run this one past you - the Create Project permission is reserved for Administrators and System-Administrators, so the only way to remove that permission is to remove those peoples from the administrators group? I ask this because I want to be absolutely sure really - removing those users from that group would prevent them from being able to edit their Field and Screen Scheme too I believe?
How I have this set is that an exclusive set are in jira-administrators having full access. These are assigned to be JIRA System Administrators in Global Permissions. Project managers, technical leads, scrum masters (whatever you call them) are all in Project Role = Administrators (on a per project basis) and are not in jira-administrators. These guys can then only manipulate versions, components, project specific fields (Add-on supported) and Project Roles.
... and to answer your question they will not have access to Fields, Screens, Workflows, etc. The burden on myself on going this way was to place the onus on myself as being the guy who established the system and to maintain it for others. Having said that all the work is in Jira and Jira Agile takes care of itself ...
Cheers chaps - I'm thinking the exact same as you. The setup here is possibly the worst I've ever seen and it's because too many people have had access. To spread the load I am suggesting that we have a group of JIRA admins who are at a similar level of competency, requests come in to the group and we serve what comes in. There are some examples where the teams are self managing and I understand that there will be some backlash to this approach. No problem really, we'll just train them up before letting them loose and there will have their own workflow/screen scheme/field config so they can't bugger up anyone else's projects.
I've usually found it pays to be blunt - have a "jira config" project, get the users to stick every request in there, and point-blank refuse to make any changes unless they're logged there! Then they can a) see how it's doing and b) get a record of every config change, so your admins have a decent audit trail if things go wrong.
The creation of projects is not logged unless you turn on the "audit logging". That will log a date/time/person after it's enabled, but for existing projects, I'm afraid you basically have to take an educated guess.
I wrote a report that pulled out the id in the database so you can compare it with other projects (the id always counts up, so you can examine surrounding projects for relative information), but it's not a huge amount of use because what you really need is the issue dates - you know that the project was created before the earliest issue within it, and after the first issue in the previous project, but that's about it.
Well, I did it as an addon, not in the database, but you can't add addons to Cloud unless they're on the approved-by-Atlassian list. I can't think of an easy way to get to the project IDs. I'm sure they can come out on a link somewhere, but I can't think of it.
Atlassian Summit is an excellent opportunity for in-person support, training, and networking.Learn more
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG