Uploaded image for project: 'OFBiz'
  1. OFBiz
  2. OFBIZ-12371

BudgetRole: improbable selection possible, PartyRole gets created

Details

    • Bug
    • Status: Open
    • Major
    • Resolution: Unresolved
    • Trunk, 18.12.01, Upcoming Branch
    • None
    • accounting

    Description

      On the BudgetRole page (see https://demo-stable.ofbiz.apache.org/accounting/control/BudgetRoles?budgetId=DemoBudget001) an improbable combination of Party and Role can be set and submitted. Leading to PartyRole record being created.

       

      Attachments

        Issue Links

          Activity

            mbrohl Michael Brohl added a comment -

            Can you explain what goes wrong there in your opinion? What do you expect?

            A common logic with roles is to implicitely create the needed role using the ensurePartyRole service. I think the currently implemented business logic takes any party and ensures the needed role.

            If the expectation would be that only parties already having this role can be selected, this would be a change of the business logic. Without ensurePartyRole, you would also first have to assign the role to the party and then create the BudgetRole in this case. I don't think this is a convenient approach. Users can change this behaviour in their custom projects any time.

            I think this is the same for all other Jiras you have created recently.

            mbrohl Michael Brohl added a comment - Can you explain what goes wrong there in your opinion? What do you expect? A common logic with roles is to implicitely create the needed role using the ensurePartyRole service. I think the currently implemented business logic takes any party and ensures the needed role. If the expectation would be that only parties already having this role can be selected, this would be a change of the business logic. Without ensurePartyRole, you would also first have to assign the role to the party and then create the BudgetRole in this case. I don't think this is a convenient approach. Users can change this behaviour in their custom projects any time. I think this is the same for all other Jiras you have created recently.
            pierresmits Pierre Smits added a comment -

            Thank you for your questions, Michael.

            This is where the logic goes wrong in current situation:

            with current situation:

            1. any Party (including external parties, like a customer, or a lead, etc.) can be selected as the party for the BudgetRole record
            2. the selected party can be associated with any RoleType (including those nothing to have to do with the budget, e.g. COMPETITOR)

            Is such desirable, from an accounting domain's perspective? No, the user should only be permitted to:

            1. select one of the RoleTypes that is related to budgets (these are defined in the seed data set), and
            2. based on that selection only be allowed to select from the list of applicable PartyRole records that meet the criterium under 1.

            And why is it undesirable to allow otherwise?

            Because, budget information is confidential information: only selected parties (within the internal organisation) are allowed to create/edit Budget and related records and to review/approve/reject budgets. And only those identified to audit the books (workers from the CPA) would be regarded as potential reviewers.

            Department manager (and every person higher up in the hierarchy) are required to budget for stuff. More often than not, these parties don't do this online, but work with spreadsheets. And often they don't actually do this themselves, but delegate such task to a trusted delegate within the party. They review and approve/reject what their delegates has concocted. And when these managers approve of what their delegates has delivered, they send it to their appropriate counterpart in the accounting department (the administrator, or financial controller, or CFO). Who hands it down the line to someone who is allowed (the administration assistant) to create (and if need be edit) the Budget record (and related) in the accounting system (OFBiz accounting, here). The administration assistant, however, is not allowed to approve/reject budgets, so create/edit yes but approve/reject no.

            Nor is the administrative assistant often not allowed to determine who reviewers and/or approvers are. That prerogative is limited to those in HR (most often). Those workers there set the roles for department managers and higher-ups in the chain. Not the junior assistant (or temp or intern) that is just hired to put numbers in.

            Now what happens here is that there is no limit. Due to ensurePartyRole and it being called as an eca service associated with the createBudgetRole service even the undesirable party-role combinations with get persisted as PartyRole records automatically. 

            Now, one could say: fool me shame on you (OFBiz in this case), fool me twice shame on me (the user in this case) and it won't happen again that an undesirable combination will be persisted as a PartyRole record. No need for the project to fix this. But from a trustworthy perspective (and those who judge this, CPAs most often as advisors of a business needing to implement a new ERP solution) it is not what we should have.

            IMO, he ensurePartyRole was created to facilitate not following a defined business process for a given domain (who can do what within that business domain, when and how) but rather laziness (not having to switch to party and create the PartyRole record there). As you described in your comment too. There is not even a limit on which user can persist PartyRoles (because  run-as-user is set to 'system').
            That makes establishing an audit trail difficult. Again: making OFBiz less desirable from the audit and operational cost perspective. It may be free, but comes at a higher operational cost: no closed-down procedures: more clean-up, more audit cost.

             

            pierresmits Pierre Smits added a comment - Thank you for your questions, Michael. This is where the logic goes wrong in current situation: with current situation: any Party (including external parties, like a customer, or a lead, etc.) can be selected as the party for the BudgetRole record the selected party can be associated with any RoleType (including those nothing to have to do with the budget, e.g. COMPETITOR) Is such desirable, from an accounting domain's perspective? No, the user should only be permitted to: select one of the RoleTypes that is related to budgets (these are defined in the seed data set), and based on that selection only be allowed to select from the list of applicable PartyRole records that meet the criterium under 1. And why is it undesirable to allow otherwise? Because, budget information is confidential information: only selected parties (within the internal organisation) are allowed to create/edit Budget and related records and to review/approve/reject budgets. And only those identified to audit the books (workers from the CPA) would be regarded as potential reviewers. Department manager (and every person higher up in the hierarchy) are required to budget for stuff. More often than not, these parties don't do this online, but work with spreadsheets. And often they don't actually do this themselves, but delegate such task to a trusted delegate within the party. They review and approve/reject what their delegates has concocted. And when these managers approve of what their delegates has delivered, they send it to their appropriate counterpart in the accounting department (the administrator, or financial controller, or CFO). Who hands it down the line to someone who is allowed (the administration assistant) to create (and if need be edit) the Budget record (and related) in the accounting system (OFBiz accounting, here). The administration assistant, however, is not allowed to approve/reject budgets, so create/edit yes but approve/reject no. Nor is the administrative assistant often not allowed to determine who reviewers and/or approvers are. That prerogative is limited to those in HR (most often). Those workers there set the roles for department managers and higher-ups in the chain. Not the junior assistant (or temp or intern) that is just hired to put numbers in. Now what happens here is that there is no limit. Due to ensurePartyRole and it being called as an eca service associated with the createBudgetRole service even the undesirable party-role combinations with get persisted as PartyRole records automatically.  Now, one could say: fool me shame on you (OFBiz in this case), fool me twice shame on me (the user in this case) and it won't happen again that an undesirable combination will be persisted as a PartyRole record. No need for the project to fix this. But from a trustworthy perspective (and those who judge this, CPAs most often as advisors of a business needing to implement a new ERP solution) it is not what we should have. IMO, he ensurePartyRole was created to facilitate not following a defined business process for a given domain (who can do what within that business domain, when and how) but rather laziness (not having to switch to party and create the PartyRole record there). As you described in your comment too. There is not even a limit on which user can persist PartyRoles (because  run-as-user is set to 'system'). That makes establishing an audit trail difficult. Again: making OFBiz less desirable from the audit and operational cost perspective. It may be free, but comes at a higher operational cost: no closed-down procedures: more clean-up, more audit cost.  
            pierresmits Pierre Smits added a comment -

            In addition to the 'fool me... ' in relation to the ensurePartyRole service, suppose we brush this off as: what is the harm (apart from the removal of undesirable PartyRole records in part)?

            Suppose in some other <object>Role screen there is indeed a tighter process to select the party in a particular role for that object (but doesn't invoke ensurePartyRole). Now, the user there can select the improbable party-role combination and persist that as the <object>Role record. And the PartyRole record can't be deleted (referential integrity). And the underlying activity (consider picking/packing) won't get done in time. And clean-up there must take place there too. Otherwise it could/would happen again.

            pierresmits Pierre Smits added a comment - In addition to the 'fool me... ' in relation to the ensurePartyRole service, suppose we brush this off as: what is the harm (apart from the removal of undesirable PartyRole records in part)? Suppose in some other <object>Role screen there is indeed a tighter process to select the party in a particular role for that object (but doesn't invoke ensurePartyRole). Now, the user there can select the improbable party-role combination and persist that as the <object>Role record. And the PartyRole record can't be deleted (referential integrity). And the underlying activity (consider picking/packing) won't get done in time. And clean-up there must take place there too. Otherwise it could/would happen again.

            There are pros and cons, or rather scenarios that are facilitated by one approach and made more difficult by the other, to both ways of interpreting PartyRole records.

            The current approach, implemented in many ootb applications, as mbrohl has pointed out, is to interpret the PartyRole records as all the roles the party actually plays.

            The other approach, that is the one advocated by pierresmits, is to interpret the PartyRole records as the roles the party can play.

             

            jacopoc Jacopo Cappellato added a comment - There are pros and cons, or rather scenarios that are facilitated by one approach and made more difficult by the other, to both ways of interpreting PartyRole records. The current approach, implemented in many ootb applications, as mbrohl has pointed out, is to interpret the PartyRole records as all the roles the party actually plays . The other approach, that is the one advocated by pierresmits , is to interpret the PartyRole records as the roles the party can play .  
            pierresmits Pierre Smits added a comment -

            Grazie Jacopo,

            While I don't know what the many ootb applications are, I would love to see a list of examples of those (not here, but rather in a (new) discussion thread on dev or even in a page in Confluence to see their interpretations). And I guess many more in the community would welcome that to get to an informed opinion.

            IMO, the two approaches across the spectrum are closer than you might think (from a business perspective at least).

            Also, we should take this to dev. I just saw Jacques repeating an entire section of another thread in OFBIZ-5980 pertaining to the same subject. Otherwise this ticket gets dilutes so much that everybody will have trouble making sense of it.

            pierresmits Pierre Smits added a comment - Grazie Jacopo, While I don't know what the many ootb applications are, I would love to see a list of examples of those (not here, but rather in a (new) discussion thread on dev or even in a page in Confluence to see their interpretations). And I guess many more in the community would welcome that to get to an informed opinion. IMO, the two approaches across the spectrum are closer than you might think (from a business perspective at least). Also, we should take this to dev. I just saw Jacques repeating an entire section of another thread in OFBIZ-5980 pertaining to the same subject. Otherwise this ticket gets dilutes so much that everybody will have trouble making sense of it.

            People

              pierresmits Pierre Smits
              pierresmits Pierre Smits
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

                Created:
                Updated: