Proposal to setup a new SecurityGroup for Accounting component.

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

Proposal to setup a new SecurityGroup for Accounting component.

Sumit Pandit-3
Hello Devs,

I would like to propose setup of a new  SecurityGroup which is  
dedicated to OFBiz Accounting component only. It will assigned by all  
SecurityPermission which are required to handle variuos accounting  
operations. Purpose of this will be to be able to create a UserLogin,  
who will have restricted access to Accounting component only.

It will reflect to changes in following entities  -
create a new SecurityGroup and assign all associated  
SecurityPermission to it.
Create a new UserLogin and assign SecurityGroup to him.
Additional suggestion - Create a new PartyRole - "ACCOUNTANT",  child  
of Role - "EMPLOYEE".

Thoughts?

Thanks And Regards
Sumit Pandit
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to setup a new SecurityGroup for Accounting component.

Anil Patel-3
Sumit,
Looks like good thing to do. Having this profile handy will give us  
opportunity to break out of habit of using admin/ofbiz user account  
for testing application.
If you have time it will be good to create a Jira issue for it and  
contribute patch.

Regards
Anil Patel

On Jun 13, 2009, at 9:45 AM, Sumit Pandit wrote:

> Hello Devs,
>
> I would like to propose setup of a new  SecurityGroup which is  
> dedicated to OFBiz Accounting component only. It will assigned by  
> all SecurityPermission which are required to handle variuos  
> accounting operations. Purpose of this will be to be able to create  
> a UserLogin, who will have restricted access to Accounting component  
> only.
>
> It will reflect to changes in following entities  -
> create a new SecurityGroup and assign all associated  
> SecurityPermission to it.
> Create a new UserLogin and assign SecurityGroup to him.
> Additional suggestion - Create a new PartyRole - "ACCOUNTANT",  
> child of Role - "EMPLOYEE".
>
> Thoughts?
>
> Thanks And Regards
> Sumit Pandit

Reply | Threaded
Open this post in threaded view
|

Re: Proposal to setup a new SecurityGroup for Accounting component.

Sumit Pandit-3
Anil,

Thank you for your response.
Created a jira issue - https://issues.apache.org/jira/browse/ 
OFBIZ-2606 and patch is uploaded with testing steps.

Thanks And Regards
Sumit Pandit

On Jun 15, 2009, at 9:57 AM, Anil Patel wrote:

> Sumit,
> Looks like good thing to do. Having this profile handy will give us  
> opportunity to break out of habit of using admin/ofbiz user account  
> for testing application.
> If you have time it will be good to create a Jira issue for it and  
> contribute patch.
>
> Regards
> Anil Patel
>
> On Jun 13, 2009, at 9:45 AM, Sumit Pandit wrote:
>
>> Hello Devs,
>>
>> I would like to propose setup of a new  SecurityGroup which is  
>> dedicated to OFBiz Accounting component only. It will assigned by  
>> all SecurityPermission which are required to handle variuos  
>> accounting operations. Purpose of this will be to be able to create  
>> a UserLogin, who will have restricted access to Accounting  
>> component only.
>>
>> It will reflect to changes in following entities  -
>> create a new SecurityGroup and assign all associated  
>> SecurityPermission to it.
>> Create a new UserLogin and assign SecurityGroup to him.
>> Additional suggestion - Create a new PartyRole - "ACCOUNTANT",  
>> child of Role - "EMPLOYEE".
>>
>> Thoughts?
>>
>> Thanks And Regards
>> Sumit Pandit
>

Reply | Threaded
Open this post in threaded view
|

Re: Proposal to setup a new SecurityGroup for Accounting component.

Mridul Pathak-2
I think we should have application specific security group not only  
for Accounting but for all other applications.  And demo data for  
parties each having an application specific permissions will also be a  
good thing to have.

--
Thanks,
Mridul Pathak
HotWax Media Pvt. Ltd.
http://www.hotwaxmedia.com


On 15-Jun-09, at 12:26 PM, Sumit Pandit wrote:

