making form field visibility user driven

[Chris Snow-3]

I expect this has been discussed many times, but has anyone looked at
making the visibility of form fields based on the current user.

HtmlFormRenderer could be modified so that before it outputs a field, it
could check a configuration object so determine whether the field
(identified by its name, e.g
WorkEffortForms.xml#EditICalendarPartyAssign:statusId) should be
displayed for the current user.  A configuration screen in webtools
could then be created to declare what fields should be hidden for a
particular user.

This concept could be extended to look at PartyGroups and assigned
organisations so that users from Organisation A would see different
forms to those users from Organisation B.

Has this been discussed before?  Is there any merit in this suggestion?

Many thanks,

Chris

[Adrian Crum-2]

That capability is included in the proposed security redesign:

http://cwiki.apache.org/confluence/display/OFBTECH/OFBiz+Security+Redesign

and there is a working example of what you describe in the latest executioncontext branch.

-Adrian

--- On Sat, 1/9/10, Christopher Snow <[hidden email]> wrote:

> From: Christopher Snow <[hidden email]>
> Subject: making form field visibility user driven
> To: [hidden email]
> Date: Saturday, January 9, 2010, 9:33 AM
> I expect this has been discussed many
> times, but has anyone looked at
> making the visibility of form fields based on the current
> user.
>
> HtmlFormRenderer could be modified so that before it
> outputs a field, it
> could check a configuration object so determine whether the
> field
> (identified by its name, e.g
> WorkEffortForms.xml#EditICalendarPartyAssign:statusId)
> should be
> displayed for the current user.  A configuration
> screen in webtools
> could then be created to declare what fields should be
> hidden for a
> particular user.
>
> This concept could be extended to look at PartyGroups and
> assigned
> organisations so that users from Organisation A would see
> different
> forms to those users from Organisation B.
>
> Has this been discussed before?  Is there any merit in
> this suggestion?
>
> Many thanks,
>
> Chris
>

[Chris Snow-3]

Nice!  Is there a rough estimate of when the executioncontext branch
will be merged back into trunk?

Many thanks,

Chris

Adrian Crum wrote:

> That capability is included in the proposed security redesign:
>
> http://cwiki.apache.org/confluence/display/OFBTECH/OFBiz+Security+Redesign
>
> and there is a working example of what you describe in the latest executioncontext branch.
>
> -Adrian
>
> --- On Sat, 1/9/10, Christopher Snow <[hidden email]> wrote:
>
>  
>> From: Christopher Snow <[hidden email]>
>> Subject: making form field visibility user driven
>> To: [hidden email]
>> Date: Saturday, January 9, 2010, 9:33 AM
>> I expect this has been discussed many
>> times, but has anyone looked at
>> making the visibility of form fields based on the current
>> user.
>>
>> HtmlFormRenderer could be modified so that before it
>> outputs a field, it
>> could check a configuration object so determine whether the
>> field
>> (identified by its name, e.g
>> WorkEffortForms.xml#EditICalendarPartyAssign:statusId)
>> should be
>> displayed for the current user.  A configuration
>> screen in webtools
>> could then be created to declare what fields should be
>> hidden for a
>> particular user.
>>
>> This concept could be extended to look at PartyGroups and
>> assigned
>> organisations so that users from Organisation A would see
>> different
>> forms to those users from Organisation B.
>>
>> Has this been discussed before?  Is there any merit in
>> this suggestion?
>>
>> Many thanks,
>>
>> Chris
>>
>>    
>
>
>      
>  

--
Chris Snow - CEng MBCS CITP MBA (Tech Mgmt) (Open) CISSP

Tel: [phone]
Mob: [phone]
Www: www.snowconsulting.co.uk

[Adrian Crum-2]

No estimate. David Jones and I seem to be the only ones actively involved right now, and our availability is limited. We need others to get involved.

I will be making a big commit to the branch today. I'm adding security auditing and making a few changes to the authorization manager API.

-Adrian

--- On Sat, 1/9/10, Christopher Snow <[hidden email]> wrote:

> From: Christopher Snow <[hidden email]>
> Subject: Re: making form field visibility user driven
> To: [hidden email]
> Date: Saturday, January 9, 2010, 11:37 AM
> Nice!  Is there a rough estimate
> of when the executioncontext branch
> will be merged back into trunk?
>
> Many thanks,
>
> Chris
>
> Adrian Crum wrote:
> > That capability is included in the proposed security
> redesign:
> >
> > http://cwiki.apache.org/confluence/display/OFBTECH/OFBiz+Security+Redesign
> >
> > and there is a working example of what you describe in
> the latest executioncontext branch.
> >
> > -Adrian
> >
> > --- On Sat, 1/9/10, Christopher Snow <[hidden email]>
> wrote:
> >
> >   
> >> From: Christopher Snow <[hidden email]>
> >> Subject: making form field visibility user driven
> >> To: [hidden email]
> >> Date: Saturday, January 9, 2010, 9:33 AM
> >> I expect this has been discussed many
> >> times, but has anyone looked at
> >> making the visibility of form fields based on the
> current
> >> user.
> >>
> >> HtmlFormRenderer could be modified so that before
> it
> >> outputs a field, it
> >> could check a configuration object so determine
> whether the
> >> field
> >> (identified by its name, e.g
> >>
> WorkEffortForms.xml#EditICalendarPartyAssign:statusId)
> >> should be
> >> displayed for the current user.  A
> configuration
> >> screen in webtools
> >> could then be created to declare what fields
> should be
> >> hidden for a
> >> particular user.
> >>
> >> This concept could be extended to look at
> PartyGroups and
> >> assigned
> >> organisations so that users from Organisation A
> would see
> >> different
> >> forms to those users from Organisation B.
> >>
> >> Has this been discussed before?  Is there any
> merit in
> >> this suggestion?
> >>
> >> Many thanks,
> >>
> >> Chris
> >>
> >>     
> >
> >
> >       
> >   
>
>
> --
> Chris Snow - CEng MBCS CITP MBA (Tech Mgmt) (Open) CISSP
>
> Tel: [phone]
> Mob: [phone]
> Www: www.snowconsulting.co.uk
>
>

[David E. Jones-2]

Adrian,

I'm planning to review this in the near future, possibly early next week but more likely later in the week. Fortunately there is market interest for this, and in my case I have a client that is considering using these changes for security, and building one form of multi-tenancy based on the execution context.

-David


On Jan 9, 2010, at 1:51 PM, Adrian Crum wrote:

> No estimate. David Jones and I seem to be the only ones actively involved right now, and our availability is limited. We need others to get involved.
>
> I will be making a big commit to the branch today. I'm adding security auditing and making a few changes to the authorization manager API.
>
> -Adrian
>
> --- On Sat, 1/9/10, Christopher Snow <[hidden email]> wrote:
>
>> From: Christopher Snow <[hidden email]>
>> Subject: Re: making form field visibility user driven
>> To: [hidden email]
>> Date: Saturday, January 9, 2010, 11:37 AM
>> Nice!  Is there a rough estimate
>> of when the executioncontext branch
>> will be merged back into trunk?
>>
>> Many thanks,
>>
>> Chris
>>
>> Adrian Crum wrote:
>>> That capability is included in the proposed security
>> redesign:
>>>
>>> http://cwiki.apache.org/confluence/display/OFBTECH/OFBiz+Security+Redesign
>>>
>>> and there is a working example of what you describe in
>> the latest executioncontext branch.
>>>
>>> -Adrian
>>>
>>> --- On Sat, 1/9/10, Christopher Snow <[hidden email]>
>> wrote:
>>>
>>>    
>>>> From: Christopher Snow <[hidden email]>
>>>> Subject: making form field visibility user driven
>>>> To: [hidden email]
>>>> Date: Saturday, January 9, 2010, 9:33 AM
>>>> I expect this has been discussed many
>>>> times, but has anyone looked at
>>>> making the visibility of form fields based on the
>> current
>>>> user.
>>>>
>>>> HtmlFormRenderer could be modified so that before
>> it
>>>> outputs a field, it
>>>> could check a configuration object so determine
>> whether the
>>>> field
>>>> (identified by its name, e.g
>>>>
>> WorkEffortForms.xml#EditICalendarPartyAssign:statusId)
>>>> should be
>>>> displayed for the current user.  A
>> configuration
>>>> screen in webtools
>>>> could then be created to declare what fields
>> should be
>>>> hidden for a
>>>> particular user.
>>>>
>>>> This concept could be extended to look at
>> PartyGroups and
>>>> assigned
>>>> organisations so that users from Organisation A
>> would see
>>>> different
>>>> forms to those users from Organisation B.
>>>>
>>>> Has this been discussed before?  Is there any
>> merit in
>>>> this suggestion?
>>>>
>>>> Many thanks,
>>>>
>>>> Chris
>>>>
>>>>      
>>>
>>>
>>>        
>>>    
>>
>>
>> --
>> Chris Snow - CEng MBCS CITP MBA (Tech Mgmt) (Open) CISSP
>>
>> Tel: [phone]
>> Mob: [phone]
>> Www: www.snowconsulting.co.uk
>>
>>
>
>
>

[Chris Snow-3]

David,

With these changes, will multi-tenancy become a standard ofbiz
configuration option?

Many thanks,

Chris

David E Jones wrote:
> Adrian,
>
> I'm planning to review this in the near future, possibly early next week but more likely later in the week. Fortunately there is market interest for this, and in my case I have a client that is considering using these changes for security, and building one form of multi-tenancy based on the execution context.
>
> -David
>
>
> On Jan 9, 2010, at 1:51 PM, Adrian Crum wrote:
>  

[David E. Jones-2]

Will it? I don't know, there's always hope though!

Another thing to keep in mind: there are many different flavours of multi-tenancy, so there's a chance it still won't match your particular requirements. Of course, once the execution context stuff is in place that will make it far easier to adapt it to whatever requirements you might have.

-David


On Jan 9, 2010, at 9:51 PM, Christopher Snow wrote:

> David,
>
> With these changes, will multi-tenancy become a standard ofbiz
> configuration option?
>
> Many thanks,
>
> Chris
>
> David E Jones wrote:
>> Adrian,
>>
>> I'm planning to review this in the near future, possibly early next week but more likely later in the week. Fortunately there is market interest for this, and in my case I have a client that is considering using these changes for security, and building one form of multi-tenancy based on the execution context.
>>
>> -David
>>
>>
>> On Jan 9, 2010, at 1:51 PM, Adrian Crum wrote:
>>
>