Issue 45634: Naming Patterns: failing to resolve lineage lookup data cross-folder

issues
Status:resolved
Assigned To:ChrisJ
Type:Defect
Area:Data
Priority:3
Milestone:22.08
Opened:2022-06-07 09:01 by mohara
Changed:2022-07-15 10:35 by Rob Morphew
Resolved:2022-06-16 16:54 by Nick Kerr
Resolution:Fixed
Support Ticket: 
Pull Requests:platform#3448
Closed:
2022-06-07 09:01 mohara
Title»Biologics using subfolders: Naming pattern can't use syntax like ${DataInputs/CellLine/Name} - parent name does not resolve
Assigned To»triage
Notify»Bernie
Type»Defect
Priority»3
Milestone»22.07
In a Biologics project using subfolders, the following naming pattern syntax validates correctly, but can't generate names for samples derived from a data class:
H-${DataInputs/CellLine/Name}-${now:date}-${dailySampleCount}

but this does (and uses the name as expected)
H-${DataInputs/CellLine}-${now:date}-${dailySampleCount}

Error raised for the first pattern is "Unable to find parent [ParentName]" and the console shows a 400 error

Note that the first/expected pattern with /Name works fine in LKSM using a source and in a 'flat' biologics project (no subfolders/shared definitions)

Repro:
1. In a biologics project with subfolders and data, such as https://learn.labkey.com/BiologicsMultiVerse/Project%20Alpha/biologics-app.view#/samples/Samples
2. edit a sample type naming pattern to try to use the first pattern
3. create new samples from a cell line - should name them with the cell line name, but instead error is thrown.

2022-06-08 17:04 Bernie
Assigned Totriage»Nick Kerr
Hey Nick,
Is this expected behavior? If not, can you please estimate?
Thanks,
Bernie

2022-06-15 14:08 Nick Kerr
TitleBiologics using subfolders: Naming pattern can't use syntax like ${DataInputs/CellLine/Name} - parent name does not resolve»Naming Patterns: failing to resolve lineage lookup data cross-folder
Area»Data
Pull Requests»https://github.com/LabKey/platform/pull/3448
I've addressed this by passing through the target "data" container to the name generator. Currently, we do a mishmash of sometimes receiving the data container and other times receiving the container where the data type is defined. Additionally, this also updates Data Classes to be able to support lineage lookups and account for the scenario outlined here.

There is also an adjacent scenario where lineage lookup values in name expressions were failing cross-folder for non "built-in" columns specified on a data class domain. The reason for this failure is that the ExpData objects were not resolving their associated ExpDataClass due to not being provided with a user. As such, the NameGenerator would fail to resolve any properties for cross-folder data types.

Repro:

1. Create a Data Class a top-level folder named "PeanutButters" with a required text column called "Texture".
2. Create a subfolder of the top-level folder.
3. Add a row of data into the top-level folder (say "Smooth") and add a row of data into the subfolder (say "Chunky") giving "Texture" a different value in each row.
4. Create a second Data Class in the top-level folder named "Sandwiches" with a name expression `${DataInputs/PeanutButters/Texture}-${genId}`.
5. Insert a row of data into "Sandwiches" in the subfolder that references the "PeanutButters" row defined in the top-level folder. It succeeds.
6. Insert a row of data into "Sandwiches" in the subfolder that references the "PeanutButters" row defined in the subfolder.

Expect: Inserts a new row successfully when referencing cross-folder data types with data that is in a subfolder.
Actual: Receive an error that the name could not be generated.

2022-06-16 16:54 Nick Kerr
resolve as Fixed
Statusopen»resolved
Assigned ToNick Kerr»ChrisJ
This has been merged to develop and the fix will be available in v22.07. Reassigning to Chris for addition of automated regression coverage.

2022-07-15 10:35 Rob Morphew
Milestone22.07»22.08