If you're looking to limit the keys you want to display in inspect and list pages, maybe you could force use of a custom version of ERDAttributeRepetition via ERXPatcher. I can see this being of use at least as a sort of safety net.
Am 27.02.2013 um 15:23 schrieb David Avendasora: > I think I understand what you are saying better now. > > But I think I'd rather have a bunch of extra displayPropertyKeys rules that > are based on the rights a user has vs. creating a bunch of custom components > and corresponding customComponent rules based on the rights a user has. > > Now, I do like your suggestion if there's a whole additional section of a > page that one user sees that another does not. I have that need as well and I > really appreciate this tip! > > Thanks! > > Dave > > > On Feb 27, 2013, at 10:07 PM, Theodore Petrosky <[email protected]> wrote: > >> ok, so if task is list and session.user.canSeeFullName = true use >> customComponent that shows full name and address >> >> >> task is list and session.user.canSeeFullName = false use customComponent >> that shows username only >> >> i have a SimpleListRepetition with an added woswitchcomponent wrapped in a >> conditional. the condition is: >> >> InstructionComponentCondition : WOConditional { >> condition = d2wContext.showHeaderInstructionComponent; >> } >> >> set that to true when session.user.seesHelpHeader is true. >> >> you could fly in custom components depending on the users security settings. >> >> I don't know if this is what you want. >> >> Ted >> >> >> >> >> >> >> >> >> --- On Wed, 2/27/13, David Avendasora <[email protected]> wrote: >> >>> From: David Avendasora <[email protected]> >>> Subject: Re: Programatically Setting/Filtering D2W displayPropertyKeys >>> To: "Theodore Petrosky" <[email protected]> >>> Cc: "WebObjects-Dev Mailing List List" <[email protected]> >>> Date: Wednesday, February 27, 2013, 8:50 AM >>> Hmmm… >>> >>> I'm not working at the Entity level, more the individual >>> properties of a given entity. Things that only certain roles >>> in the system should be able to see, like personally >>> identifying information about someone other than themselves. >>> A regular can see that a person exists and what their >>> "displayName" is, number of events attended, etc., but not >>> their full name, address or phone number. >>> >>> So when displaying a list of people, a user with the correct >>> rights sees their full names and phone numbers where a >>> different user navigates to the same page and gets a list of >>> only their displayNames. >>> >>> I'm trying to accomplish this without adding a bunch of >>> displayPropertykey rules. Currently the system is in the >>> initial rollout stages and there are going to be frequent >>> changes to property names and architecture as we work out >>> how people actually make use of the system, which makes D2W >>> a great tool, but also makes it a huge PITA. If you make a >>> change to the EOModel, you aren't notified of rule problems >>> until runtime, and that is a Very Bad Thing™ >>> >>> Dave >>> >>> On Feb 27, 2013, at 8:32 PM, Theodore Petrosky <[email protected]> >>> wrote: >>> >>>> i have done this two ways: >>>> >>>> 1. when filtering which entityNames to show I put a >>> condition in the NavigationMenu.plist: >>>> >>>> conditions = ("session.user.canSeeAgendas"); >>>> >>>> >>>> and b. I have keys and rules: >>>> >>>> 100 : (task = 'list' and session.user.showsHelpText = >>> 'true') => showHeaderInstructionComponent = "true" >>> [com.webobjects.directtoweb.BooleanAssignment] >>>> >>>> I gave up on the idea of 'admins' and users. instead I >>> tend to think that all users are administrators of their >>> domain. >>>> >>>> Ted >>>> >>>> >>>> >>>> --- On Wed, 2/27/13, David Avendasora <[email protected]> >>> wrote: >>>> >>>>> From: David Avendasora <[email protected]> >>>>> Subject: Programatically Setting/Filtering D2W >>> displayPropertyKeys >>>>> To: "WebObjects-Dev Mailing List List" <[email protected]> >>>>> Date: Wednesday, February 27, 2013, 12:10 AM >>>>> Hi all you D2W devs >>>>> out there! >>>>> >>>>> Your worst nightmare is here, and I'm using D2W for >>> a >>>>> app about to go into production! >>>>> >>>>> After it's initial roll-out, one of the next >>> features to >>>>> be rolled out is to vary the attributes and >>> relationships >>>>> displayed to users based on permissions that they >>> have. >>>>> >>>>> What I'd like to do is take the keys that are >>> defined by >>>>> displayPropertyKeys in the rule file and then >>> filter it >>>>> based on which ones they have permissions to. >>>>> >>>>> I have figured out a way to define and later recall >>> which >>>>> keys each users has permissions to view and/or >>> edit, now I >>>>> just need a mechanism to filter the rule-defined >>> keys based >>>>> on the currently-loggedin user's permissions. >>>>> >>>>> I've looked at a couple ways, but I'm not sure >>> what >>>>> is the best strategy. I'm thinking creating a >>> custom D2W >>>>> Assignment subclass is the way, but I'm not sure. >>>>> >>>>> Any suggestions? >>>>> >>>>> Thanks! >>>>> >>>>> Dave >>>>> >>>>> >>>>> >>>>> >>> —————————————————————————————WebObjects >>> - so >>>>> easy that even Dave Avendasora can do >>>>> >>> it!™—————————————————————————————David >>>>> AvendasoraSenior Software >>>>> AbuserKaiten, Inc. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -----Inline Attachment Follows----- >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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/tedpet5%40yahoo.com >>>>> >>>>> This email sent to [email protected] >>>>> >>>> >>>> >>> >>> >>> ————————————————————————————— >>> WebObjects - so easy that even Dave Avendasora can do >>> it!™ >>> ————————————————————————————— >>> David Avendasora >>> Senior Software Abuser >>> Kaiten, Inc. >>> >>> >>> >>> >>> >> >> > > > ————————————————————————————— > WebObjects - so easy that even Dave Avendasora can do it!™ > ————————————————————————————— > David Avendasora > Senior Software Abuser > Kaiten, Inc. > > > > > > _______________________________________________ > 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/lists.fabian%40e-lumo.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]
