Cannot close a sprint in Greenhopper: Project admin required for another project

[Mick Flanigan]

We have a sprint which cannot be closed. The error messages says I must be a project admin in the project the sprint is in, and another project. I assumed this was because of issue links, and went back and removed, however it will still not allow the sprint to be closed unless I add myself as admin on the other project. This is not the right procedure. What items could be contaminating my sprint from another project that would block me from completing it in this way? Is there a bug in the system because issue links or other items outside the sprint project are influencing the ability to close the sprint?

Error

To update this sprint you must have Project Administrator permissions for all of the following projects: Project A and Project B

BTW this is for JIRA version 5.2.7 and Greenhopper 6.1.2

We did not have this issue until this latest sprint, and we recently did an upgrade from 5.1.1 JIRA and 6.0.x GH. We are not sure this casued the issue, or if some use case of Greenhopper and JIRA changed with the team, but somethign from Project B is blocking us closing the sprint in Project A, and issue links have been cleared. Still something blocking.

[John Chin · Accepted solution]

Hi Mick,

It seem the problem that you encounter was related to file corrupted happen in JIRA instance, please try the following steps to rebuild the file again:

1. Shutdown JIRA instance
2. Delete the contents of JIRA Installation Directory\work directory
3. Delete contents of the JIRA Home Directory\caches\indexes\changes directory
4. Delete contents of the JIRA Home Directory\caches\indexes\comments directory
5. Delete contents of the JIRA Home Directory\caches\indexes\entities directory
6. Delete contents of the JIRA Home Directory\caches\indexes\issues directory
7. Remove the content of the following directory:
   • <JIRA Home Directory>/plugins/.bundled-plugins
   • <JIRA Home Directory>/plugins/.osgi-plugins
8. Restart JIRA instance.
9. Perform re-indexing.
10. Perform the integrity checker and fix any inconsistent data.

Hope it helps.

Regards,

John Chin

[Mick Flanigan]

Thanks John we will test this and report back in the next 24 hours.

[Mick Flanigan]

This appears to have resolved our issues, sprints can be started and stopped properly now with your instructions John. Thanks!

[Dominik]

We are having the same problem, but deleting the indexes etc did not help.

[MarkW]

I just had this exact issue reported.

Will a background index suffice or do I really need to completely rebuild the index and delete the plugin cache?

If I have to do a complete rebuild, I will likely have to wait until a maitnenance window as we have a large instance and indexing will take some time.

[Deleted user]

"It seem the problem that you encounter was related to file corrupted happen in JIRA instance"

What triggers it? Is this a known issue? Any workarounds or will it be fixed in future versions?

[John Chin]

For your information, the problem only happen in Greenhopper pior v6.1.2. If you see and get the same problem in the latest version, please raise an issue to our https://support.atlassian.comchannel.

[PedroA]

This page can help, too :)

Unable to manage sprint due to the error "Project Administrator permissions are required"

Cheers,
Pedro

[MarkW]

Here is an additional answer that resolved my problem. While all the issues were from a single project the users board filter was set to only look for the fix version. Adding in a filter for the project allowed the user to mark the sprint complete.

[MattS]

Yes, I always make sure that the board filter has some projects named in it, otherwise people have to be project admins for all JIRA projects to be able to create sprints etc

[MattS]

This can also happen if an issue is moved from one project to another where the board owners don't have permission to edit the issue I think

[MarkW]

Great suggestion Matt. I had just checked this but the issue history does not show them as being moved.

To test, I created a test user and assigned it as an administrator to the project but the user still could not complete sprint. I added a group this user was in to the Administrator role but with no luck. Interestingly enough, when I added the user to the jira-administrators group they could complete the sprint. Unfortunately, I cannot do that for the real user that is experiencing the problem.

[Mick Flanigan]

Hi Natalie,

I checked and all looks good. Filter against Rapid Board is setup to pull from Project A, no reference to Project B here. Good question though and made me go double check that!

[Natalie Hobson]

Just curious - does the filter associated with the board have both those projects in it?