> Anil,
>
> Thank you for your response.
> Created a jira issue - https://issues.apache.org/jira/browse/OFBIZ-2606 
>  and patch is uploaded with testing steps.
>
> Thanks And Regards
> Sumit Pandit
>
> On Jun 15, 2009, at 9:57 AM, Anil Patel wrote:
>
>> Sumit,
>> Looks like good thing to do. Having this profile handy will give us  
>> opportunity to break out of habit of using admin/ofbiz user account  
>> for testing application.
>> If you have time it will be good to create a Jira issue for it and  
>> contribute patch.
>>
>> Regards
>> Anil Patel
>>
>> On Jun 13, 2009, at 9:45 AM, Sumit Pandit wrote:
>>
>>> Hello Devs,
>>>
>>> I would like to propose setup of a new  SecurityGroup which is  
>>> dedicated to OFBiz Accounting component only. It will assigned by  
>>> all SecurityPermission which are required to handle variuos  
>>> accounting operations. Purpose of this will be to be able to  
>>> create a UserLogin, who will have restricted access to Accounting  
>>> component only.
>>>
>>> It will reflect to changes in following entities  -
>>> create a new SecurityGroup and assign all associated  
>>> SecurityPermission to it.
>>> Create a new UserLogin and assign SecurityGroup to him.
>>> Additional suggestion - Create a new PartyRole - "ACCOUNTANT",  
>>> child of Role - "EMPLOYEE".
>>>
>>> Thoughts?
>>>
>>> Thanks And Regards
>>> Sumit Pandit
>>
>


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

Re: Proposal to setup a new SecurityGroup for Accounting component.

David E. Jones-2

That's an interesting idea... what are you thinking about _why_ would  
we want that?

-David


On Jun 15, 2009, at 2:00 AM, Mridul Pathak wrote:

> I think we should have application specific security group not only  
> for Accounting but for all other applications.  And demo data for  
> parties each having an application specific permissions will also be  
> a good thing to have.
>
> --
> Thanks,
> Mridul Pathak
> HotWax Media Pvt. Ltd.
> http://www.hotwaxmedia.com
>
>
> On 15-Jun-09, at 12:26 PM, Sumit Pandit wrote:
>
>> Anil,
>>
>> Thank you for your response.
>> Created a jira issue - https://issues.apache.org/jira/browse/OFBIZ-2606 
>>  and patch is uploaded with testing steps.
>>
>> Thanks And Regards
>> Sumit Pandit
>>
>> On Jun 15, 2009, at 9:57 AM, Anil Patel wrote:
>>
>>> Sumit,
>>> Looks like good thing to do. Having this profile handy will give  
>>> us opportunity to break out of habit of using admin/ofbiz user  
>>> account for testing application.
>>> If you have time it will be good to create a Jira issue for it and  
>>> contribute patch.
>>>
>>> Regards
>>> Anil Patel
>>>
>>> On Jun 13, 2009, at 9:45 AM, Sumit Pandit wrote:
>>>
>>>> Hello Devs,
>>>>
>>>> I would like to propose setup of a new  SecurityGroup which is  
>>>> dedicated to OFBiz Accounting component only. It will assigned by  
>>>> all SecurityPermission which are required to handle variuos  
>>>> accounting operations. Purpose of this will be to be able to  
>>>> create a UserLogin, who will have restricted access to Accounting  
>>>> component only.
>>>>
>>>> It will reflect to changes in following entities  -
>>>> create a new SecurityGroup and assign all associated  
>>>> SecurityPermission to it.
>>>> Create a new UserLogin and assign SecurityGroup to him.
>>>> Additional suggestion - Create a new PartyRole - "ACCOUNTANT",  
>>>> child of Role - "EMPLOYEE".
>>>>
>>>> Thoughts?
>>>>
>>>> Thanks And Regards
>>>> Sumit Pandit
>>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Proposal to setup a new SecurityGroup for Accounting component.

Mridul Pathak-2
Hi David,

     We have documentation on OFBiz wiki where various Actors and  
