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
