Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix BPNL Group Validation for a Policy with a Collection as a rightOperand #1674

Open
bmg13 opened this issue Nov 11, 2024 · 0 comments
Open
Labels
bug Something isn't working triage all new issues awaiting classification

Comments

@bmg13
Copy link
Contributor

bmg13 commented Nov 11, 2024

Describe the bug

According to the documentation, for creating a Policy with a constraint to match if the groups a BPNL is assigned are allowed to fetch the respective catalog, the rightOperand should be something similar to the following

"constraint": 
{
	"leftOperand": "tx:BusinessPartnerGroup",
	"operator": "isAllOf",
	"rightOperand": ["some-group-1", "some-group-2"]
}

However this implementation does not seem to be working properly, since the expanded value is the one being use for comparison instead of "simplified" values, but only seen when more than one entry in the collection is verified.

To Reproduce

So, using the example above, a BPNL assigned to the groups "some-group-1" and "some-group-2" would not pass the evaluation, however it should.
Simply creating a Policy with above constraint and ensure a testing BPNL is assigned to the aforementioned groups and try to see it pass the validation by requesting the Catalog (after Asset and Contract Definition are created).

Expected behavior

Since the BPNL is assigned to the groups explicit in the Policy constraint, then it should be able to see the full Catalog.

Context Information

After analysis, it is confirmed the match of ["some-group-1", "some-group-2] is done against the next:

"{@value={valueType=STRING, chars=some-group-1, string=some-group-1}}"
"{@value={valueType=STRING, chars=some-group-2, string=some-group-2}}"

Which will always fail since the Strings are different.

This may be due to this inference for a Collection. Here the instance type for the Collection is kept as Generic and the input of a JsonObject invalidates a direct conversion to String.

Important note:
As seen here, the comma-separated single String (instead of Collection) does not seem to be affected by this behaviour.

Possible Implementation

Three possible approaches:

  • Remove the availability of a Collection input, only allowing the comma-separated (single) String and update the documentation accordingly;
  • Fix the parsing of the input Collection to avoid the comparison of the expanded Strings. This would be a workaround done in BusinessPartnerGroupFunction to expose a collection with groups and not expanded view. This solution would not prevent expanded view on fetching catalog.
  • Fix in Upstream the parsing of the rightOperand (in here) to ensure the data consistency throughout.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working triage all new issues awaiting classification
Projects
None yet
Development

No branches or pull requests

1 participant