OFBiz › OFBiz - Dev

Dev - Party Application

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

15 messages Options

Carlos Barros-2

Dev - Party Application

hi list!
I've sent one email to the list yesterday about not using the applications
shipped with ofbiz framework and tryied to do some research on it.
I figured out that the framework disposes a simple userlogin data model,
in the security directory inside framework/ that is used as the base
authentication for the framework. But further research pointed me
that this model (and others too) is someway linked with the party
application. I dont know about the other modules but the link in the
user login data model is required, and very simple to change. The problem
is: I dont know how deep is the link between the party application and the
framework itself. I'm asking this cause I want to use the framework to develop
my own set of application. I really liked this framework, it seems that I can
develop stuffs much quickier, but I dont want to use the applications
shipped with it, and I really dont know if this task is just as simples as
remove the link between party and the framework from the datamodels inside the
framework directory, or if the framework (CODE) is linked with this app.

any one can point me some directioin on how to do this?
best regards

Carlos Barros

_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

Adrian Crum

Re: Dev - Party Application

Carlos,

Welcome to OFBiz! Your best route to learning about OFBiz is to spend time on
the OFBiz Documention site - http://www.ofbiz.org/documents.html.

You will also need to pick up the Data Model Resource book to get an
understanding of the database schema.

My advice to you is to avoid reinventing the wheel. OFBiz has working
applications that are tested and robust. Writing your own applications will be a
waste of your time. Consider modifying the user interface instead.

-Adrian

Carlos Barros wrote:

> hi list!
> I've sent one email to the list yesterday about not using the applications
> shipped with ofbiz framework and tryied to do some research on it.
> I figured out that the framework disposes a simple userlogin data model,
> in the security directory inside framework/ that is used as the base
> authentication for the framework. But further research pointed me
> that this model (and others too) is someway linked with the party
> application. I dont know about the other modules but the link in the
> user login data model is required, and very simple to change. The problem
> is: I dont know how deep is the link between the party application and the
> framework itself. I'm asking this cause I want to use the framework to develop
> my own set of application. I really liked this framework, it seems that I can
> develop stuffs much quickier, but I dont want to use the applications
> shipped with it, and I really dont know if this task is just as simples as
> remove the link between party and the framework from the datamodels inside the
> framework directory, or if the framework (CODE) is linked with this app.
>
> any one can point me some directioin on how to do this?
> best regards
>
> Carlos Barros
>
>
>
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev
>

_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

Carlos Barros-2

Re: Dev - Party Application

In reply to this post by Carlos Barros-2

Just to complement this email,
i've looked at the Hotel Backend Demo at ofbiz.org and
and the party management is diferent from the party shipped
with the framework, as well the accountig one..

was it made from the scratch or adapted (or something like that)
from the original one?

regards
Carlos Barros

On Wed, 26 Apr 2006 12:43:50 -0300
Carlos Barros <[hidden email]> wrote:

_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

David E. Jones

Re: Dev - Party Application

In reply to this post by Carlos Barros-2

Carlos,

It should be possible to use everything in OFBiz except the applications by simply removing the applications directory and perhaps the reference to it in the component-load.xml file. We would like to make it possible to use the framework independently and so have reorganized things and made changes in this direction over the years, but I'm not aware of any extensive testing having been done on it for using it this way.

The security data model only has one link to the party data model and that is the UserLogin.partyId field and the corresponding foreign key. If you comment out the relation tag to define it then it should work fine, and the partyId can be left null.

Again this hasn't been thoroughly tested, but should work fine. If you do find any dependencies as you try it please let us know (perhaps with a Jira issue submission, but even a mailing list message, preferably on the users list as this is concerned more with the use of OFBiz than development of OFBiz).

-David

Carlos Barros wrote:

_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

Carlos Barros-2

Re: Dev - Party Application

On Wed, 26 Apr 2006 18:23:09 +0100
David E Jones <[hidden email]> wrote:

>
> Carlos,
>
> It should be possible to use everything in OFBiz except the applications by simply removing the applications directory and perhaps the reference to it in the component-load.xml file. We would like to make it possible to use the framework independently and so have reorganized things and made changes in this direction over the years, but I'm not aware of any extensive testing having been done on it for using it this way.
>
> The security data model only has one link to the party data model and that is the UserLogin.partyId field and the corresponding foreign key. If you comment out the relation tag to define it then it should work fine, and the partyId can be left null.

If i do a quick search for Party in the entitymodels i get 3 files.
the security one is that one u talked about.. the other two and not sure
but i think the relation is used on by the Party application, so it is should
be safe to remove the relation..

