Openbravo Issue Tracking System - Openbravo ERP
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0057769Openbravo ERPA. Platformpublic2025-01-28 08:482025-02-03 11:18
ReporterAugustoMauch 
Assigned ToAugustoMauch 
PrioritynormalSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOS5OS Version
Product Version 
Target VersionFixed in VersionPR25Q2 
Merge Request Statusapproved
Review Assigned To
OBNetwork customerNo
Web browser
ModulesCore
Support ticket
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary0057769: Entity is not accesible by role, even when the role configuration should allow it
DescriptionDepending on how other roles are configured, it is possible that an automatic role, that should by default have access to all entities, will miss access to some.
Steps To Reproduce- Create a role called ManualTest.
- Set it as manual
- Create an entry in the Window Access subtab. Window: Sales order, Active: false

- Create another role called NonManualTest
- Make sure Manual=false
- Assign it to the usuario de Openbravo
- Logout

- Login as Openbravo
- Change role, use NonManualTest
- Open Sales Order. An error will be displayed when rendering rows for the Lines subtab:

org.openbravo.base.exception.OBSecurityException: Entity OrderLine is not accessible by this role/user: TestRoleNotAdvanced/Openbravo
Proposed Solution
Additional Information
TagsNo tags attached.
Relationships
depends on backport 0057770PR25Q1 closed AugustoMauch Entity is not accesible by role, even when the role configuration should allow it 
depends on backport 0057771PR24Q4.1 closed AugustoMauch Entity is not accesible by role, even when the role configuration should allow it 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2025-01-28 08:48AugustoMauchNew Issue
2025-01-28 08:48AugustoMauchAssigned To => AugustoMauch
2025-01-28 08:48AugustoMauchOBNetwork customer => No
2025-01-28 08:48AugustoMauchModules => Core
2025-01-28 08:48AugustoMauchTriggers an Emergency Pack => No
2025-01-28 08:50AugustoMauchStatusnew => scheduled
2025-01-28 12:17hgbotMerge Request Status => open
2025-01-28 12:17hgbotNote Added: 0174807
2025-01-28 12:47ivazquezIssue Monitored: ivazquez
2025-01-29 08:46hgbotMerge Request Statusopen => approved
2025-02-03 11:18hgbotResolutionopen => fixed
2025-02-03 11:18hgbotStatusscheduled => closed
2025-02-03 11:18hgbotNote Added: 0175042
2025-02-03 11:18hgbotFixed in Version => PR25Q2
2025-02-03 11:18hgbotNote Added: 0175043

Notes
(0174807)
hgbot   
2025-01-28 12:17   
Merge Request created: https://gitlab.com/orisha-group/bu-commerce/openbravo/product/openbravo/-/merge_requests/1514 [^]
(0175042)
hgbot   
2025-02-03 11:18   
Merge request merged: https://gitlab.com/orisha-group/bu-commerce/openbravo/product/openbravo/-/merge_requests/1514 [^]
(0175043)
hgbot   
2025-02-03 11:18   
Directly closing issue as related merge request is already approved.

Repository: https://gitlab.com/orisha-group/bu-commerce/openbravo/product/openbravo [^]
Changeset: 8fbb1539927d54510869b0740b8168f69ce69424
Author: Augusto Mauch <amauch@orisha.com>
Date: 03-02-2025 10:18:17
URL: https://gitlab.com/orisha-group/bu-commerce/openbravo/product/openbravo/-/commit/8fbb1539927d54510869b0740b8168f69ce69424 [^]

Fixes ISSUE-57769: Table access for auto role is not properly checked

There was a problem in the query that was used to determine if an auto role was explicitly denied access
to a given table, in the getAutomaticTableAccess method. The problem was that the query wanted to check
that there are no disabled entries in ADWindowAccess for this role, but the role filter was missing in
the subquery. As a consequence, if a table was disabled for other roles, the configuration leaked to other
auto roles.

Also a change was done to getManualTableAccess to avoid granting access to tables, if the isActive property
in the header tab is false.

---
M src/org/openbravo/dal/security/EntityAccessChecker.java
---