You don't have the 'Browse Projects' permission, which allows you to view a project and its issues.

[gbatalski]

Jira Software doesn't allow me to see the project list.

What is wrong?? I am an admin, and there is only one project and the permissions to browse it are granted to all logged in users??

I also would like to know, why do you ruin a nice pice of software just like jira was  years ago and add those sh*t , so we can not just simply start to work with, just we could do it on github???

Regards, Gena

[Nic Brough -Adaptavist-]

That's not really a very fair thing to do - blaming a tool because you don't quite understand what it's doing, and having a go at a way that it has behaved since version 1 (ok, maybe not 1, I only used 1 very briefly, but definitely version 2)

Administrators have the right to administrate, not "do everything".  You have not granted your account access to the project via the permissions.  So you don't have "browse".  Either add yourself as a user into the project, or change the permissions to include "admin browse" - I'd recommend going no further, just let admins see the projects saves a lot of confusion if you're struggling with "admin means just admin"

[Gaston Valente]

did you actually work with a version 1 in production? That's a lot of history.

i ask to myself which features remains from day 1. 

I started with 3

[Nic Brough -Adaptavist-]

My first task was upgrading a 2.7.3 to 3.0.3 (3.0 was released the week I started the new role), and then we needed to merge  data from some other JIRAs, including a 1.something.

