this means, that there is something wrong with your ACL and group definition on either Source or Target Server or on both.
Most likely one of the ACLs you try to deploy has no members defined.
I have seen similar entries when using Central User Management and the ACL was referencing a Group or Role in MWS system directory which did not exist there.
Usually I do not deploy ACLs and Groups from one IS to another as their content might be differing.
Instead I create the ACLs and their contents manually on the targets and define the ACLs as existing.
Initially I did not want to deploy ACL;
I was just deploying my packages. but during the checking step, the Deployer asks for resolving ACL dependencies.
In my ACL console, I can see :
Anonymous ACL :
Denied : none@–@
Maybe it’s just an issue ? “none@–@” means " ----none----" ?
Anonymous ACL :
Denied : ----none----
If it’s the same thing, maybe I can delete the “none@–@” item for it to be replaced by " ----none----" ?
When defining the deployment set and checking the dependencies just mark the ACLs as “Exists” and the Set will be satisfied.
As the mentioned ACLs are default ACLs they are always existing and cannot be removed.
Cedric – In general we come across this ACL issue if there is a conflict b/w source & target servers. If you are sure, target environment has the specified ACL’s then you can chose Ignore option.
Whenever possible I prefer Exists instead of Ignore as this will warn you when defining the map if there is something missing on the target. When using Ignore, this is simply bypassed without notification.
Additional information about the “none@–@”-entry:
This might indicate a wrong or missing Central Users Management configuration on IS.
Please check the JDBC Pools under Settings if there is a pool created for the MWS schema and assigned to the “Central Users” function.
This is needed when using Monitor especially.
In this case the MWS SAML Resolver URL under Settings → Resources should point to the appropriate MWS instance.
Thanks “MR as173d”… I always worried about warnings… specially when it comes for PROD… so I was hesitating to ignore.
Holger, you’re right : few days ago… I’ve noticed the CentralUsers was not configured.
So last week, I’ve configured this new CentralUsers pool and associated it to the “Central Users” function.
Then, I’ve change the SAML Url which was mistakenly pointing on localhost inplace of the correct MWS server.
So, I’ve corrected all that.
Maybe the “none@–@” entry could be created by the wrong previous settings, and now these entries can be safely deleted ?
(I see these ones under : “Anonymous ACL”, “Developers ACL” and “Internal ACL”),
do you remember if you had assigned a specific group or role to the deny section of these ACLs?
if not just delete this entry and it should revert to “—none—”.
You are right:
Such entries can occur when there are issues with the CentralUsers database.
Holger, what do you mean by “I do not deploy ACL”… you mean that you click on “Ignore” for each ACL group warnings displayed during the Checking step ?
For custom ACLs, when we hand over the build to the other team, there is an accompanying document in which is described how the build is deployed. In this document we specify the ACLs and that they need to be created before the deployment of the build otherwise the map in Deployer will warn that the ACLs are missing.
About the additional ACLs:
yes these are expected.
Deployer creates them automatically.
By using these ACLs you can restrict access to Deployer projects.
I.e. Who can view, modify or deploy the projects.
Deployer Users Guide should have more informations about this.