their roles have been defined.  These are the Actors which are meant  
to use OFBiz backend applications.  Each Actor has some specific role,  
and he executes a certain business process.  For example, a buyer  
places purchase order, or a packer packs inventory into boxes for  
shipping.  There are many such actors which have been defined, and in  
many cases the business process associated with them is also defined.  
They are standard to every organization, though some of them may vary  
slightly from organization to organization.

     What I am actually thinking here is that we should be able to  
apply security on "Actor/Business Process" combination.  Like for a  
buyer, we can have a specific security group, which allows only  
purchase order placement and nothing else.  Or for packer, only those  
security permissions should be assigned which just allows him to pack  
inventory into boxes for shipping, that is to complete his business  
process, and he shouldn't be able to control other parts of the  
facility application.

     These security groups may exist as seed data and can be used by  
any organization OOTB.  Or, if it is not a good idea to keep them as  
seed data, they can still exist as demo data.  Also, this effort can  
help us evaluating OFBiz Security Model, that how far on the business  
process level we can apply the security, and then we can go for  
improvements if found any.

      If what I am proposing here makes sense, we can think about my  
last proposal as an initial start toward this effort.  We can start  
with defining application specific security groups.  So that if  
someone has permissions only for a Order Manager application, he won't  
be able to control other applications.

--
Thanks,
Mridul Pathak

On 15-Jun-09, at 1:36 PM, David E Jones wrote:

>
> That's an interesting idea... what are you thinking about _why_  
> would we want that?
>
> -David
>
>
> On Jun 15, 2009, at 2:00 AM, Mridul Pathak wrote:
>
>> I think we should have application specific security group not only  
>> for Accounting but for all other applications.  And demo data for  
>> parties each having an application specific permissions will also  
>> be a good thing to have.
>>
>> --
>> Thanks,
>> Mridul Pathak
>> HotWax Media Pvt. Ltd.
>> http://www.hotwaxmedia.com
>>
>>
>> On 15-Jun-09, at 12:26 PM, Sumit Pandit wrote:
>>
>>> Anil,
>>>
>>> Thank you for your response.
>>> Created a jira issue - https://issues.apache.org/jira/browse/OFBIZ-2606 
>>>  and patch is uploaded with testing steps.
>>>
>>> Thanks And Regards
>>> Sumit Pandit
>>>
>>> On Jun 15, 2009, at 9:57 AM, Anil Patel wrote:
>>>
>>>> Sumit,
>>>> Looks like good thing to do. Having this profile handy will give  
>>>> us opportunity to break out of habit of using admin/ofbiz user  
>>>> account for testing application.
>>>> If you have time it will be good to create a Jira issue for it  
>>>> and contribute patch.
>>>>
>>>> Regards
>>>> Anil Patel
>>>>
>>>> On Jun 13, 2009, at 9:45 AM, Sumit Pandit wrote:
>>>>
>>>>> Hello Devs,
>>>>>
>>>>> I would like to propose setup of a new  SecurityGroup which is  
>>>>> dedicated to OFBiz Accounting component only. It will assigned  
>>>>> by all SecurityPermission which are required to handle variuos  
>>>>> accounting operations. Purpose of this will be to be able to  
>>>>> create a UserLogin, who will have restricted access to  
>>>>> Accounting component only.
>>>>>
>>>>> It will reflect to changes in following entities  -
>>>>> create a new SecurityGroup and assign all associated  
>>>>> SecurityPermission to it.
>>>>> Create a new UserLogin and assign SecurityGroup to him.
>>>>> Additional suggestion - Create a new PartyRole - "ACCOUNTANT",  
>>>>> child of Role - "EMPLOYEE".
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> Thanks And Regards
>>>>> Sumit Pandit
>>>>
>>>
>>
>


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

Re: Proposal to setup a new SecurityGroup for Accounting component.

Jacopo Cappellato-4
+1

On Jun 15, 2009, at 11:29 AM, Mridul Pathak wrote:

