Darn I didn’t see/forgot about ERAuth. I had this project on the shelf for a year so I forgot about that. Anyway, all this makes a lot of sense in that context. I bought into Ponder last year, so I best not fight it. I am using a portion of ERAuth, but will need to review my login as that doesn’t go through d2w. Anyway, it’s all coming back to me quickly.
Thanks again James > On Nov 13, 2014, at 12:32 PM, Ramsey Gurley <[email protected]> wrote: > > In ponder, all the Edit* property level components have a disabled binding. > By default, they are enabled/disabled using rules for ‘disabled’ RHS key > found in ERD2W. Since Ponder reuses the edit* components on inspect pages, > then there is one additional rule. > > 15 : task = 'inspect' => disabled = "true" > [com.webobjects.directtoweb.BooleanAssignment] > > 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 > > 10 : task = 'edit' => disabled = (null) [ERADefaultAuthorizationAssignment] > > 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 protected] > <mailto:[email protected]>> 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 protected] >> <mailto:[email protected]>) >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/webobjects-dev/rgurley%40smarthealth.com >> >> <https://lists.apple.com/mailman/options/webobjects-dev/rgurley%40smarthealth.com> >> >> This email sent to [email protected] >
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
