[3.0] What do we need?

[bakura10]

Once various PR from @jmleroux are merged, we can start talking about ZfcRbac 3, so that we can allow some BC breaks.

In overall, I'm very happy with the work we've done in ZfcRbac 2.x, and it proved to be super stable, powerful and efficient, so thank you everyone for the great ideas.

Dependencies

For ZfcRbac 3, I'm still wondering about dependencies. We have no valid reason to raise the minimum PHP version to 5.5, but:

• It would allows us to use ::class, remove the RecursiveIteratorIterator approach from RBAC, hence only keeping the most efficient generator one.
• ZfcRbac 2.x is very nice, and I'd don't expect ZfcRbac 3 to be that very different feature-wise, so ZfcRbac 2 can still be used for people that need PHP 5.4 compatibility.

At the same time, as ZfcRbac is a widely used module, raising the dependency two versions upper than the framework it is based on may be a bit frustrating for a lot of users.

RBAC

ZfcRbac is based on a ZF3 prototype (https://github.com/zf-fr/rbac) and I think we can say with some good confidence that the component is very good and that integrating it into ZF3 will not be a problem.

I don't have any idea about what kind of change could we do (excepting removing some now useless interfaces like PermissionInterface one).

ZfcRbac

• Pending PR: [3.0] AssertionInterface is now using an AuthorizationContext #250 this will bring more flexibility by allowing to know the asked permission in assertions. It also makes context a first-class citizen in the interface, which is nice.
• Parameterized Rbac: [RFC] [3.0] Context Aware RBAC #241 This is definitely something I want for 3.0.
• Annotation: I'm not considering to have this for ZfcRbac 3.0. This is a lot of work and needs a lot of thinking about how it should be used, both from a usability and performance point of view.

Do you have other features, BC... that you would like in ZfcRbac 3 ?

ping @spiffyjr @jmleroux @Ocramius @arekkas @danizord

[jmleroux]

At the same time, as ZfcRbac is a widely used module, raising the dependency two versions upper than the framework it is based on may be a bit frustrating for a lot of users.

For my clients in France, 5.3 is still the most widespread version. 5.4 is growing fast, but 5.5 is still very low. So it's not only a problem regarding the framework version, but also compared to clients environments.

IMHO, we should keep 5.4 as the requirement.

[aeneasr]

IMHO, we should keep 5.4 as the requirement.

I agree, PHP 5.3 doesn't provide patches for bugs any more, only for security issues. So it would actually be a good way of telling people: Upgrade your PHP! However, moving on 2 versions could potentially break a lot of stuff in legacy apps, so I agree with the 5.4 raise.

[jmleroux]

moving on 2 versions

We already require 5.4.

[jmleroux]

Do you have other features, BC... that you would like in ZfcRbac 3 ?

A "develop" branch

[aeneasr]

We already require 5.4.

Haha, my bad.

Annotation: I'm not considering to have this for ZfcRbac 3.0. This is a lot of work and needs a lot of thinking about how it should be used, both from a usability and performance point of view.

I agree, especially because annotations are unlikely to bc break, as they are a completely new feature.

[bakura10]

Ok, let's keep 5.4 as dependency.

I've created a develop branch that is aliased to 3.0

[atans]

php cli search permission name from *.php, *.phtml which file contains isGranted("permission.name")
or
auto update permission names to permission table of database Like doctrine orm:schema-tool:update

[jmleroux]

php cli search permission name from *.php, *.phtml which file contains isGranted("permission.name")

Sort of ZfcRbacDiagnostics ?