History | Log In     View a printable version of the current page.  
Issue Details (XML | Word | Printable)

Key: QB-3267
Type: Improvement Improvement
Status: Closed Closed
Resolution: Won't Fix
Priority: Minor Minor
Assignee: Robin Shen
Reporter: John Landers
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
QuickBuild

Support wildcards in Configuration Path for PermissionSets/Groups Authorizations

Created: 01/Oct/18 04:51 PM   Updated: 19/Aug/20 12:01 AM
Component/s: None
Affects Version/s: 8.0.22
Fix Version/s: None

Original Estimate: Unknown Remaining Estimate: Unknown Time Spent: Unknown


 Description  « Hide
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.


 All   Comments   Work Log   Change History      Sort Order:
John Landers [18/Aug/20 10:42 PM]
Any chance this will get impl soon.

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.

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.

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

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();
}

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.