Hi,
I have read the links above. But I can't understand how category 2 (data
level security) works.
I also see method hasRolePermission(String application, String action,
String entityName, EntityCondition condition, GenericValue userLogin) where
EntityName and EntityCondition are mentioned (and another method with
parameter List<String> roles).
But I see no example of how they work.

In Parties relationship I see that it is possible to assign Security Group
ID. But I cant see how it is connected to other entities (only in xml's of
other applications, where application and action is mentioned) and to other
entities field.

As result i can't understand: is it possible to prohibit user to work with
entity based on fields values? (without using complex permissions, where
you can code anything you want)

For example with Demo data - is it possible to prohibit user to user value
"Google Catalog" in Purchase Orders? and Allow him to choose any other
available catalog from the list?

I also found similar question here
http://ofbiz.116.s1.nabble.com/Security-hasRolePermission-or-DataDrivenSecurity-td154342.html
and similar case, when entites field value should be checked here
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=7045135

But did not found answer about - is it possible or not with Data Level
Security Category.

BR,
Denis


Fri, 7 Mar. 2025 г. at 13:31, Ashish Vijaywargiya <
[email protected]>:

> Hello Alexander,
>
> It looks like you need to explore Role Based Permission in OFBiz.
> Following document can be helpful to you:
>
> https://cwiki.apache.org/confluence/x/NIBr
>
> Additionally following links can be referred:
>
> https://www.hotwaxsystems.com/hotwax-blog/ofbiz/ofbiz-tutorials/ofbiz-tutorial-how-to-setup-permission-for-a-new-user-to-access-an-application
>
> https://medium.com/@anchitjindal91/ofbiz-security-groups-permissions-63af179355d0
>
> --
> Kind Regards,
> Ashish Vijaywargiya
> Vice President of Operations
> *HotWax Systems*
> *Enterprise open source experts*
> http://www.hotwaxsystems.com
>
>
>
>
> On Fri, Mar 7, 2025 at 3:28 PM Alexander Bolgarin <
> [email protected]> wrote:
>
> > >
> > > Dear OFBiz Community,
> > >
> >
> >
> > > Kindly ask to help with Permission check questions. I’m seeking
> > > clarification on how permission checks work for entities in OFBiz and
> > would
> > > appreciate any insights or pointers to relevant documentation. Below
> are
> > > some specific scenarios I’m trying to understand:
> > >
> > >    1. Restricting User A to Purchase Orders Only
> > >    I’d like to restrict User A so they can only work with purchase
> > >    orders. This would require the permission check to examine the
> > >    ORDER_HEADER entity, specifically the ORDER_TYPE_ID field. If it
> > >    equals "PURCHASE_ORDER", the user should be allowed to create, edit,
> > >    or delete the order; if it equals "SALES_ORDER", these actions
> should
> > >    be prohibited. Based on the demo data, it seems this is achievable
> > with
> > >    standard functionality. Can someone confirm how this is typically
> > >    implemented?
> > >    2. Granular Permissions Across Parties
> > >    Is it possible to configure permissions so User A can:
> > >    - Create purchase orders for Party "Company1" (an internal
> > >       organization).
> > >       - Create sales orders for Party "Company2".
> > >       If so, how would this be set up?
> > >       3. Restricting Accountant to Specific GL Account Types
> > >    Can I allow an accountant to use GL Accounts in GL Transactions, but
> > >    only for accounts where GL_ACCOUNT_TYPE_ID is either "Customer" or
> > >    "Supplier"? Is there a way to limit access to just these types and
> > >    exclude all others?
> > >
> > > Lastly, is there a resource (e.g., documentation, wiki, or code
> comments)
> > > that explains how security checks work in OFBiz? I’d love to dive
> deeper
> > > into the mechanics of permissions and entity-level access control.
> > > Thanks in advance for your help!
> > >
> > > Best regards,
> > > Alexander
> > >
> >
>

Reply via email to