> Hi David,
>
>    We have documentation on OFBiz wiki where various Actors and  
> their roles have been defined.  These are the Actors which are meant  
> to use OFBiz backend applications.  Each Actor has some specific  
> role, and he executes a certain business process.  For example, a  
> buyer places purchase order, or a packer packs inventory into boxes  
> for shipping.  There are many such actors which have been defined,  
> and in many cases the business process associated with them is also  
> defined.  They are standard to every organization, though some of  
> them may vary slightly from organization to organization.
>
>    What I am actually thinking here is that we should be able to  
> apply security on "Actor/Business Process" combination.  Like for a  
> buyer, we can have a specific security group, which allows only  
> purchase order placement and nothing else.  Or for packer, only  
> those security permissions should be assigned which just allows him  
> to pack inventory into boxes for shipping, that is to complete his  
> business process, and he shouldn't be able to control other parts of  
> the facility application.
>
>    These security groups may exist as seed data and can be used by  
> any organization OOTB.  Or, if it is not a good idea to keep them as  
> seed data, they can still exist as demo data.  Also, this effort can  
> help us evaluating OFBiz Security Model, that how far on the  
> business process level we can apply the security, and then we can go  
> for improvements if found any.
>
>     If what I am proposing here makes sense, we can think about my  
> last proposal as an initial start toward this effort.  We can start  
> with defining application specific security groups.  So that if  
> someone has permissions only for a Order Manager application, he  
> won't be able to control other applications.
>
> --
> Thanks,
> Mridul Pathak
>
> On 15-Jun-09, at 1:36 PM, David E Jones wrote:
>
>>
>> That's an interesting idea... what are you thinking about _why_  
>> would we want that?
>>
>> -David
>>
>>
>> On Jun 15, 2009, at 2:00 AM, Mridul Pathak wrote:
>>
>>> I think we should have application specific security group not  
>>> only for Accounting but for all other applications.  And demo data  
>>> for parties each having an application specific permissions will  
>>> also be a good thing to have.
>>>
>>> --
>>> Thanks,
>>> Mridul Pathak
>>> HotWax Media Pvt. Ltd.
>>> http://www.hotwaxmedia.com
>>>
>>>
>>> On 15-Jun-09, at 12:26 PM, Sumit Pandit wrote:
>>>
>>>> Anil,
>>>>
>>>> Thank you for your response.
>>>> Created a jira issue - https://issues.apache.org/jira/browse/OFBIZ-2606 
>>>>  and patch is uploaded with testing steps.
>>>>
>>>> Thanks And Regards
>>>> Sumit Pandit
>>>>
>>>> On Jun 15, 2009, at 9:57 AM, Anil Patel wrote:
>>>>
>>>>> Sumit,
>>>>> Looks like good thing to do. Having this profile handy will give  
>>>>> us opportunity to break out of habit of using admin/ofbiz user  
>>>>> account for testing application.
>>>>> If you have time it will be good to create a Jira issue for it  
>>>>> and contribute patch.
>>>>>
>>>>> Regards
>>>>> Anil Patel
>>>>>
>>>>> On Jun 13, 2009, at 9:45 AM, Sumit Pandit wrote:
>>>>>
>>>>>> Hello Devs,
>>>>>>
>>>>>> I would like to propose setup of a new  SecurityGroup which is  
>>>>>> dedicated to OFBiz Accounting component only. It will assigned  
>>>>>> by all SecurityPermission which are required to handle variuos  
>>>>>> accounting operations. Purpose of this will be to be able to  
>>>>>> create a UserLogin, who will have restricted access to  
>>>>>> Accounting component only.
>>>>>>
>>>>>> It will reflect to changes in following entities  -
>>>>>> create a new SecurityGroup and assign all associated  
>>>>>> SecurityPermission to it.
>>>>>> Create a new UserLogin and assign SecurityGroup to him.
>>>>>> Additional suggestion - Create a new PartyRole - "ACCOUNTANT",  
>>>>>> child of Role - "EMPLOYEE".
>>>>>>
>>>>>> Thoughts?
>>>>>>
>>>>>> Thanks And Regards
>>>>>> Sumit Pandit
>>>>>
>>>>
>>>
>>
>


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

Re: Proposal to setup a new SecurityGroup for Accounting component.

David E. Jones-2
In reply to this post by Mridul Pathak-2

On Jun 15, 2009, at 3:29 AM, Mridul Pathak wrote:

