[MGNLPN-554] Trait resolver should be able to handle multiple traits combinations Created: 02/Jul/21  Updated: 26/Aug/22

Status: Open
Project: Magnolia Personalization
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Neutral
Reporter: Christoph Meier Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Date of First Response:
Epic Link: AuthorX improvements
Team: AuthorX

 Description   

Context

I discovered the "issue"  while creating integration tests for the new feature "Headless p13n via rest" (see MGNLPN-550), for this scenario:

Personalized endpoint delivers a page variant based on multiple traits country plus cookie.

Expected behaviour

When choosing the audience for a variant, we can add multiple traits. In consequence the assumption is, that the trait resolver takes combinations of traits into consideration.

Example

A page has 4 variants:

  • variant-0: trait-country = CH
  • variant-1: trait-country = US
  • variant-2: trait-cookies=weatherLocation_Basel
  • variant-3: trait-country = CH & trait-cookies=weatherLocation_Basel

When requesting the resources with trait-country=CH&trait-cookies=weatherLocality_Basel
I would expect the trait resolver to return variant-3.

Current behaviour

The trait resolver returns the variant with the first trait which matches.
From the given example above, it returns variant-0.

I could change the order of the variants, swapping the positions of current v-0 and v-3 - this then would return new v-0 - as expected. But the order of the variants should not affect the result returned by the trait resolver.

Additional notes

The traits are resolved as explained above not only on the new / upgraded delivery endpoint - but that's how traits are resolved generally so far.

When discussing the problem jsimak told me that rkovarik told him, that this is a "known issue", or in other words, it was a intentional decision to implement as it is now. (Taking trait combinations would require much more resources.)

I report this as discussed with PM of headless team czimmermann



 Comments   
Comment by Christopher Zimmermann [ 05/Jul/21 ]

I think this expectation makes sense.

jsimak would there be performance implications for this?

An alternatvive would be to improve the UI to make it more clear how the resolution works, and also to facilitate reordering of variants.

There could even be a tip if you put a more specific trait variant at the bottom of the stack.

Generated at Mon Feb 12 06:38:47 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.