ofbiz@zaphod:~/ofbiz/framework$ find . -name entitymodel.xml -exec grep -l Party {} \;
./common/entitydef/entitymodel.xml
./security/entitydef/entitymodel.xml
./webapp/entitydef/entitymodel.xml
ofbiz@zaphod:~/ofbiz/framework$

Well, Adrian said about modifying the UI, it can be one good option too. In the
hotel backend demo the party application is completely modified. I think the
best choice here is remodeling this application to fit my needs. About the
other applications, the problem is that I'll not use it, actualy I dont need it
(at least for now). But the party one I'll need and I think the best choice,
as Adrian said, is remodeling the UI. Is there some document about the datamodel
of the party application, so I can adapt the UI to my needs, and remove what I dont
need?

regards

>
> Again this hasn't been thoroughly tested, but should work fine. If you do find any dependencies as you try it please let us know (perhaps with a Jira issue submission, but even a mailing list message, preferably on the users list as this is concerned more with the use of OFBiz than development of OFBiz).
>
> -David
>
>
> Carlos Barros wrote:
> > hi list!
> > I've sent one email to the list yesterday about not using the applications
> > shipped with ofbiz framework and tryied to do some research on it.
> > I figured out that the framework disposes a simple userlogin data model,
> > in the security directory inside framework/ that is used as the base
> > authentication for the framework. But further research pointed me
> > that this model (and others too) is someway linked with the party
> > application. I dont know about the other modules but the link in the
> > user login data model is required, and very simple to change. The problem
> > is: I dont know how deep is the link between the party application and the
> > framework itself. I'm asking this cause I want to use the framework to develop
> > my own set of application. I really liked this framework, it seems that I can
> > develop stuffs much quickier, but I dont want to use the applications
> > shipped with it, and I really dont know if this task is just as simples as
> > remove the link between party and the framework from the datamodels inside the
> > framework directory, or if the framework (CODE) is linked with this app.
> >
> > any one can point me some directioin on how to do this?
> > best regards
> >
> > Carlos Barros
> >
> >
> >
> > _______________________________________________
> > Dev mailing list
> > [hidden email]
> > http://lists.ofbiz.org/mailman/listinfo/dev
>
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

Andrew Sykes

Re: Dev - Party Application

In reply to this post by Carlos Barros-2

Carlos,

The Hotel stuff is primarily the work of Hans Bakker, hopefully he'll
notice this and pass on some advice.

If you haven't already, you should look at the entity reference page
in /webtools

Good luck with it all.
--
Kind Regards
Andrew Sykes <[hidden email]>
Sykes Development Ltd
http://www.sykesdevelopment.com

_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

Hans Bakker

Re: Dev - Party Application

In reply to this post by Carlos Barros-2

Hi Carlos,

some advice after building the opentravelsystem, please also read the document
in that directory.

