[MAGNOLIA-6381] HierarchicalUserManager incorrectly stores users with one and two letter user names Created: 17/Sep/15  Updated: 18/Nov/16  Resolved: 17/Nov/16

Status: Closed
Project: Magnolia
Component/s: None
Affects Version/s: 5.3.11, 5.4.2, 5.5
Fix Version/s: 5.5.1

Type: Bug Priority: Critical
Reporter: Antonín Juran Assignee: Ngoc Nguyenthanh
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0d
Time Spent: 1d 0.5h
Original Estimate: 3d

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:
Sprint: Saigon 70
Story Points: 5

 Description   

User with one-letter name eg. A, created in PUBLIC USER sub app in SECURITY app is placed on the top level of tree hierarchy. User named with two letter username. eg. AA is placed on the top level of tree hierarchy too. Subsequently created user with the user name AAA is placed in AA folder under the user A.



 Comments   
Comment by Mikaël Geljić [ 07/Nov/16 ]

Dumping few thoughts here first:

  1. Needs a proposal first where those should end up (at least the one-letters; two-letters otoh are well defined, bug?)
    • needs to prevent collisions (speaks against right-padding with some character)
    • something like /a/a0/a coud possibly do
    • likely needs to tune lookup and uniqueness checks to dig into the right place
  2. Alternatively or complementarily, should we allow one-letter user names at all? two-letter user names?

Update:

  • we tentatively store single-letter users "one level up", e.g. mgnl:user "j" at path /j/j
    • i.e. on same level as mgnl:folders "ja", "jb", "jc"...
    • can't think of any depth-base rationale against it; hopefully it doesn't make ACL "sync" operations more complex either (say upon renames/copies etc.)
  • we make sure HUM behaves consistently re: lookup, uniqueness checks resp. storing, updating.
  • those ops need to be node-type aware; based on the issue description, they might not be atm (storing users beneath users; which could also be further prevented with node-type defs, but different story)
Generated at Mon Feb 12 04:13:59 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.