The stuff that has persisted is essentially the system fields, users, the default workflow (couldn't edit it in 1), the way resolution works, and the permissions and notifications.  There's probably more, but I didn't work with it a lot.

[Gaston Valente]

ok, so the fundamental building blocks of the app are the same.

thanks for answer

[Steven F Behnke]

I stand by Nic's response.

I can't help but find the OP hilarious. If an admin wants to see all projects, then go to Admin > Projects. Using the User > Browse Projects screen obviously only shows projects that you can browse.

[gbatalski]

Hello,

i'm an administrator and a developer at the same time.  But the jira is connected to crowd server as a read-only directory. I've maped my crowd groups to project roles. The project roles are assigned to the permission scheme, but i can't see the project lists and i'm not allowed to create issues (and the both are the only features i need from jira since about 15 years).

Although, the defalt schema says, the project browsing is allowed for all logged in user without any other restriction, and i am logged in user even via Crowd. 

Jira just not allowes me to assign the Jira Software Application to me. So the communication between Jira and Crowd is not realy smooth. I've lost about two days to configure whole infrastructure and just as i wanted to create some issues to test all the things it was not possible.  

I think, it is unnecessary to talk about missing issue tracker and wiki integration in bitbucket in opposite to bitbucket.org/com, what is also revealed after the installation was completed. I naively thought, if i use jira/confluece and bitbucket together, they will work smooth together...

Gena 

[Steven F Behnke]

I'm trying to be polite: The complexity here is your Crowd/External Directory setup. 

If you had used the exact same groups/configuration as JIRA Cloud, it should all work exactly like in JIRA Cloud.

Experienced admins do not have these problems.

[Nic Brough -Adaptavist-]

>but i can't see the project lists and i'm not allowed to create issues

That means your account is not in the right groups or roles.  You need to look at the permission scheme and make sure your account matches it.  As an admin, you can see the full list of projects and administrate them, so adding yourself to the right roles will solve it (as it sounds like your schemes do the right thing and use riles).

JIRA (Core, Server and Service desk), Confluence, Bitbucket (and, for what it's worth here), Bamboo, and the rest can work seamlessly together, with Crowd or another user directory provider.  As long as you get the design of the directory aligned with the applications.  That's not an Atlassian thing, I'd say exactly the same about any set of applications wanting to share users.

[gbatalski]

Hello

My account is in a right groups and has enough permissions (i can configure whole system with it). But jira expects the role jira-administrators or jira-software-users  assigned in a target directory to work correctly. Possibly, i may further configure fine granular permissions depending on other directory roles/groups, but the global access to jira application was possible only after i've assigned the groups jira-administrators or jira-software-users to me in a target, for jira read-only, directory.

It's not a good solution even the only one i've found for now, because our firm may have multiple jira instances in a future and not all users should be permitted to use them all. I think, jira should support the role/group to permission/application mapping just like confluence does.

Gena

[gbatalski]

One more thing: The local assignment to the role jira-administrators, jira-software-users etc. was not possible as the local user management is disabled and the remote directory is a read-only one... 

[Nic Brough -Adaptavist-]

> jira should support the role/group to permission/application mapping just like confluence does.

It already does.  It's a different shape because it has more complex layers, but it's the same underlying principle.

>My account is in a right groups and has enough permissions (i can configure whole system with it).

Again, that is irrelevant.  Please re-read my first answer.

>But jira expects the role jira-administrators or jira-software-users

No.  It expects the user to be groups.  There are a number of named groups that grant access to various parts of the applications.  There are two places:

1.  For Application access (JIRA Core, JIRA Software and JIRA Service Desk are licenced independently), see Admin -> Applications -> Application access

2. For some general functions, including both levels of administration, bulk edit rights, sharing objects etc, see Admin -> Global permissions

In both of these cases, you can change the groups the system uses for them.   This completely removes your "our firm may have multiple jira instances in a future" concern because you can simply set up "jira 1 admins", "jira 2 admins", "jira 1 users", "jira 2 users" and so-on, then set them in the config.

Now, you have an external user and group management system, so you've got a set of groups you can work with.  The people looking after those will have to support your requirements for different groups, but once you've got the basic ones you need to get people access and admin, you don't actually need more, because JIRA can work with the groups or with individual users.

In Confluence, you grant groups and users direct access.  JIRA has a LOT more permissions to worry about so it does this with extra layers of permission schemes and roles, which give you the same flexibility that you see in confluence (in fact, more, because you can also nominate people with watchers and fields, use dynamic roles such as assignee and reporter, and and and)

[gbatalski]

for 1. I'm not able to grant application access explicitlly. The error message says, the target directory is read-only.

for 2. I've configured these to my groups, but they don't have any affect to browsing projects/issues.

Only the assignment the jira.... groups/roles in a remote directory helped. I double checked this by removing the assignment. The user was not allowed to see the projects even it has a project role to do it and the global setting allowes the browsing for all logged in users and he was logged in. 

The permission schemes are ok, but without jira... groups/roles they didn't grip.

Any other possibilities are appreciated, because it may not be always possible to have the jira.. groups in a remote directory. 

[Nic Brough -Adaptavist-]

1. Granting application access is NOT done by changing the user directory.  I really don't understand what you are trying to do here.

2.  No, they don't.  Yet again, the rights to use projects are granted in the project permission scheme.

>The user was not allowed to see the projects even it has a project role to do it and the global setting allowes the browsing for all logged in users and he was logged in. 

That's correct, that is exactly what it should be.  You need to grant the user the ability to use the application.  Separately, you need to make them match the permission to see each project.

I'm struggling to understand what the problem is here.

[Steven F Behnke]

I'm really not sure but I think he's saying that the groups don't sync from the external directory but if he adds the groups locally within JIRA it does work.

Gena, can you please provide any technical information on your configuraration at all? We have no idea what the problem is because you're not actually descibing your setup.

[gbatalski]

No, i want to say, the assignment of groups jira... in an external directory causes the correct recognition of user to be enabled for jira application. If the groups jira... aren't assigned within the foreign  directory, which is for jira read-only and connected via crowd, it is not possible to enable the jira application for user. He still be an administrator, just like configured within the global permissions, but he can not use jira application as user.

Direct assignment to application in Jira is not allowed due to read-only character of crowd directory (it shouldn't be, but it is so!). Any other assignments of foreign groups to project roles or even directly to permissions (eg. browse projects, browse issues etc.) doesn't have any affect...

until jira... group(s) assigned to user in a foreign directory, as i already mentioned previously.

[Nic Brough -Adaptavist-]

>the assignment of groups jira... in an external directory causes the correct recognition of user to be enabled for jira application

So you're saying "The user is in a group.  That group is named as a "can use application" group in the application access.  This user can now log in.

If they are not in a "can use" group, they can not use JIRA (unless you do the wrong thing and make them an admin.  Which still does not let them use it in full because they still do not have "can use")

That is absolutely correct, and how it should work.  It sounds like your groups are populated incorrectly, and you need your user directory admins to put the right people into the "can use JIRA" group.
>Direct assignment to application in Jira is not allowedThis is the bit I don't understand.  What do you mean by "direct assignment to application"?  The other permissions after log in are determined by project permissions, where you can use groups, individuals or roles (which is the best way to go).  But whatever you do there, your  user has to be able to use JIRA to get to the projects.  i.e. in a "can use" group (same as Confluence)

[Deleted user]

There is a problem (also as of 7.4.2) to map the jira application access to custom groups (via `/secure/admin/ApplicationAccess.jspa`). After selecting the group i want gain the application access to jira-software, i'm getting folowing error

End the FF console shows this message:

11:45:47.738 ajax[42347681] error : {
successful : false,
status : 412,
statusText : error,
hasData : true,
readyState : 4,
requestId : 42347681,
aborted : undefined,
} 1 batch.js:1206:168

So my custom groups are not allowed to login into Jira even the (global) permissions may be successfully assigned.

[Nic Brough -Adaptavist-]

That suggests an error in the user directory somewhere.  Read the application log to find out what is going wrong.

[Deleted user]

Sorry, but default logs saying nothing (either jira or crowd). I only see the

"PUT /rest/api/2/applicationrole/jira-software HTTP/2.0" 412 101

 The group from screenshot appears shortly and after clicking on refresh disapears again.

Regards

[Nic Brough -Adaptavist-]

I am stuck then - it suggests the browser is sending something which triggers a process which fails, but if the application logs say there are no errors, it can't have started it, or you would see errors in there.

[Steven F Behnke]

I found this problem myself when we had LDAP Groups in the Application Access and the LDAP group was deleted. 

Re-creating the group within Jira made it possible to use the Application Access screen again, and we were able to remove the offending item from Application Access.