if you do not like the OFBiz application, have a look at the hotelbackend. It
is using as much as possible of the ofbiz system however within one component
only, and showing only a limited functionality in a shared environment.
(major entities ID's are automatically prefixed when created and the find
screens limit the search on this prefix also automatically when you activate
(compile) the opentravelsystem.
Currently we are also implementing a different screen design for the backend
which is partly done.

I am also working very hard to get translation completely working. We just
lauched the site for test on http://www.openwinkel.nl and will go online with
a bowling support shop in a few weeks using it.

The opentravelsystem demo's at this moment are not working very good, however
i will get them functional again in a week or so.

You can write complete SOA (Service Oriented Architecture)applications only
using screen/form and minilanguage services, no bsh or java required. Write
however only new services if you could not find an existing one.

If you have further questions let me know.

--
Regards,
Hans Bakker
ANT Websystems Co.,Ltd (http://www.antwebsystems.com)

If you want to verify that this message really originates from
from the above person, download the public key from:
http://www.antwebsystems.com/hbakkerAntwebsystems.asc

On Wednesday 26 April 2006 22:55, Carlos Barros wrote:

> Just to complement this email,
> i've looked at the Hotel Backend Demo at ofbiz.org and
> and the party management is diferent from the party shipped
> with the framework, as well the accountig one..
>
> was it made from the scratch or adapted (or something like that)
> from the original one?
>
> regards
> Carlos Barros
>
> On Wed, 26 Apr 2006 12:43:50 -0300
>
> Carlos Barros <[hidden email]> wrote:
> > hi list!
> > I've sent one email to the list yesterday about not using the
> > applications shipped with ofbiz framework and tryied to do some research
> > on it. I figured out that the framework disposes a simple userlogin data
> > model, in the security directory inside framework/ that is used as the
> > base authentication for the framework. But further research pointed me
> > that this model (and others too) is someway linked with the party
> > application. I dont know about the other modules but the link in the user
> > login data model is required, and very simple to change. The problem is:
> > I dont know how deep is the link between the party application and the
> > framework itself. I'm asking this cause I want to use the framework to
> > develop my own set of application. I really liked this framework, it
> > seems that I can develop stuffs much quickier, but I dont want to use the
> > applications shipped with it, and I really dont know if this task is just
> > as simples as remove the link between party and the framework from the
> > datamodels inside the framework directory, or if the framework (CODE) is
> > linked with this app.
> >
> > any one can point me some directioin on how to do this?
> > best regards
> >
> > Carlos Barros
> >
> >
> >
> > _______________________________________________
> > Dev mailing list
> > [hidden email]
> > http://lists.ofbiz.org/mailman/listinfo/dev
>
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

attachment0 (196 bytes) Download Attachment

Ean Schuessler

Re: Dev - Party Application

In reply to this post by David E. Jones

On Wednesday 26 April 2006 12:23, David E Jones wrote:

> It should be possible to use everything in OFBiz except the applications by
> simply removing the applications directory and perhaps the reference to it
> in the component-load.xml file. We would like to make it possible to use
> the framework independently and so have reorganized things and made changes
> in this direction over the years, but I'm not aware of any extensive
> testing having been done on it for using it this way.
>
> The security data model only has one link to the party data model and that
> is the UserLogin.partyId field and the corresponding foreign key. If you
> comment out the relation tag to define it then it should work fine, and the
> partyId can be left null.
>
> Again this hasn't been thoroughly tested, but should work fine. If you do
> find any dependencies as you try it please let us know (perhaps with a Jira
> issue submission, but even a mailing list message, preferably on the users
> list as this is concerned more with the use of OFBiz than development of
> OFBiz).

There seems to be a little schizophernia in the OFBiz applications when it
comes to separating parties from user logins. I find myself needing role
oriented security for many applications that our clients are developing and
the framework tends to favor parties as the connection point for that to
happen. For instance, websites in the content system and stores in the
catalog system both grant roles to users through associations to parties
(typically with time filtering). That's fine but it would seem that if the
recommended approach is through UserLogins then we should see those roles
associated with that entity instead of a Party. I'm fine with either approach
and even like/prefer the idea of those things using UserLogins instead of
Parties but that isn't the current methodology.

--
Ean Schuessler, CTO
[hidden email]
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com

_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

cjhowe

Re: Dev - Party Application

I think the link to party instead of userlogin is to
allow the same party to limit their permissions by how
they're logged in (since one party may have multiple
user names) but still be able to track all the actions
of that person as one person. Take for example the
scenario that a sales rep has. Having the current
setup allows a sales rep to use one user name and see
his cost for the product when he is in private. Then
have him use a different user name when he is infront
of his client where he certainly doesn't want to
reveal his cost, but rather his client's cost. This
allows the salesrep to learn only one application. In
addition if a username is abandoned, it doesn't
abandon the record of the person.

--- Ean Schuessler <[hidden email]> wrote:

> On Wednesday 26 April 2006 12:23, David E Jones
> wrote:
> > It should be possible to use everything in OFBiz
> except the applications by
> > simply removing the applications directory and
> perhaps the reference to it
> > in the component-load.xml file. We would like to
> make it possible to use
> > the framework independently and so have
> reorganized things and made changes
> > in this direction over the years, but I'm not
> aware of any extensive
> > testing having been done on it for using it this
> way.
> >
> > The security data model only has one link to the
> party data model and that
> > is the UserLogin.partyId field and the
> corresponding foreign key. If you
> > comment out the relation tag to define it then it
> should work fine, and the
> > partyId can be left null.
> >
> > Again this hasn't been thoroughly tested, but
> should work fine. If you do
> > find any dependencies as you try it please let us
> know (perhaps with a Jira
> > issue submission, but even a mailing list message,
> preferably on the users
> > list as this is concerned more with the use of
> OFBiz than development of
> > OFBiz).
>
> There seems to be a little schizophernia in the
> OFBiz applications when it
> comes to separating parties from user logins. I find
> myself needing role
> oriented security for many applications that our
> clients are developing and
> the framework tends to favor parties as the
> connection point for that to
> happen. For instance, websites in the content system
> and stores in the
> catalog system both grant roles to users through
> associations to parties
> (typically with time filtering). That's fine but it
> would seem that if the
> recommended approach is through UserLogins then we
> should see those roles
> associated with that entity instead of a Party. I'm
> fine with either approach
> and even like/prefer the idea of those things using
> UserLogins instead of
> Parties but that isn't the current methodology.
>
> --
> Ean Schuessler, CTO
> [hidden email]
> 214-720-0700 x 315
> Brainfood, Inc.
> http://www.brainfood.com
>
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev
>

_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

Ean Schuessler

Re: Dev - Party Application

On Wednesday 26 April 2006 23:12, Chris Howe wrote:
> I think the link to party instead of userlogin is to
> allow the same party to limit their permissions by how
> they're logged in (since one party may have multiple
> user names) but still be able to track all the actions
> of that person as one person.

