Qu: why does this product cover so many permissions?

[djowett]

A standard plone workflow covers a handful of permissions - typically 3 or 4.

Where as ftw.lawgiver sets 50 or so permissions.
While it does it very succinctly by the use of action groups, it does concern me that permissions be set up differently to standard Plone - resulting in behavior that was unexpected or strange to the seasoned Plonista.

Any reason why you set so many permissions? Did it start off this way?

thanks again @jone!!
Daniel

[jone]

The standard Plone workflows are quite simple indeed. Only a few permissions are set. That means the security of a given object is mostly defined by the security of the parents, so the permission-role-mapping is acquired from the acquisition chain.
This has the advantage that the workflow is simple to understand and easy to manage.
The disadvantage is that it is very implicit. In practice it means that when we use simple workflows for most types but an object in the acquisition chain has a more complex workflow resetting the permission-role-mapping in an unexpected way, we can experience unexpected behavior on the given object. It is then quite hard to understand why it behaves that way.

ftw.lawgiver has a different approach. As a developer, we only write a specification of how the workflow should behave. The lawgiver then makes sure that it works that way. In order to be able to ensure the specified behavior the workflows basically disable inheritance of permission-roles from the parent by disabling the acquisition of the managed permissions.
Since the mapping is automatically generated by lawgiver, we can manage a lot of permissions without increasing the workload for developers.
The result is that we have a very explicit workflow which behaves exactly as described in the specification without negative impact from other objects or their workflows.

This approach has its limitations though. It is, for example, not possible that the workflow of a child object extends roles for a permission while also acquiring the setting from the parent. We didn't yet run into that problem though 😉

So this design is on purpose and we got along quite good with it. We have devs writing workflows without really looking in the actual workflow definition nor having to understand what's happening there.

I hope this helps understand why we chose this approach 😉

[djowett]

Thanks Jonas for taking the time to explain, that makes a lot of sense to me. I've had a bit of a fight with inherited permissions recently. :-)

…

On 5 April 2019 10:07:07 BST, Jonas Baumann ***@***.***> wrote: The standard Plone workflows are quite simple indeed. Only a few permissions are set. That means the security of a given object is mostly defined by the security of the parents, so the permission-role-mapping is acquired from the acquisition chain.> This has the advantage that the workflow is simple to understand and easy to manage.> The disadvantage is that it is very implicit. In practice it means that when we use simple workflows for most types but an object in the acquisition chain has a more complex workflow resetting the permission-role-mapping in an unexpected way, we can experience unexpected behavior on the given object. It is then quite hard to understand why it behaves that way.> > `ftw.lawgiver` has a different approach. As a developer, we only write a specification of how the workflow should behave. The lawgiver then makes sure that it works that way. In order to be able to ensure the specified behavior the workflows basically disable inheritance of permission-roles from the parent by disabling the acquisition of the managed permissions.> Since the mapping is automatically generated by lawgiver, we can manage a lot of permissions without increasing the workload for developers.> The result is that we have a very explicit workflow which behaves exactly as described in the specification without negative impact from other objects or their workflows.> > This approach has its limitations though. It is, for example, not possible that the workflow of a child object extends roles for a permission while also acquiring the setting from the parent. We didn't yet run into that problem though 😉 > > So this design is on purpose and we got along quite good with it. We have devs writing workflows without really looking in the actual workflow definition nor having to understand what's happening there.> > I hope this helps understand why we chose this approach 😉 > > -- > You are receiving this because you authored the thread.> Reply to this email directly or view it on GitHub:> #89 (comment)

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.