A soft dependency could be better.

You can play withclass_exist andCommand::IsEnable method

@lyrixxdoctrine-bundle is only needed to run the tests. It's arequire-dev dependency.
Making it a soft dependency is awkward because all functional tests on the ACL system will be skipped by default.
If someone clone the repository, start hacking, run phpunit and make a PR, he can silently broke the ACL system.

It will also require tweaking.travis.yml (to make Travis installdoctrine-bundle before running the tests) and update the doc to explain that tests should be run withdoctrine-bundle installed.

If it's really annoying to havedoctrine-bundle as a development dependency, I prefer registering the DBAL connection directly in the test app's kernel.

Let me know which solution is better.

Sorry. I did not see it was a dev deps ;)

You're welcome.

The Help should be expanded to explain the main use cases (probably using the defined options).

This should beVALUE_NONE IMO

VALUE_OPTIONAL means that you don't need to pass a value when using this option, so--security-class is valid; which looks wrong to me. Again, any required value should probably be an argument and not an option.

This is not required to pass a security class. You must pass at least a security class and a security username OR a role.

This is checked lines 104 to 108.

But when using the--security-class, you must pass a class name, right? If that's the case, you must useVALUE_REQUIRED.VALUE_OPTIONAL means that thevalue for the option is optional, not the option itself. An option isalways optional by definition.

Ok I got it. For required values, how to handle several arrays as arguments?
Object IDs and permissions are required and are arrays.

Should I use an argument for one of them (which) and leave the other as a (required) option?

What if the user did not provide a--object-id option? You're going to getnull here. That's why I said thatall required informationmust be managed via arguments, not options. To avoid getting too many of them, you can maybe have some conventions likeclass:id.

weird variable name

Indeed.

Hi@dunglas, I'm redacting a "New in Symfony 2.6" blog post about the newacl:set and I wonder if this help message is correct. If you are using the--class-scope, you are granting access to all the objects of the same class, so the trailing object id (42 in this case) should be removed, right?

Original help message:

<info>php %command.full_name% --class-scope --user=Symfony/Component/Security/Core/User/User:anne OWNER Acme/MyClass:42</info>

Proposed help message:

<info>php %command.full_name% --class-scope --user=Symfony/Component/Security/Core/User/User:anne OWNER Acme/MyClass</info>

Hi@javiereguiluz. This help message is correct. It should not be modified. This how the underlying ACL system works (and I agree that this is far from perfect).

The class scope can be set only is you precise an object identity (otherwise an error will be thrown). Technically, it will not grant access to all objects of the same class but only to all objects of this class present in the ACL table.

e.g:

• You have three objects:Untitled #1,Renaming "Entities" to "Entity" #2 andUntitled #3.
• ACL are initialized forUntitled #1 andUntitled #3 but not forRenaming "Entities" to "Entity" #2.
• You grant access to an user with the class scope.
• Access will be granted forUntitled #1 andUntitled #3 but not forRenaming "Entities" to "Entity" #2.

@dunglas thanks for your reply. I now understand that everything is correct. However, I find this behavior amazingly counterintuitive. Moreover, in thescopes for access control entries section of the documentation it says:

Class-Scope: These entries apply to all objects with the same class.

This is quite different from what you have said.@wouterj don't you think that the documentation should better explain this strange behavior?