I don't think it lets you do that. Since the association is by party, the
UserLogin will have no influence over the behavior of the application.

> Take for example the
> scenario that a sales rep has. Having the current
> setup allows a sales rep to use one user name and see
> his cost for the product when he is in private. Then
> have him use a different user name when he is infront
> of his client where he certainly doesn't want to
> reveal his cost, but rather his client's cost. This
> allows the salesrep to learn only one application. In
> addition if a username is abandoned, it doesn't
> abandon the record of the person.

Association by UserLogin would not prevent pricing by Party. Since there is
only one Party associated with a given UserLogin you can still do Party based
operations from the UserLogin. The only negative side effect is that all the
Parties in these types of roles (ie. Vendor, etc.) would have to have
UserLogins and that seems a little undesirable.

--
Ean Schuessler, CTO
[hidden email]
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com

_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

Adrian Crum

Re: Dev - Party Application

In reply to this post by cjhowe

The sales rep example could be handled by an enhancement we implemented here.

We set up what we call an Organization Context. There can be any number of
Organization Contexts set up. Parties are related to particular Organization
Contexts. When the user logs into OFBiz, they are required to select one of the
Organization Contexts that they have been associated with. We redesigned the UI
to allow the logged-in party to interact only with data that is somehow related
to the Organization Context they are logged into.

Using a system like this, a sales rep with a single Userlogin could log into one
of two Organization Contexts: Retail or Wholesale.

Chris Howe wrote:

> I think the link to party instead of userlogin is to
> allow the same party to limit their permissions by how
> they're logged in (since one party may have multiple
> user names) but still be able to track all the actions
> of that person as one person. Take for example the
> scenario that a sales rep has. Having the current
> setup allows a sales rep to use one user name and see
> his cost for the product when he is in private. Then
> have him use a different user name when he is infront
> of his client where he certainly doesn't want to
> reveal his cost, but rather his client's cost. This
> allows the salesrep to learn only one application. In
> addition if a username is abandoned, it doesn't
> abandon the record of the person.
>
> --- Ean Schuessler <[hidden email]> wrote:
>
>
>>On Wednesday 26 April 2006 12:23, David E Jones
>>wrote:
>>
>>>It should be possible to use everything in OFBiz
>>
>>except the applications by
>>
>>>simply removing the applications directory and
>>
>>perhaps the reference to it
>>
>>>in the component-load.xml file. We would like to
>>
>>make it possible to use
>>
>>>the framework independently and so have
>>
>>reorganized things and made changes
>>
>>>in this direction over the years, but I'm not
>>
>>aware of any extensive
>>
>>>testing having been done on it for using it this
>>
>>way.
>>
>>>The security data model only has one link to the
>>
>>party data model and that
>>
>>>is the UserLogin.partyId field and the
>>
>>corresponding foreign key. If you
>>
>>>comment out the relation tag to define it then it
>>
>>should work fine, and the
>>
>>>partyId can be left null.
>>>
>>>Again this hasn't been thoroughly tested, but
>>
>>should work fine. If you do
>>
>>>find any dependencies as you try it please let us
>>
>>know (perhaps with a Jira
>>
>>>issue submission, but even a mailing list message,
>>
>>preferably on the users
>>
>>>list as this is concerned more with the use of
>>
>>OFBiz than development of
>>
>>>OFBiz).
>>
>>There seems to be a little schizophernia in the
>>OFBiz applications when it
>>comes to separating parties from user logins. I find
>>myself needing role
>>oriented security for many applications that our
>>clients are developing and
>>the framework tends to favor parties as the
>>connection point for that to
>>happen. For instance, websites in the content system
>>and stores in the
>>catalog system both grant roles to users through
>>associations to parties
>>(typically with time filtering). That's fine but it
>>would seem that if the
>>recommended approach is through UserLogins then we
>>should see those roles
>>associated with that entity instead of a Party. I'm
>>fine with either approach
>>and even like/prefer the idea of those things using
>>UserLogins instead of
>>Parties but that isn't the current methodology.
>>
>>--
>>Ean Schuessler, CTO
>>[hidden email]
>>214-720-0700 x 315
>>Brainfood, Inc.
>>http://www.brainfood.com
>>
>>_______________________________________________
>>Dev mailing list
>>[hidden email]
>>http://lists.ofbiz.org/mailman/listinfo/dev
>>
>
>
>
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev
>

