Handle access rights on our flows
We're using HP-OO 10.22, and the number of OO developpers is increasing significantly in our company. We definitely need to protect our existing code from OO-beginners.
I couldn't find in HP documentation any information related to access rights at project level: for instance, forbid SCM-Commit to some users. Did I miss that information?
I guess there might be some settings on SVN, but I'd rather have some OO-embedded solution if it exists. Any hint someone?
Thanks in advance,
I believe what you are faced with is the advanced administration of the SVN structures.
Out of the box, I do not believe it has integration to manage the VisualSVN provided to that level of complexity.
If you read the manual for VisualSVN, you will find that you can restrict your branches and paths to provide the effect I believe you are looking for.
This may take you beyond the scope of what HPE Software will support (meaning you have to have someone responsible for managing the SVN). Consider restricting who can publish the content packs in OO to help minimize impact if you haven't. And also don't forget to "Enforce Locking Policy" to make sure someone doesnt edit a flow you are working on. (all covered in the Studio guide)
On 10.22 currently it is not possible to do what you want out of the box, however after upgrading OO to 10.5x (latest version is 10.51) OO will also support GIt as part of SCM and in git it is easyer to perform the kind of restrictions you require.
Thank you very much for your feedback and all the detailed information. I will look into it and contact our SVN admin to see what's feasible or not in our case.
Thank you, this is good information, and it probably will be my plan B: use Git instead of SVN while upgrading to 10.5x.
Our SVN environment has many more uses than HP-OO repository, therefore it's easier for us to stay on SVN for the moment, but if SVN makes it hard for us to adapt access rights to our needs, then GIT it will be 🙂
Path-based authorization of Apache Subversion is what you are looking for. Authorization has to be implemented and managed on the server and the repository, locally or remotely.
As @demena already suggested, read SVNBook | Path-based authorization chapter. This documentation chapter provides comprehensive description of the authorization mechanism. But if you are looking for a IMO better summary of it, read KB33: Understanding VisualSVN Server authorization. I suggest reading this article because when using VisualSVN Server you won't ever have to write authorization rules yourself as it's described in SVNBook on low level. The configuration of access rules is perfomed either in the VisualSVN Server Manager MMC console, VisualSVN Repository Configurator tool or through VisualSVN PowerShell cmdlets.
I guess that the Repository Management Delegation is the feature that you'd find most helpful in your case. It should help you to assign repository supervisors who can manage access rules on your projects or repositories.
@VladM, could you please explain how managing user authorization and access is easier in Git than in SVN?
I'm asking this just because I'm a bit confused and you could shed some light on this. If you are an experienced Git user, you should know that Git - as a distributed version control system - does not have any real granular built-in access control. Every Git user has complete read access to the repositories. Write access is controlled by liuetenants / dictators / integration managers who control merges or pulls when following distributed workflows. But this is not one jot or little easier than the workflows commonly used with Subversion when you can simply assign various levels of access to different user groups or users.
Exactly this thing you are mentioning is what i mean, That write access controlled by "liuetenants / dictators / integration managers" system is what the original usecase was all about, as far as i understand it, since the use case in part was about forbidding SCM commit to some users.
With this in mind obviously the solution i thought of was Git's managed pull request system, because if author A (who is forbidden SCM commit) makes w worth while change that author B (who is an experienced author that knows the project well) will review and decide that it is worth commiting the end result is still the use case of GIT managed pull requests.
Now if talking about user X doesn't see parts of project Y that is a different disscussion alltogether.