> Hi David,
>
>    We have documentation on OFBiz wiki where various Actors and  
> their roles have been defined.  These are the Actors which are meant  
> to use OFBiz backend applications.  Each Actor has some specific  
> role, and he executes a certain business process.  For example, a  
> buyer places purchase order, or a packer packs inventory into boxes  
> for shipping.  There are many such actors which have been defined,  
> and in many cases the business process associated with them is also  
> defined.  They are standard to every organization, though some of  
> them may vary slightly from organization to organization.
>
>    What I am actually thinking here is that we should be able to  
> apply security on "Actor/Business Process" combination.  Like for a  
> buyer, we can have a specific security group, which allows only  
> purchase order placement and nothing else.  Or for packer, only  
> those security permissions should be assigned which just allows him  
> to pack inventory into boxes for shipping, that is to complete his  
> business process, and he shouldn't be able to control other parts of  
> the facility application.
>
>    These security groups may exist as seed data and can be used by  
> any organization OOTB.  Or, if it is not a good idea to keep them as  
> seed data, they can still exist as demo data.  Also, this effort can  
> help us evaluating OFBiz Security Model, that how far on the  
> business process level we can apply the security, and then we can go  
> for improvements if found any.

Thank you. This is good, in fact it's very good and I think it is  
consistent with what we want to do in OFBiz.

>     If what I am proposing here makes sense, we can think about my  
> last proposal as an initial start toward this effort.  We can start  
> with defining application specific security groups.  So that if  
> someone has permissions only for a Order Manager application, he  
> won't be able to control other applications.

Isn't this the exact opposite of what you described above?

The reason I say that is that the base applications are organized  
according to general business concepts that make up the way the data  
is organized, and they have little to do with processes. In fact,  
because the base application are organized this way  most business  
processes will actually need to go across the various base applications.

The existing security groups are probably close to the definitions of  
actors than a security group for each application would be. Because of  
that I think that doing so would actually be a step backwards, both in  
theory and in practicality.

-David


> On 15-Jun-09, at 1:36 PM, David E Jones wrote:
>
>>
>> That's an interesting idea... what are you thinking about _why_  
>> would we want that?
>>
>> -David
>>
>>
>> On Jun 15, 2009, at 2:00 AM, Mridul Pathak wrote:
>>
>>> I think we should have application specific security group not  
>>> only for Accounting but for all other applications.  And demo data  
>>> for parties each having an application specific permissions will  
>>> also be a good thing to have.
>>>
>>> --
>>> Thanks,
>>> Mridul Pathak
>>> HotWax Media Pvt. Ltd.
>>> http://www.hotwaxmedia.com
>>>
>>>
>>> On 15-Jun-09, at 12:26 PM, Sumit Pandit wrote:
>>>
>>>> Anil,
>>>>
>>>> Thank you for your response.
>>>> Created a jira issue - https://issues.apache.org/jira/browse/OFBIZ-2606 
>>>>  and patch is uploaded with testing steps.
>>>>
>>>> Thanks And Regards
>>>> Sumit Pandit
>>>>
>>>> On Jun 15, 2009, at 9:57 AM, Anil Patel wrote:
>>>>
>>>>> Sumit,
>>>>> Looks like good thing to do. Having this profile handy will give  
>>>>> us opportunity to break out of habit of using admin/ofbiz user  
>>>>> account for testing application.
>>>>> If you have time it will be good to create a Jira issue for it  
>>>>> and contribute patch.
>>>>>
>>>>> Regards
>>>>> Anil Patel
>>>>>
>>>>> On Jun 13, 2009, at 9:45 AM, Sumit Pandit wrote:
>>>>>
>>>>>> Hello Devs,
>>>>>>
>>>>>> I would like to propose setup of a new  SecurityGroup which is  
>>>>>> dedicated to OFBiz Accounting component only. It will assigned  
>>>>>> by all SecurityPermission which are required to handle variuos  
>>>>>> accounting operations. Purpose of this will be to be able to  
>>>>>> create a UserLogin, who will have restricted access to  
>>>>>> Accounting component only.
>>>>>>
>>>>>> It will reflect to changes in following entities  -
>>>>>> create a new SecurityGroup and assign all associated  
>>>>>> SecurityPermission to it.
>>>>>> Create a new UserLogin and assign SecurityGroup to him.
>>>>>> Additional suggestion - Create a new PartyRole - "ACCOUNTANT",  
>>>>>> child of Role - "EMPLOYEE".
>>>>>>
>>>>>> Thoughts?
>>>>>>
>>>>>> Thanks And Regards
>>>>>> Sumit Pandit
>>>>>
>>>>
>>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Proposal to setup a new SecurityGroup for Accounting component.