_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

cjhowe

Re: Dev - Party Application

In reply to this post by Ean Schuessler

Security groups are associated with user login (and
security permissions with security groups), not with
party. Security groups (has_permission in ftl,
if-has-permission in screen widget) is (or should be)
how it's controlled on the application level. I'm not
saying that much thought has made it into OFBiz in
this regard thus far. But, in the sales rep example,
replogin1 would have the security group of say
WHOLESALE_VIEW, so if you took the ecommerce
application and added a bit of code to display product
cost ie..

<#if has_permission("WHOLESALE", "_VIEW", session)>
${productPrice.averageCost}
</#if>

salesrep logged in as replogin1 would see it, where
logged in as replogin2 who does not have that security
permission (or group that has that permission) would
not see that line (my syntax may be slightly off in
the example)

In summary, it's my understanding that the data layer
is what is checking the associated parties, and the
application layer is controlling the permissions.

--- Ean Schuessler <[hidden email]> wrote:

> On Wednesday 26 April 2006 23:12, Chris Howe wrote:
> > I think the link to party instead of userlogin is
> to
> > allow the same party to limit their permissions by
> how
> > they're logged in (since one party may have
> multiple
> > user names) but still be able to track all the
> actions
> > of that person as one person.
>
> I don't think it lets you do that. Since the
> association is by party, the
> UserLogin will have no influence over the behavior
> of the application.
>
> > Take for example the
> > scenario that a sales rep has. Having the current
> > setup allows a sales rep to use one user name and
> see
> > his cost for the product when he is in private.
> Then
> > have him use a different user name when he is
> infront
> > of his client where he certainly doesn't want to
> > reveal his cost, but rather his client's cost.
> This
> > allows the salesrep to learn only one application.
> In
> > addition if a username is abandoned, it doesn't
> > abandon the record of the person.
>
> Association by UserLogin would not prevent pricing
> by Party. Since there is
> only one Party associated with a given UserLogin you
> can still do Party based
> operations from the UserLogin. The only negative
> side effect is that all the
> Parties in these types of roles (ie. Vendor, etc.)
> would have to have
> UserLogins and that seems a little undesirable.
>
> --
> Ean Schuessler, CTO
> [hidden email]
> 214-720-0700 x 315
> Brainfood, Inc.
> http://www.brainfood.com
>
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev
>

_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

Ean Schuessler

Re: Dev - Party Application

In reply to this post by Adrian Crum

On Thursday 27 April 2006 10:15, Adrian Crum wrote:

> We set up what we call an Organization Context. There can be any number of
> Organization Contexts set up. Parties are related to particular
> Organization Contexts. When the user logs into OFBiz, they are required to
> select one of the Organization Contexts that they have been associated
> with. We redesigned the UI to allow the logged-in party to interact only
> with data that is somehow related to the Organization Context they are
> logged into.
>
> Using a system like this, a sales rep with a single Userlogin could log
> into one of two Organization Contexts: Retail or Wholesale.

That sounds a little like two separate stores... one retail and one wholesale.
Would that approach have worked as well?

--
Ean Schuessler, CTO
[hidden email]
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com

_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

Adrian Crum

Re: Dev - Party Application

I suggested it as a way of controlling what information is visible according to
the context the user logged in to. It would be a way to log into one store but
with different sets of permissions.

I like Chris Howe's solution better though. It takes less code modification.

The differences between my suggestion and Chris's is: mine requires only one
user login name.

Ean Schuessler wrote:

> On Thursday 27 April 2006 10:15, Adrian Crum wrote:
>
>>We set up what we call an Organization Context. There can be any number of
>>Organization Contexts set up. Parties are related to particular
>>Organization Contexts. When the user logs into OFBiz, they are required to
>>select one of the Organization Contexts that they have been associated
>>with. We redesigned the UI to allow the logged-in party to interact only
>>with data that is somehow related to the Organization Context they are
>>logged into.
>>
>>Using a system like this, a sales rep with a single Userlogin could log
>>into one of two Organization Contexts: Retail or Wholesale.
>
>
> That sounds a little like two separate stores... one retail and one wholesale.
> Would that approach have worked as well?
>

_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

David E. Jones

Re: Dev - Party Application

In reply to this post by cjhowe

I don't know if the current security scheme is well documented anywhere, but it's fairly simple so here's a quick summary...

The larger domain of security is split into 2 categories in OFBiz:

1. application/functionality level security
2. data level security

Category #1 (UserLogin-driven) doesn't know about anything except the UserLogin, the permissions checked for different screens, services, etc, and the SecurityGroup structure that maps between them.

Category #2 (Party-driven) can be combined with #1, usually with special "role limited" permissions that when checked require not just the permission, but some relationship between the Party and whatever records are concerned by the screen, service, or whatever.

It should be possible (in theory, I haven't tested it...) to use the Category #1 security without the party component, but #2 is very dependent on the Party data model and whatever data model relates to it for the required relationships.

This is the general design. What exists OOTB in OFBiz has various examples of both, but no attempt has been made to create a comprehensive or at least "generically complete" set of security settings in either style #1 or #2. Si Chen, et al have put some effort into more granular permissions for style #1, and that is quite helpful.

While much more effort for something like this is needed I'm still not totally convinced of the usefulness. I don't think I've worked with any 2 clients that had the same staff structure and desire for the same set of permissions, though certain ones do come up now and again or could be reduced to a more granular set of permissions that both could use. Whatever the case, this is an area of customization that tends to be pretty complex and there is as much variety in it as there are combinations of relationships of entities in OFBiz. You could write zeroes for a while trying to get a real number for the possible combinations there... ;)

-David

Chris Howe wrote:

> Security groups are associated with user login (and
> security permissions with security groups), not with
> party. Security groups (has_permission in ftl,
> if-has-permission in screen widget) is (or should be)
> how it's controlled on the application level. I'm not
> saying that much thought has made it into OFBiz in
> this regard thus far. But, in the sales rep example,
> replogin1 would have the security group of say
> WHOLESALE_VIEW, so if you took the ecommerce
> application and added a bit of code to display product
> cost ie..
>
>
> <#if has_permission("WHOLESALE", "_VIEW", session)>
> ${productPrice.averageCost}
> </#if>
>
> salesrep logged in as replogin1 would see it, where
> logged in as replogin2 who does not have that security
> permission (or group that has that permission) would
> not see that line (my syntax may be slightly off in
> the example)
>
> In summary, it's my understanding that the data layer
> is what is checking the associated parties, and the
> application layer is controlling the permissions.
>
> --- Ean Schuessler <[hidden email]> wrote:
>
>> On Wednesday 26 April 2006 23:12, Chris Howe wrote:
>>> I think the link to party instead of userlogin is
>> to
>>> allow the same party to limit their permissions by
>> how
>>> they're logged in (since one party may have
>> multiple
>>> user names) but still be able to track all the
>> actions
>>> of that person as one person.
>> I don't think it lets you do that. Since the
>> association is by party, the
>> UserLogin will have no influence over the behavior
>> of the application.
>>
>>> Take for example the
>>> scenario that a sales rep has. Having the current
>>> setup allows a sales rep to use one user name and
>> see
>>> his cost for the product when he is in private.
>> Then
>>> have him use a different user name when he is
>> infront
>>> of his client where he certainly doesn't want to
>>> reveal his cost, but rather his client's cost.
>> This
>>> allows the salesrep to learn only one application.
>> In
>>> addition if a username is abandoned, it doesn't
>>> abandon the record of the person.
>> Association by UserLogin would not prevent pricing
>> by Party. Since there is
>> only one Party associated with a given UserLogin you
>> can still do Party based
>> operations from the UserLogin. The only negative
>> side effect is that all the
>> Parties in these types of roles (ie. Vendor, etc.)
>> would have to have
>> UserLogins and that seems a little undesirable.
>>
>> --
>> Ean Schuessler, CTO
>> [hidden email]
>> 214-720-0700 x 315
>> Brainfood, Inc.
>> http://www.brainfood.com
>>
>> _______________________________________________
>> Dev mailing list
>> [hidden email]
>> http://lists.ofbiz.org/mailman/listinfo/dev
>>
>
>
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev