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

Authorization in FishEye based on settings imported from Subversion

    • Icon: Suggestion Suggestion
    • Resolution: Unresolved
    • None
    • User management
    • None
    • 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.

      Ability to synchronize access permissions from Subversion authorization file (authz) into FishEye (or other way around - let FishEye manage this file and access to repository).

            [FE-462] Authorization in FishEye based on settings imported from Subversion

            Atlassian Update – 24 July 2019

            Hi everyone,

            We have recently reviewed this issue and the overall interest in the problem. As the issue hasn't collect votes, watchers, comments, or support cases from many customers during its lifetime, it's very low on our priority list, and will not be fixed in the foreseeable future. That's why we've decided to resolve it as Not being considered.

            Although we're aware the issue is still important to those of you who were involved in the conversations around it, we want to be clear in managing your expectations. The Fisheye&Crucible team is focusing on issues that have broad impact and high value, reflected by the number of comments, votes, support cases, and customers interested. Please consult the Implementation of New Features Policy for more details.

            We understand how disappointing this decision may be, but we hope you'll appreciate our transparent approach and communication. Atlassian will continue to watch this issue for further updates, so please feel free to share your thoughts in the comments.

            Regards
            Marek Parfianowicz
            Development Team Lead
            Fisheye/Crucible Team

            Marek Parfianowicz added a comment - Atlassian Update – 24 July 2019 Hi everyone, We have recently reviewed this issue and the overall interest in the problem. As the issue hasn't collect votes, watchers, comments, or support cases from many customers during its lifetime, it's very low on our priority list, and will not be fixed in the foreseeable future. That's why we've decided to resolve it as Not being considered . Although we're aware the issue is still important to those of you who were involved in the conversations around it, we want to be clear in managing your expectations. The Fisheye&Crucible team is focusing on issues that have broad impact and high value, reflected by the number of comments, votes, support cases, and customers interested. Please consult the Implementation of New Features Policy for more details. We understand how disappointing this decision may be, but we hope you'll appreciate our transparent approach and communication. Atlassian will continue to watch this issue for further updates, so please feel free to share your thoughts in the comments. Regards Marek Parfianowicz Development Team Lead Fisheye/Crucible Team

            Hi, we are evaluating FishEye and this feature is important to us. We build software for different customers and permissions are managed in subversion authz for each repository (100's of them). We can't duplicate these settings using groups.

            Is this feature being considered to develop in the near future?

            Best Regards

            Manuel Arranz added a comment - Hi, we are evaluating FishEye and this feature is important to us. We build software for different customers and permissions are managed in subversion authz for each repository (100's of them). We can't duplicate these settings using groups. Is this feature being considered to develop in the near future? Best Regards

            In our environment, we have to restrict access to different source code modules from being read by external consultants in the same project in an SVN / LDAP environment. The only viable way is to group the directories sharing the same access control into one FishEye repository connection and assign each with an LDAP ACL filter.

            In my eyes, a design which uses the subversion authz file natively would be a big advantage.

            It should be considered as a user option to let Fisheye only maintain the repository Meta-Data (i.e. not the file content) and link the user for the file contents to an existing ViewVC, which adheres to the subversion's authz settings - or let FishEye dwnload the contents in the user's name from Subversion, once the content is requested. I.e. In the current use case it is not acceptable that FishEye maintains a somplete copy of the repository, including file contents as diff or as raw files if it retrieved these contents with the configuration manager administrative account. it must use the user's account to check availability of the data, even if that means the data needs to be downloaded at access time.

            Hans-Jürgen Tappe added a comment - In our environment, we have to restrict access to different source code modules from being read by external consultants in the same project in an SVN / LDAP environment. The only viable way is to group the directories sharing the same access control into one FishEye repository connection and assign each with an LDAP ACL filter. In my eyes, a design which uses the subversion authz file natively would be a big advantage. It should be considered as a user option to let Fisheye only maintain the repository Meta-Data (i.e. not the file content) and link the user for the file contents to an existing ViewVC, which adheres to the subversion's authz settings - or let FishEye dwnload the contents in the user's name from Subversion, once the content is requested. I.e. In the current use case it is not acceptable that FishEye maintains a somplete copy of the repository, including file contents as diff or as raw files if it retrieved these contents with the configuration manager administrative account. it must use the user's account to check availability of the data, even if that means the data needs to be downloaded at access time.

            is there any solution to this problem?

            Alexander Falteysek added a comment - is there any solution to this problem?

            With respect to this request, please be aware fine-grained authz support is not on the FishEye roadmap (the ability to authz at the file/directory level).

            Matt Quail (Inactive) added a comment - With respect to this request, please be aware fine-grained authz support is not on the FishEye roadmap (the ability to authz at the file/directory level).

              Unassigned Unassigned
              73d805a2526b MattS
              Votes:
              21 Vote for this issue
              Watchers:
              19 Start watching this issue

                Created:
                Updated: