Re: Programatically Setting/Filtering D2W displayPropertyKeys
Re: Programatically Setting/Filtering D2W displayPropertyKeys
- Subject: Re: Programatically Setting/Filtering D2W displayPropertyKeys
- From: David Avendasora <email@hidden>
- Date: Wed, 27 Feb 2013 22:23:11 +0800
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@hidden> 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@hidden> wrote:
>
>> From: David Avendasora <email@hidden>
>> Subject: Re: Programatically Setting/Filtering D2W displayPropertyKeys
>> To: "Theodore Petrosky" <email@hidden>
>> Cc: "WebObjects-Dev Mailing List List" <email@hidden>
>> 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@hidden>
>> 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@hidden>
>> wrote:
>>>
>>>> From: David Avendasora <email@hidden>
>>>> Subject: Programatically Setting/Filtering D2W
>> displayPropertyKeys
>>>> To: "WebObjects-Dev Mailing List List" <email@hidden>
>>>> 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@hidden)
>>>> Help/Unsubscribe/Update your Subscription:
>>>>
>>>> This email sent to email@hidden
>>>>
>>>
>>>
>>
>>
>> —————————————————————————————
>> 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@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden