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.
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.