Mridul Pathak-2

On 15-Jun-09, at 3:20 PM, David E Jones wrote:

>
> On Jun 15, 2009, at 3:29 AM, Mridul Pathak wrote:
>
>> Hi David,
>>
>>   We have documentation on OFBiz wiki where various Actors and  
>> their roles have been defined.  These are the Actors which are  
>> meant to use OFBiz backend applications.  Each Actor has some  
>> specific role, and he executes a certain business process.  For  
>> example, a buyer places purchase order, or a packer packs inventory  
>> into boxes for shipping.  There are many such actors which have  
>> been defined, and in many cases the business process associated  
>> with them is also defined.  They are standard to every  
>> organization, though some of them may vary slightly from  
>> organization to organization.
>>
>>   What I am actually thinking here is that we should be able to  
>> apply security on "Actor/Business Process" combination.  Like for a  
>> buyer, we can have a specific security group, which allows only  
>> purchase order placement and nothing else.  Or for packer, only  
>> those security permissions should be assigned which just allows him  
>> to pack inventory into boxes for shipping, that is to complete his  
>> business process, and he shouldn't be able to control other parts  
>> of the facility application.
>>
>>   These security groups may exist as seed data and can be used by  
>> any organization OOTB.  Or, if it is not a good idea to keep them  
>> as seed data, they can still exist as demo data.  Also, this effort  
>> can help us evaluating OFBiz Security Model, that how far on the  
>> business process level we can apply the security, and then we can  
>> go for improvements if found any.
>
> Thank you. This is good, in fact it's very good and I think it is  
> consistent with what we want to do in OFBiz.
>
>>    If what I am proposing here makes sense, we can think about my  
>> last proposal as an initial start toward this effort.  We can start  
>> with defining application specific security groups.  So that if  
>> someone has permissions only for a Order Manager application, he  
>> won't be able to control other applications.
>
> Isn't this the exact opposite of what you described above?
>
> The reason I say that is that the base applications are organized  
> according to general business concepts that make up the way the data  
> is organized, and they have little to do with processes. In fact,  
> because the base application are organized this way  most business  
> processes will actually need to go across the various base  
> applications.
>
> The existing security groups are probably close to the definitions  
> of actors than a security group for each application would be.  
> Because of that I think that doing so would actually be a step  
> backwards, both in theory and in practicality.
     I agree with you.   The reason for this proposal was that  
sometimes organization may not want to use the complete backend  
functionality and are mostly concerned with their Ecommerce  
application, and also may not want to be very specific about Actor's  
and their roles.  They may just want to have some administrators who  
will work on a set of backend applications, for example just Order  
Manager and Party Manager.  Currently, FULLADMIN gives permission for  
all the applications.  So idea here was to have granular application  
specific security groups, just in case if we want to assign someone  
complete permissions for only a set of applications.
     Though, with the way OFBiz applications are interrelated, I am  
not sure if this would work or not.

--
Mridul Pathak

>
> -David
>
>
>> On 15-Jun-09, at 1:36 PM, David E Jones wrote:
>>
>>>
>>> That's an interesting idea... what are you thinking about _why_  
>>> would we want that?
>>>
>>> -David
>>>
>>>
>>> On Jun 15, 2009, at 2:00 AM, Mridul Pathak wrote:
>>>
>>>> I think we should have application specific security group not  
>>>> only for Accounting but for all other applications.  And demo  
>>>> data for parties each having an application specific permissions  
>>>> will also be a good thing to have.
>>>>
>>>> --
>>>> Thanks,
>>>> Mridul Pathak
>>>> HotWax Media Pvt. Ltd.
>>>> http://www.hotwaxmedia.com
>>>>
>>>>
>>>> On 15-Jun-09, at 12:26 PM, Sumit Pandit wrote:
>>>>
>>>>> Anil,
>>>>>
>>>>> Thank you for your response.
>>>>> Created a jira issue - https://issues.apache.org/jira/browse/OFBIZ-2606 
>>>>>  and patch is uploaded with testing steps.
>>>>>
>>>>> Thanks And Regards
>>>>> Sumit Pandit
>>>>>
>>>>> On Jun 15, 2009, at 9:57 AM, Anil Patel wrote:
>>>>>
>>>>>> Sumit,
>>>>>> Looks like good thing to do. Having this profile handy will  
>>>>>> give us opportunity to break out of habit of using admin/ofbiz  
>>>>>> user account for testing application.
>>>>>> If you have time it will be good to create a Jira issue for it  
>>>>>> and contribute patch.
>>>>>>
>>>>>> Regards
>>>>>> Anil Patel
>>>>>>
>>>>>> On Jun 13, 2009, at 9:45 AM, Sumit Pandit wrote:
>>>>>>
>>>>>>> Hello Devs,
>>>>>>>
>>>>>>> I would like to propose setup of a new  SecurityGroup which is  
>>>>>>> dedicated to OFBiz Accounting component only. It will assigned  
>>>>>>> by all SecurityPermission which are required to handle variuos  
>>>>>>> accounting operations. Purpose of this will be to be able to  
>>>>>>> create a UserLogin, who will have restricted access to  
>>>>>>> Accounting component only.
>>>>>>>
>>>>>>> It will reflect to changes in following entities  -
>>>>>>> create a new SecurityGroup and assign all associated  
>>>>>>> SecurityPermission to it.
>>>>>>> Create a new UserLogin and assign SecurityGroup to him.
>>>>>>> Additional suggestion - Create a new PartyRole -  
>>>>>>> "ACCOUNTANT",  child of Role - "EMPLOYEE".
>>>>>>>
>>>>>>> Thoughts?
>>>>>>>
>>>>>>> Thanks And Regards
>>>>>>> Sumit Pandit
>>>>>>
>>>>>
>>>>
>>>
>>
>


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

Re: Proposal to setup a new SecurityGroup for Accounting component.

Jacopo Cappellato-4
In reply to this post by David E. Jones-2
On Jun 15, 2009, at 11:50 AM, David E Jones wrote:

>>
>>    If what I am proposing here makes sense, we can think about my  
>> last proposal as an initial start toward this effort.  We can start  
>> with defining application specific security groups.  So that if  
>> someone has permissions only for a Order Manager application, he  
>> won't be able to control other applications.
>
> Isn't this the exact opposite of what you described above?
>
> The reason I say that is that the base applications are organized  
> according to general business concepts that make up the way the data  
> is organized, and they have little to do with processes. In fact,  
> because the base application are organized this way  most business  
> processes will actually need to go across the various base  
> applications.
>
This is a very good point David: each of these roles will have  
permissions from different applications for sure. Where should we  
place the demo/seed data? Maybe we could add the data in new files in  
the ecommerce application.

> The existing security groups are probably close to the definitions  
> of actors than a security group for each application would be.  
> Because of that I think that doing so would actually be a step  
> backwards, both in theory and in practicality.
>

I agree that we should start by looking at and reviewing the existing  
process/role oriented groups and (demo) users:

https://demo.ofbiz.org/webtools/control/FindGeneric?entityName=UserLoginSecurityGroup&find=true&VIEW_SIZE=50&VIEW_INDEX=0

By reviewing I mean:

1) write short stories about the tasks allowed by each security group  
(probably as comments in seed data)
2) verify that we have a userlogin for each of the security groups  
(and create missing ones)
3) verify if a user associated to the user login is really able to  
perform the tasks listed in #1; if not, adjust permissions
4) possibly add more roles/groups and demo users

Then when we will write new stories for ofbiz, or we will implement  
new processes, we should always state for which demo users they are  
intended for.

