How do you find the most recently created project in JIRA?

[motherg]

Hi all,

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.

[John Bayne · Accepted solution]

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

[Nic Brough -Adaptavist-]

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.

[motherg]

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.

[motherg]

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?

[Nic Brough -Adaptavist-]

Your assumption is spot on. You have to remove them from the admin groups to remove their ability to create projects, and that will also remove their right to edit fields and screens.

[John Bayne]

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.

[Nic Brough -Adaptavist-]

(It's usually the fields that give me the worst nightmares when people have been allowed admin rights)

[John Bayne]

... 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 ...

[Nic Brough -Adaptavist-]

John's comment is exactly the way I recommend setting it up as well.

[motherg]

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.

[Nic Brough -Adaptavist-]

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.

[motherg]

Not a bad suggestion - a good way for a group of Admins to see the work queue and pick something up.

[John Bayne]

Ditto - I have a Helpdesk project that I encourage users to ask questions about Jira through. I'm alerted at each submission. This also means that I act as a funnel so that we don;t have all of our staff visiting Atlassian Answers with dumb questions - just me :-)

[motherg]

Talking of stupid questions, I feel another one coming on but it's way OT for this thread...

[Nic Brough -Adaptavist-]

That's what "answers" is for. (And clever questions too, of course)

[motherg]

Hahaha, yup! Right, I'll be asking another question momentarily. Change of context, this time it's about a resolution screen that only appears for certain issue types!

[motherg]

hmmm - I suspect you can't get that DB report if you have Cloud?

Thanks for the answer as always Nic - you have given me an idea to run a query and have a look at the ID numbers, that'll give me an idea at least.

[Nic Brough -Adaptavist-]

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.

[MattS]

For Cloud you'd have to screen scrape the All Projects page I reckon

[Nic Brough -Adaptavist-]

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.