Openbravo Issue Tracking System - Openbravo ERP
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007311Openbravo ERP03. Procurement managementpublic2009-02-02 12:282009-02-05 06:26
Reporterjoan 
Assigned Topjuvara 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionno change required 
PlatformOS30OS VersionDebian Etch
Product Version2.40 
Target VersionFixed in Version 
Merge Request Status
Review Assigned To
OBNetwork customer
Web browser
ModulesCore
Support ticket
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary0007311: M_requisition Window doesn't follow security model
DescriptionIn the Requisition window, only the user that inserted the requisition can see his own requisition (defined by ad_user_id in m_requisition table) and not the same role users. I know this is a where clause in the header window and you can change it by your own. But I think the default behavoir of this window should be that all the users of the same role can see the requisitions made by this role. In this way you keep the Openbravo security model that claims to be by role, and not by user.

It is something quite confusing to the new users dont to see the documents made by the same role and just the documents created by you.
Steps To ReproduceLogin with user U1 With role R1
Create a requisition with user U1
Change to user U2 with role R1
Try to see the requisition made by U1, I think it should be displayed (not filtered)

Proposed Solution
Additional Information
TagsNo tags attached.
Relationships
related to feature request 0004716 closed pjuvara Requisition and Manage Requisitions form are almost identical 
related to feature request 0007374 acknowledged iciordia Secure records so that only user who created them can view them 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2009-02-02 12:28joanNew Issue
2009-02-02 12:28joanAssigned To => rafaroda
2009-02-02 12:28joansf_bug_id0 => 2556621
2009-02-03 16:31rafarodaAssigned Torafaroda => pjuvara
2009-02-05 06:26pjuvaraRegression testing => No
2009-02-05 06:26pjuvaraStatusnew => closed
2009-02-05 06:26pjuvaraNote Added: 0013161
2009-02-05 06:26pjuvaraResolutionopen => no change required
2009-02-05 06:32pjuvaraRelationship addedrelated to 0004716
2009-02-05 06:43pjuvaraRelationship addedrelated to 0007374

Notes
(0013161)
pjuvara   
2009-02-05 06:26   
Joan,

this is the intended behavior. Please let me explain.

The business flow that we intend to support is one where employees can request products and services to be purchased by the enterprise on their behalf. These could be, for instance, raw materials that the VP of manufacturing needs to produce, products purchased for resale, but also expense items such as office supply or services such as legal services, consulting services, etc.

One of the requirements to support this flow is that only the employee that requested the product or service and the purchasing agent that will process it are able to view the requisition.

For instance, if I request to purchase a new set of business cards, only myself and the person who is responsible to find the most appropriate printing company and order the card need to know about it.

For this reason, we have introduced two windows who look similar but have different behavior.
- Requisitions: where employee create requisitions; to handle the above requirement, only the user who created the record is able to see it
- Manage Requisitions: where purchasing agents can see and process all the requisitions that have been created according to the normal organization based security.

Please notice that, while in an unconfigured system this might look a bit confusing because both windows sit side by side, in a properly configured system these two windows would not belong to the same role. You should configure the system with at least two roles:
- Employee: having access to Requistions
- Purchasing agent: having access to Manage Requisition

Please feel free to reopen this feature request if you disagree with this explanation.

Paolo