What do you think?

Jacopo

> -David


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

Re: Proposal to setup a new SecurityGroup for Accounting component.

David E. Jones-2

On Jun 15, 2009, at 4:39 AM, Jacopo Cappellato wrote:

> On Jun 15, 2009, at 11:50 AM, David E Jones wrote:
>
>>>
>>>   If what I am proposing here makes sense, we can think about my  
>>> last proposal as an initial start toward this effort.  We can  
>>> start with defining application specific security groups.  So that  
>>> if someone has permissions only for a Order Manager application,  
>>> he won't be able to control other applications.
>>
>> Isn't this the exact opposite of what you described above?
>>
>> The reason I say that is that the base applications are organized  
>> according to general business concepts that make up the way the  
>> data is organized, and they have little to do with processes. In  
>> fact, because the base application are organized this way  most  
>> business processes will actually need to go across the various base  
>> applications.
>>
>
> This is a very good point David: each of these roles will have  
> permissions from different applications for sure. Where should we  
> place the demo/seed data? Maybe we could add the data in new files  
> in the ecommerce application.
>
>> The existing security groups are probably close to the definitions  
>> of actors than a security group for each application would be.  
>> Because of that I think that doing so would actually be a step  
>> backwards, both in theory and in practicality.
>>
>
> I agree that we should start by looking at and reviewing the  
> existing process/role oriented groups and (demo) users:
>
> https://demo.ofbiz.org/webtools/control/FindGeneric?entityName=UserLoginSecurityGroup&find=true&VIEW_SIZE=50&VIEW_INDEX=0
>
> By reviewing I mean:
>
> 1) write short stories about the tasks allowed by each security  
> group (probably as comments in seed data)
> 2) verify that we have a userlogin for each of the security groups  
> (and create missing ones)
> 3) verify if a user associated to the user login is really able to  
> perform the tasks listed in #1; if not, adjust permissions
> 4) possibly add more roles/groups and demo users
>
> Then when we will write new stories for ofbiz, or we will implement  
> new processes, we should always state for which demo users they are  
> intended for.
>
> What do you think?

We don't really have requirements for the current applications and  
security groups and permissions and such, and in fact these things  
weren't created based on a certain set of requirements but instead  
evolved over time.

I might be wrong, but I think it will be easier to start with  
requirements and move forward than to start with the implementation  
(ie OFBiz as it is now) and move backward. In other words, something  
along the lines of what is described here:

http://docs.ofbiz.org/display/OFBREQDES/UBPL+Introduction

-David


Reply | Threaded
Open this post in threaded view
|

Re: Proposal to setup a new SecurityGroup for Accounting component.

Jacopo Cappellato-4

On Jun 15, 2009, at 1:04 PM, David E Jones wrote:

>
> We don't really have requirements for the current applications and  
> security groups and permissions and such, and in fact these things  
> weren't created based on a certain set of requirements but instead  
> evolved over time.
>
> I might be wrong, but I think it will be easier to start with  
> requirements and move forward than to start with the implementation  
> (ie OFBiz as it is now) and move backward. In other words, something  
> along the lines of what is described here:
>
> http://docs.ofbiz.org/display/OFBREQDES/UBPL+Introduction
>
> -David
>
>
Starting from requirements is of course the best way to do this; but  
we have already several groups in place, whose initial meaning  
possibly evolved over time to the point where they could be complete/
incomplete/invalid... but we don't really know because no one  
documented them. I see some value in trying to document/fix/use them  
right now, waiting for the new ones coming out of the UBPL effort. We  
should also start to look at the actors coming out of the UBPL because  
they will be good candidates for demo users/roles.

What I think it is important about the UBPL effort is that we should  
do this following a lightweight approach where we will follow many  
requirements/review(of existing stuff)&design(for stuff that is  
missing)/development cycles and not a big effort where we put together  
all the requirements of the ERP system, then we do the design etc... I  
am saying this because we have the luck of already having a system  
already in place and we are not planning to redo everything, but  
instead to reuse and customize stuff to implement more specialized  
applications.

Jacopo


smime.p7s (3K) Download Attachment