To expand on that a bit, which fields are editable for each permission level is
defined in the code of a superclass for each area, so not quite that flexible,
but good enough for what we are doing.
> On Aug 13, 2017, at 6:11 PM, Morris, Mark <mark.mor...@experian.com> wrote:
>
> No, it’s really just something bolted on top of a permission system on a
> suite of applications that have been in continuous development for almost 20
> years. In other words, not an ideal architecture at this point, but I think
> impressive that it’s holding its own!
>
>> On Aug 13, 2017, at 6:02 PM, Paul Yu <p...@mac.com> wrote:
>>
>> Is this an ABAC implementation?
>>
>> Paul
>>
>> Sent from my iPhone
>> Please excuse iOS autocomplete
>>
>>> On Aug 13, 2017, at 5:08 PM, Morris, Mark <mark.mor...@experian.com> wrote:
>>>
>>> This is a topic that was discussed back in 2011, but my searches haven’t
>>> turned up a satisfactory solution.
>>>
>>> Some quick background info, we have information-dense, complex pages, and
>>> there are a variety of permission levels for internal and external users
>>> that needed to be implemented at field-level granularity.
>>>
>>> My approach was to create a method for determining edit-ability in the
>>> superclass for each area’s components that maps permission level with field
>>> name:
>>>
>>> public boolean editingEnabledByField( String field )
>>>
>>> … which I’m calling using WOOgnl in WOConditionals as the condition and in
>>> custom components like this:
>>>
>>> <wo:OurCustomComponent
>>> editingEnabled="~editingEnabledByField(\”thisFieldName\")" expanded="$true"
>>> />
>>>
>>> This actually works fine as far as the functionality goes. The issue is our
>>> logs get filled with warnings that look like error messages, one for every
>>> field for every page hit. Since the bindings on these pages are
>>> synchronized, the log messages apparently occur when the value of
>>> “editingEnabled” tries to get pushed into
>>> “editingEnabledByField(”thisFieldName”)”, which obviously isn’t possible.
>>> (So getting the value from the ognl expression works fine, setting to the
>>> ognl expression does not.)
>>>
>>> In 2011 Mike Schrag wrote about almost this exact same question:
>>>
>>>> this seems wrong to me ... it's not the ognl is intrinsically unsettable
>>>> it's that you're trying to set a value on an ognl expression that
>>>> definitely ISN'T settable. either you should turn off automatic binding
>>>> synchronization on SelectByCharacterPopupEditField and manually sync, or
>>>> this patch should maybe be smarter about how it determines "setability" in
>>>> ognl. i would be afraid of breaking anyone who might be taking advantage
>>>> of settable ognl expressions. i don't, offhand, know how to perform that
>>>> check -- whether ognl has API to do it or if it's even possible.
>>>
>>> The patch he was referring to was:
>>>
>>> public WOOgnlAssociation(String s) {
>>> super(s);
>>> _isValueSettable = false;
>>> }
>>>
>>> … which is a sledgehammer approach that probably wouldn’t be applicable in
>>> general. However, picking up from where Stefan left off there, perhaps this
>>> is at least a partial solution (that I think will work for my case anyway):
>>>
>>> public WOOgnlAssociation(String s) {
>>> super(s);
>>> if( s != null && s.matches( ".+\\(.*\\S.*\\)" ) ) {
>>> _isValueSettable = false;
>>> }
>>> }
>>>
>>> This regex checks to see if there’s a method call with some sort of
>>> parameter (by looking for something followed by “(“ followed by some
>>> non-whitespace followed by “)”).
>>>
>>> Does this seem reasonable? Any counterexamples where a matching key path
>>> should be settable? I know that ognl expressions can include parentheses as
>>> well, but I would think those also would not be settable, right?
>>>
>>> Thanks for any tips or advice!
>>>
>>> Regards,
>>> Mark
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
>>> Help/Unsubscribe/Update your Subscription:
>>> https://lists.apple.com/mailman/options/webobjects-dev/pyu%40mac.com
>>>
>>> This email sent to p...@mac.com
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/webobjects-dev/mark.morris%40experian.com
>
> This email sent to mark.mor...@experian.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
