If you add the ERAuth framework, it opens a new can of worms. That overrides the ‘disabled' RHS key binding with a permissions based approach on edit pages
That assignment delegates this authority to whatever object you have assigned to the ‘crudAuthorization’ RHS Key. You’ll also noticed there is another binding handled by that assignment object
10 : task = 'inspect' => displayProperty = (null) [ERADefaultAuthorizationAssignment]
These correspond to the methods canUpdateProperty and canReadProperty on your CRUDAuthorization object. There are a number of existing CRUDAuthorization objects provided. By default, it says NO
0 : *true* => crudAuthorization = "er.auth.SimpleCRUDAuthorization.DENY_ALL" [ERDEnumAssignment]
But you can change that to YES
10 : *true* => crudAuthorization = "er.auth.SimpleCRUDAuthorization.ALLOW_ALL" [ERDEnumAssignment]
Those aren’t very useful, but if you just want to get moving in model development, that can do the trick.
Another available assignment class is the RoleBasedCRUDAuthorization class. By itself, it only reads role based authorization flags out of the database. Perhaps you have a role named Sales which can read and update a product Quantity attribute, but can only read the price attribute. Maybe you have another role named Manager who can read and update both of those attributes.
All that can be handled without any logic by simply checking boxes in a role based authorization d2w page. Typically, things are rarely all true/false in every case, so you can subclass the RoleBasedCRUDAuthorization object to fine tune certain permissions.
If you are interested in seeing a fully implemented CRUDAuthorization object, look in ERUsers at the AuthorizationDelegate enum.
10 : (entity.model.name = 'ERUsers' or pageConfiguration = 'CreateERUser') => crudAuthorization = "er.users.delegates.AuthorizationDelegate.INSTANCE" [ERDEnumAssignment]
Make note that the ERASelector is similar to NSSelector, but it allows you to override methods based on the argument’s class. So when you see methods like:
public Boolean canReadProperty(EOEnterpriseObject eo, String keyPath)
public Boolean canReadProperty(ERUser eo, String keypath)
public Boolean canReadProperty(MyUser eo, String keypath)
ERASelector will pick the most specific method based on the eo argument. If eo is a MyUser instance and MyUser subclasses ERUser, then the method
public Boolean canReadProperty(MyUser eo, String keypath)
would win. If MyOtherUser also subclasses ERUser, then the more general ERUser method would be used because there’s no method specific to MyOtherUser. If eo is an instance of some other entity, then the generic EOEnterpriseObject method is called.
Using the CRUDAuthorization approach, you can supply all your permission logic in a single class as I did in ERUsers. There may be more details in my last WOWODC presentation if that screencast is up somewhere.
On Nov 13, 2014, at 10:34 AM, James Cicenia <
email@hidden> wrote:
This, I think is a Ponder question.
After coming back to the problem of the non-enterable forms, I have identified that there is no
explicit rule setting disabled to false in any of the frameworks I used.
All the rules set the flag to true, but those are all list and inspect type tasks.
James
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden