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
Using a system like this, a sales rep with a single Userlogin could log into one
> 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>