[MGNLPN-561] Treat depth of variants to be the same as depth of original node when getting all personalized variants from REST Created: 21/Jul/21  Updated: 21/Sep/21  Resolved: 19/Aug/21

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

Type: Bug Priority: Neutral
Reporter: Jaroslav Simak Assignee: Jaroslav Simak
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: 0.25d
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)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:
Epic Link: Headless p13n
Sprint: HL & LD 35
Story Points: 3

 Description   

Scenario 1:

  • Delivery API defined with depth 0
  • Page A with variants X, Y
  • User requests A with ?variants=all parameter included in the request
  • API returns only page A

Scenario 2:

  • Delivery API defined with depth 2
  • Page A with variants X, Y
  • User requests A with ?variants=all parameter included in the request
  • API returns page A and variants X, Y**
  • That happens because variant depth is always depth of A + 2

Question: Should API return variant pages in scenario 1?



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

Hah - good question! Hmmm...

I think a developer would and should not have to think of a variant as being a child (grandchild), its a different concept - its a variant of the current item. For example in scenario where I do not add ?variants=all, I will sometimes get a variant returned, also with depth=0.

Another point:
Depth parameter is used to get known children like subpages, areas, components and the like. So I may specifically want only depth 1, but still want to be able to get variants of the page.

Comment by Christopher Zimmermann [ 07/Aug/21 ]

jsimak Is the above making sense and acceptable? Does something in the functionality need to be changed based on that? Is this to be done in scope of this ticket or another one?

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