2 Replies Latest reply on Jun 30, 2005 4:00 PM by Michael Mraz

    Role specific Property Dictionary?

      I am trying to enforce the recording of a Change Control ticket number for certain types of jobs (NSH script, File deploy, BLdeploy, batch) under 6.2.3. I set up a CCNUMBER property in the Properties Dictionary logged into the role, made it a Job Specific value and made it mandatory for the types listed above.


      It did exactly what I wanted, not allowing the user to save or run the job without setting something for the property/parameter.


      But, then the problems started. The guys in QA, using another role, now had a mandatory job property to set for each job. Since they don't use the Change Control system in Dev/QA this was an unnecessary speedbump. So, they deleted the property from the dictionary within their role. That broke the desired process flow I set up in the original role.


      Why is the property dictionary shared among roles? Why do settings in one role show and affect behavior in another role? How do I prevent this from happening (especially one role deleting the paramters needed by another role)?* How do I enforce my mandatory field field requirement for a specific role without impacting other roles?




      • I do not need someone else's use of this functionality interfering with work being done in the CMAdmins, Root or other role. I can hear certain people complaining at me already...


        • 1. Re: Role specific Property Dictionary?

          Hopefully I can help a little bit here, but at the end of the day I'm not sure there's a perfect workaround for this:


          1) Not exactly sure why the dictionary is shared across roles, but the immediate thought that comes to mind is that if the dictionary was role-specific, it would be an absolute management nightmare for the end user. I think what you actually would want is to be able to set whether or not a property is required on a per-role basis. As you've seen, this can't be done today.


          2) You can restrict a role's ability to access/modify the property dictionary via authorizations. See "blade.property" in RBAC-->Authorizations.

          • 2. Re: Role specific Property Dictionary?

            1. Yes, sounds like the feature request is "Global/Role local" setting for properties. Or 2 dictionaries, a global dictionary where things like intrinsic properties live and a role local dictionary. The latter may be simpler to implement?!? (And, new features not for future releases, but enhancements/fixes to currently operating versions instead are prefered.*)


            2. I can't restrict their access as they need to be able to use this functionality when creating/testing new packages in Dev/QA.


            So, that leaves me still with:


            How do I prevent a user, who must be able to set properties, from breaking jobs in other roles by setting a new mandatory job property up?


            How do I make placing a Change Control ticket number into a job's information mandatory while limiting the scope of that requirement to a single role?


            The first one I don't have a solution for and the potential for intentional or accidental abuse is substantial. The second one we'll enforce by a policy requiring the ticket number be part of the job name or description and spot checking regularly for compliance.


            • Unfortunately our (and probably many other customers) upgrade cycle does not match the frequency of BL version releases. It has taken us a full 6 months of planning, building and incremental deployment for one upgrade. If we followed this process strictly and it only took 4-5 months I would spend 2/3 of every year working on upgrading to keep up with feature requirements. Patches/updates to current versions reduce this cycle significantly as they do not require all the porting and testing work done between revisions.