Uploaded image for project: 'FishEye'
  1. FishEye
  2. FE-629

FishEye should be able to manage Subversion repository permissions

    • Icon: Suggestion Suggestion
    • Resolution: Won't Fix
    • None
    • None
    • Enterprise Edition, Standalone
    • Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

      JIRA Enterprise Edition should be able to manage Subversion repository permissions like JIRA Studio does.

      We've been evaluating JIRA as a possible replacement for GForge Advanced Server, and from a centralized administration perspective having JIRA be able to manage the SVN repositories that are associated with projects and components would be most beneficial.

      The fact that it exists in JIRA Studio makes me think that this functionality is already available in some fashion.

      This issue is to request that the SVN Permission Manager in JIRA Studio be made available in JIRA Enterprise.

            [FE-629] FishEye should be able to manage Subversion repository permissions

            Ray McDermott added a comment - Oops - that link should be http://confluence.atlassian.com/display/FISHEYE/Enabling+Repository+Management+in+FishEye

            Just to be clear that previous comment is a request for you to reopen in the light of your new approach

            Ray McDermott added a comment - Just to be clear that previous comment is a request for you to reopen in the light of your new approach

            http://confluence.atlassian.com/display/FISHEYE026/Permissions
            You have support for permission management in DVCS so this should be provided for SVN

            Ray McDermott added a comment - http://confluence.atlassian.com/display/FISHEYE026/Permissions You have support for permission management in DVCS so this should be provided for SVN

            Hi,
            I'm going to close this issue at this point as our intention is to have FishEye continue with a "read-only" interaction with the SCMs.
            Thanks,
            Tim

            Tim Buntel [Atlassian] added a comment - Hi, I'm going to close this issue at this point as our intention is to have FishEye continue with a "read-only" interaction with the SCMs. Thanks, Tim

            Hi all,

            There appears to be a couple of different use-cases being talked about on this issue:

            1. A GUI to manage svn permissions, as in JIRA Studio. This is not directly related to FishEye and was originally a JIRA feature request.
              1. We have no plans to release this part of Studio; it's really tightly coupled to our specific Studio infrastructure and would take a lot of work to generalise.
              2. However, you can get a lot of the way there with Crowd's svn connector: it will allow you to relate groups to svn paths, and manage the group memberships from within Crowd's GUI. More details: http://confluence.atlassian.com/display/CROWD/Integrating+Crowd+with+Subversion
            2. The ability to restrict repository viewing in FishEye in the same way you can you can use AuthzSVNAccessFile to restrict command-line repository access.
              1. The FishEye team have decided that they're not going to implement this feature. There's more detail on why in FE-1620.


            Sorry for the bad news.

            Cheers,
            Dave O'Flynn
            Integration Product Manager.

            David O'Flynn [Atlassian] added a comment - Hi all, There appears to be a couple of different use-cases being talked about on this issue: A GUI to manage svn permissions, as in JIRA Studio. This is not directly related to FishEye and was originally a JIRA feature request. We have no plans to release this part of Studio; it's really tightly coupled to our specific Studio infrastructure and would take a lot of work to generalise. However, you can get a lot of the way there with Crowd's svn connector: it will allow you to relate groups to svn paths, and manage the group memberships from within Crowd's GUI. More details: http://confluence.atlassian.com/display/CROWD/Integrating+Crowd+with+Subversion The ability to restrict repository viewing in FishEye in the same way you can you can use AuthzSVNAccessFile to restrict command-line repository access. The FishEye team have decided that they're not going to implement this feature. There's more detail on why in FE-1620 . Sorry for the bad news. Cheers, Dave O'Flynn Integration Product Manager.

            Hi,
            I was looking around if it was possible to handle svn access rights to a repo used by a Jira project, and found this issue. I know it is possible to handle common authentication with Crowd, but this does not fill my needs. As previous members said, it would be great if user assignment to a jira project could automatically set user access rights to the svn repository of that project.
            Or is there is way of scripting this? (watching user changes in jira project and modify svn access rights accordingly)
            Regards,
            Al

            Costa Albert added a comment - Hi, I was looking around if it was possible to handle svn access rights to a repo used by a Jira project, and found this issue. I know it is possible to handle common authentication with Crowd, but this does not fill my needs. As previous members said, it would be great if user assignment to a jira project could automatically set user access rights to the svn repository of that project. Or is there is way of scripting this? (watching user changes in jira project and modify svn access rights accordingly) Regards, Al

            If FishEye were to access the respective repository with the logged in user making the actual request, then it would be subject to the same restrictions as that user is.

            Igor Galić added a comment - If FishEye were to access the respective repository with the logged in user making the actual request, then it would be subject to the same restrictions as that user is.

            Partha added a comment -

            Another workaround, is if your LDAP users belong to groups and you can restrict access to repositories via groups rather than per user, then go to Administration > Security and you can setup a group filter to restrict access per a repository.

            Remember if you have a group object that contains the users, you will need to set the "match type" to any rather than user.

            If you are having trouble setting up the group filters, remember that you can test authentication via Administration > Security > LDAP authentication, which will give you the query it runs against your ldap server and the result for each of your repository filters.

            Partha added a comment - Another workaround, is if your LDAP users belong to groups and you can restrict access to repositories via groups rather than per user, then go to Administration > Security and you can setup a group filter to restrict access per a repository . Remember if you have a group object that contains the users, you will need to set the "match type" to any rather than user. If you are having trouble setting up the group filters, remember that you can test authentication via Administration > Security > LDAP authentication, which will give you the query it runs against your ldap server and the result for each of your repository filters.

            Partha added a comment -

            Dear Howard,

            Is this "[fisheye-repository-name]" in his example a place holder for the real name of the repository or is it a variable passed from Fisheye?

            You need to replace [fisheye-repository-name] with the name of your repository. I.e it is not a variable passed from Fisheye, as Fisheye is not even aware that you have apache set up in front of it.

            In the above example Gunther is using AJP, but you can use proxy pass as defined at Integrating with other Websevers

            I.e something like the following:

            ProxyPass /fisheye http://[HOST]:8060/fisheye
            
            <Location /fisheye/browse/[fisheye-repository-name]>
              SVNPath /var/www/svn
            
              # access control policy
              AuthzSVNAccessFile /etc/httpd/conf/svn.authz
            
              AuthType basic
              AuthName "Access to Subversion projects browsing"
              AuthUserFile /etc/httpd/conf/svn.passwd
              Require valid-user
            </Location>
            

            I hope that makes things clearer.

            Kind Regards,
            Partha Kamal

            Partha added a comment - Dear Howard, Is this " [fisheye-repository-name] " in his example a place holder for the real name of the repository or is it a variable passed from Fisheye? You need to replace [fisheye-repository-name] with the name of your repository. I.e it is not a variable passed from Fisheye, as Fisheye is not even aware that you have apache set up in front of it. In the above example Gunther is using AJP, but you can use proxy pass as defined at Integrating with other Websevers I.e something like the following: ProxyPass /fisheye http: //[HOST]:8060/fisheye <Location /fisheye/browse/[fisheye-repository-name]> SVNPath / var /www/svn # access control policy AuthzSVNAccessFile /etc/httpd/conf/svn.authz AuthType basic AuthName "Access to Subversion projects browsing" AuthUserFile /etc/httpd/conf/svn.passwd Require valid-user </Location> I hope that makes things clearer. Kind Regards, Partha Kamal

            I would really like to have this feature added. I have over 200 repositories, some of them very restricted. I would like to have Fisheye look into my Subversion access control file defined by "AuthzSVNAccessFile" and give access as defined in the access control file.

            Gunther, above, is proposing a work around but I'm not an Apache GURO so I'm mission some of the details of his example. If anyone can help me I would be most thankful.

            In Gunther's example what connection method does he use?
            Is this "[fisheye-repository-name]" in his example a place holder for the real name of the repository or is it a variable passed from Fisheye?

            Thanks,
            Howard V.

            Howard Vanfleet added a comment - I would really like to have this feature added. I have over 200 repositories, some of them very restricted. I would like to have Fisheye look into my Subversion access control file defined by "AuthzSVNAccessFile" and give access as defined in the access control file. Gunther, above, is proposing a work around but I'm not an Apache GURO so I'm mission some of the details of his example. If anyone can help me I would be most thankful. In Gunther's example what connection method does he use? Is this " [fisheye-repository-name] " in his example a place holder for the real name of the repository or is it a variable passed from Fisheye? Thanks, Howard V.

              Unassigned Unassigned
              d3413ebbaf32 Kutsal Berberoglu
              Votes:
              8 Vote for this issue
              Watchers:
              10 Start watching this issue

                Created:
                Updated:
                Resolved: