General Discussion about roles and Security for Display of data.

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

General Discussion about roles and Security for Display of data.

BJ Freeman
There is a need to be able to block viewing info except that info that
may pertain to that login (partyID)
The is not taking into consideration Admin or Managers levels.

for instance you have employees who should not be able to see each
others profiles, payroll information, and/or time sheets, as a few examples.

another area, if an communication event is set to private, no one but
the party ID associated with the email address should be able to see them.



So this is a discussion about how to best implement this.
Reply | Threaded
Open this post in threaded view
|

Re: General Discussion about roles and Security for Display of data.

BJ Freeman
http://issues.apache.org/jira/browse/OFBIZ-118

BJ Freeman sent the following on 7/27/2006 11:49 AM:

> There is a need to be able to block viewing info except that info that
> may pertain to that login (partyID)
> The is not taking into consideration Admin or Managers levels.
>
> for instance you have employees who should not be able to see each
> others profiles, payroll information, and/or time sheets, as a few
> examples.
>
> another area, if an communication event is set to private, no one but
> the party ID associated with the email address should be able to see them.
>
>
>
> So this is a discussion about how to best implement this.
>
Reply | Threaded
Open this post in threaded view
|

Re: General Discussion about roles and Security for Display of data.

David E Jones-2
If it's meant to be a discussion the mailing list is probably the better place for it.

On the other hand, there are established patterns for this so perhaps the best first step is to do a bit of research. The is a fair bit of commentary in the mailing list archives and probably in the wiki too, and there is a lot of code that uses this sort of pattern in ecommerce so customers can see their own stuff but no one else can.

-David


BJ Freeman wrote:

> http://issues.apache.org/jira/browse/OFBIZ-118
>
> BJ Freeman sent the following on 7/27/2006 11:49 AM:
>> There is a need to be able to block viewing info except that info that
>> may pertain to that login (partyID)
>> The is not taking into consideration Admin or Managers levels.
>>
>> for instance you have employees who should not be able to see each
>> others profiles, payroll information, and/or time sheets, as a few
>> examples.
>>
>> another area, if an communication event is set to private, no one but
>> the party ID associated with the email address should be able to see
>> them.
>>
>>
>>
>> So this is a discussion about how to best implement this.
>>

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: General Discussion about roles and Security for Display of data.

BJ Freeman
Thanks David.
It was not so much developing new ways but extending it to other sections.

sorry I was not clear.


David E Jones sent the following on 7/27/2006 12:06 PM:

> If it's meant to be a discussion the mailing list is probably the better
> place for it.
>
> On the other hand, there are established patterns for this so perhaps
> the best first step is to do a bit of research. The is a fair bit of
> commentary in the mailing list archives and probably in the wiki too,
> and there is a lot of code that uses this sort of pattern in ecommerce
> so customers can see their own stuff but no one else can.
>
> -David
>
>
> BJ Freeman wrote:
>> http://issues.apache.org/jira/browse/OFBIZ-118
>>
>> BJ Freeman sent the following on 7/27/2006 11:49 AM:
>>> There is a need to be able to block viewing info except that info
>>> that may pertain to that login (partyID)
>>> The is not taking into consideration Admin or Managers levels.
>>>
>>> for instance you have employees who should not be able to see each
>>> others profiles, payroll information, and/or time sheets, as a few
>>> examples.
>>>
>>> another area, if an communication event is set to private, no one but
>>> the party ID associated with the email address should be able to see
>>> them.
>>>
>>>
>>>
>>> So this is a discussion about how to best implement this.
>>>
Reply | Threaded
Open this post in threaded view
|

Re: General Discussion about roles and Security for Display of data.

BJ Freeman
to be more clear, to implement this thru out ofbiz on screens that fit
this criteria.

BJ Freeman sent the following on 7/27/2006 1:33 PM:

> Thanks David.
> It was not so much developing new ways but extending it to other sections.
>
> sorry I was not clear.
>
>
> David E Jones sent the following on 7/27/2006 12:06 PM:
>> If it's meant to be a discussion the mailing list is probably the
>> better place for it.
>>
>> On the other hand, there are established patterns for this so perhaps
>> the best first step is to do a bit of research. The is a fair bit of
>> commentary in the mailing list archives and probably in the wiki too,
>> and there is a lot of code that uses this sort of pattern in ecommerce
>> so customers can see their own stuff but no one else can.
>>
>> -David
>>
>>
>> BJ Freeman wrote:
>>> http://issues.apache.org/jira/browse/OFBIZ-118
>>>
>>> BJ Freeman sent the following on 7/27/2006 11:49 AM:
>>>> There is a need to be able to block viewing info except that info
>>>> that may pertain to that login (partyID)
>>>> The is not taking into consideration Admin or Managers levels.
>>>>
>>>> for instance you have employees who should not be able to see each
>>>> others profiles, payroll information, and/or time sheets, as a few
>>>> examples.
>>>>
>>>> another area, if an communication event is set to private, no one
>>>> but the party ID associated with the email address should be able to
>>>> see them.
>>>>
>>>>
>>>>
>>>> So this is a discussion about how to best implement this.
>>>>
>
Reply | Threaded
Open this post in threaded view
|

Re: General Discussion about roles and Security for Display of data.

BJ Freeman
Lets take the profile as an example.
currently in ecommerces it is setup so only the login can view.
in Party it can be seen by anyone.
By making a change to it so if admin is viewing, then the admin can see
any profile.
Now companies have their own way of who has what permission or role.
and ofbiz allows the consultant to create these.
if say we think in in organization structure, and make groups that would
  fit different structures, then have a single group for the widget,
these other structures can be added by the organization.

This makes the profile widget only one, and have multi purpose.
this also would reduce code unmaintainence.


BJ Freeman sent the following on 7/27/2006 1:56 PM:

> to be more clear, to implement this thru out ofbiz on screens that fit
> this criteria.
>
> BJ Freeman sent the following on 7/27/2006 1:33 PM:
>> Thanks David.
>> It was not so much developing new ways but extending it to other
>> sections.
>>
>> sorry I was not clear.
>>
>>
>> David E Jones sent the following on 7/27/2006 12:06 PM:
>>> If it's meant to be a discussion the mailing list is probably the
>>> better place for it.
>>>
>>> On the other hand, there are established patterns for this so perhaps
>>> the best first step is to do a bit of research. The is a fair bit of
>>> commentary in the mailing list archives and probably in the wiki too,
>>> and there is a lot of code that uses this sort of pattern in
>>> ecommerce so customers can see their own stuff but no one else can.
>>>
>>> -David
>>>
>>>
>>> BJ Freeman wrote:
>>>> http://issues.apache.org/jira/browse/OFBIZ-118
>>>>
>>>> BJ Freeman sent the following on 7/27/2006 11:49 AM:
>>>>> There is a need to be able to block viewing info except that info
>>>>> that may pertain to that login (partyID)
>>>>> The is not taking into consideration Admin or Managers levels.
>>>>>
>>>>> for instance you have employees who should not be able to see each
>>>>> others profiles, payroll information, and/or time sheets, as a few
>>>>> examples.
>>>>>
>>>>> another area, if an communication event is set to private, no one
>>>>> but the party ID associated with the email address should be able
>>>>> to see them.
>>>>>
>>>>>
>>>>>
>>>>> So this is a discussion about how to best implement this.
>>>>>
>>
>