Only Users role is displayed.

Issue #16 resolved
David Sedlock created an issue

We have the roles Admin, Developers, Testers, ToBeInformed and Users. Only the Users role is now displayed by the plugin.

Capture.PNG

I"m pretty sure more roles were displayed in the past, otherwise I would not have continued to deploy the plugin.

Jira 6.4.6

Comments (14)

  1. Holger Schimanski repo owner

    Did you recently updated the plugin? Can you provide a screenshot of the permission scheme assigned to the project? Guess only role Users is assigned to Browse Project permission?

    Best regards Holger

  2. David Sedlock Account Deactivated reporter

    Yes, I have recently cleaned up the notifications scheme. Why should the Browse Project permission matter to which roles the plugin shows?

  3. David Sedlock Account Deactivated reporter

    I realized I had already had this discussion with you 3 years ago:

    From: Sedlock David (LQKG IT RDS) Sent: 24 September 2013 17:23 To: 'Holger Schimanski' Subject: RE: JIRASUP-1690 JIRA Project Role Tab plugin: Displays only Users role after upgrade to Jira 6. Hi Holger, I think the overloading is fairly harmless, but it makes the configuration difficult to understand. According to its definition, the "browse projects" permission allows users in different categories to view the project and its issues. So the roles you define there have to do with the users, not with the information to be displayed, which is, without the plugin, always the same. When you jump from that to the idea that the permission defines the sorts of information to be displayed, you've reoriented the permission in a disorienting way. Maybe these reflections will help you understand the difficulty: A simple way to define the permission is with Project Role (Users). With the plugin now, this means users of the project can see a list of other users of the project, but not the members of the other roles. To allow users to see other roles, say admin, you have to add Project Role (Administrators). But if you think of this in terms of the original meaning of the permission, it's redundant: the project admins must already be users, so the first permission should have been enough! Another problem that arises is that any admin following me, who hasn't heard of the overloading done by the plugin, will look at this permission and clean it up by removing the redundant roles! To be honest, I can't see why this functionality is needed. If a user can already see the project and its issues, why would you want to offer the possibility to hide the members of some roles from him? Jira is remarkably free of such "overloading" and hard-to-understand corner cases, so if I were you I would be reluctant to introduce one. If you really want this functionality, then better to offer a way to configure it directly, without resorting to any existing permission. Regards, David

    The important point was "it makes the configuration difficult to understand...Another problem that arises is that any admin following me, who hasn't heard of the overloading done by the plugin, will look at this permission and clean it up by removing the redundant roles!" So difficult I have again shot myself in the foot.

    After shooting myself twice, I have learned an important lesson: I'm going to uninstall the plugin. ;)

  4. David Sedlock Account Deactivated reporter

    Just looked at my past Jira issues and I find this is actually the 3rd time I have shot myself in the foot. ;)

  5. Holger Schimanski repo owner

    You are right. Maybe it is an easier approach to simply show all project roles used in the permission scheme instead of this work around showing all roles in browse project. Similar discussion I had some days ago with another user here in issue #15.

    I already started to change plugin behaviour (see here 7484fd8).

    Do you think, showing all project roles in the tab which are used in permission scheme assigned to the project is okay? Would this result in showing all relevant roles for you?

  6. David Sedlock Account Deactivated reporter

    Good news! I'm not sure I understand enough about how roles work in Jira to answer the question. It looks like the roles are defined for the instance, but the permission scheme actually determines which ones are used in a given project. (Otherwise the Project Role Browser would not provide an action to show which projects use it.)

    The bottom line is that the role tab in a project should display the roles that the project admin can determine. If that's done by looking at the project's permission scheme rather than the project itself, fine by me.

  7. Holger Schimanski repo owner

    I don't want to give the option to configure which role to show to the project admin. This this should not be on his shoulders as he can also not configure what permissions has what role. This is done by the JIRA admin. And you can have more roles in you JIRA and use these role in different permission schemes differently.

  8. David Sedlock Account Deactivated reporter

    Hi Holger, can you give me a perspective on this change? If it is soon come I will leave the plugin installed. Otherwise, I will permantly give up. ;)

  9. Holger Schimanski repo owner

    You can download projectroletab-2.3.0-rc1.jar from https://bitbucket.org/hski/projectroletab-public/downloads and install it via upload of jar file via Plugin Manager in JIRA. The plugin now shows all project roles, which are used in the permission scheme (and not only those with Browse Project permission).

    Would be very interested in getting feedback, if this solves your issue.

    Best regards, Holger

  10. Holger Schimanski repo owner

    Sorry, 2.3.0-rc is only for JIRA 7.0 to 7.2. There was a change in the JIRA API for user management and therefor the plugin it is not backward compatible to JIRA 6.x.

  11. David Sedlock Account Deactivated reporter

    Holger, I don't see a new version at Atlassian Marketplace with this fix. We're going to upgrade to Jira 7.2 in a month or so and I would like to install the fixed release of your plugin at the same time.

  12. Log in to comment