|
|
|
[
Permlink
| « Hide
]
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.
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(); } 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 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. 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.
|