<< Back to previous view |
[QB-3267] Support wildcards in Configuration Path for PermissionSets/Groups Authorizations
|
|
Status: | Closed |
Project: | QuickBuild |
Component/s: | None |
Affects Version/s: | 8.0.22 |
Fix Version/s: | None |
Type: | Improvement | Priority: | Minor |
Reporter: | John Landers | Assigned To: | Robin Shen |
Resolution: | Won't Fix | Votes: | 0 |
Remaining Estimate: | Unknown | Time Spent: | Unknown |
Original Estimate: | Unknown |
Description |
It would be nice to have wilcard support so we don't have to manually add entries when a new configuration is added.
Example: root/Deploy/SiteAbc/DeployCfg root/Deploy/SiteDef/DeployCfg root/Deploy/SiteXyz/DeployCfg .... Would be nice to allow: root/Deploy/*/DeployCfg Any child named DeployCfg. |
Comments |
Comment by John Landers [ 18/Aug/20 10:42 PM ] |
Any chance this will get impl soon. |
Comment by Robin Shen [ 18/Aug/20 10:47 PM ] |
Unfortunately this is almost impossible to implement as QB maintains configuration/group/user authorizations via foreign key which means that an authorization entry should be mapped to a single configuration. Using wildcards will break this structure and lost the guarantee from database for data consistency. |
Comment by John Landers [ 18/Aug/20 11:11 PM ] |
Ok that makes sense. I didn't see this issue closed.
What about adding another field to Group that supports a script to build additional list of configurations. Manually picking through 30 configurations is a lot of work. |
Comment by Robin Shen [ 18/Aug/20 11:32 PM ] |
I forgot to close this issue. Adding another field to script this can be confusing:
1. It is not easy to determine which setting will be taking effect 2. If script content is changed, the authorization database entry might be out-of-sync with the script 3. If another configuration added matching wildcard of the script, the configuration will not be authorized automatically unless the script has a chance to run |
Comment by John Landers [ 18/Aug/20 11:52 PM ] |
ok thanks.
We will take another route and create a build configuration to walk the configuration tree and based on a provided wildcard update the Groups with the authorizations based on the found configurations, add or replace or remove. Play code: groovy: com.pmease.quickbuild.persistence.SessionManager.openSession(); try { def grpMgr = com.pmease.quickbuild.entitymanager.GroupManager.instance; def grp = grpMgr.get("TestGroup"); logger.info("Group:" + grp); logger.info("GroupDesc:" + grp.getDescription()); def auths = grp.getAuthorizations(); for (auth in auths) { logger.info("Auth:" + auth.getConfiguration().getPathName() + " Perms:" + auth.getPermissions()); } def authMgr = com.pmease.quickbuild.entitymanager.AuthorizationManager.instance; def newAuth = new com.pmease.quickbuild.model.Authorization(); newAuth.setConfiguration(configuration); // add any configuration for now, finding them is easy part. newAuth.setGroup(grp); newAuth.setPermissions([]); authMgr.save(newAuth); } finally { com.pmease.quickbuild.persistence.SessionManager.closeSession(); } |
Comment by Robin Shen [ 19/Aug/20 12:01 AM ] |
Yes, this will work. You may pass wildcard configuration via variable and do flexible things inside the script. I like this approach as this makes it explicit that anytime something is changed, I need to run the configuration. |