This is an old revision of the document!


How to handle elements in LOST+FOUND

Root cause for LOST+FOUND

If an element is removed, but other objects - e.g. elements, files, user assignments - for which Stages did not receive an explicit order to delete, are dependent on that element. Those elements are moved to LOST+FOUND to prevent them from being deleted.

All cases listed below are variations of this core problem.

1. LOST + FOUND after the release of a new valid version

Case 1.1: A work product with a linked file is deleted

Example:

  • Create a work product WP1 with a link (or upload a file, or connect to a file in a CMS)
  • Create a version V1 and set it to valid
  • Delete WP1 in the working version
  • Create a V2 and set it to valid

–> LOST+FOUND folder is created for WP1 so that the link is not lost

Case 1.2: A role with a user assignment is deleted

Proceed like in Case 1.1, only in this case use a role and assign a user.

→ User assignment and therefore maybe access rights would be lost if the role was deleted.

2. LOST + FOUND while using modules

Case 2.1: Imported project data/guidance files

Integrate V1 in Case 1.1 or Case 1.2 in process, make an update with V2 → LOST+FOUND in the integrated process

Case 2.2: Local project data /guidance files

Project data is added locally in the integrated process for elements imported with a module. If those module elements are deleted with an update of the module OR the module is removed completely → LOST + FOUND

Case 2.3: Local sub-elements

Sub-elements are locally added in the integrated process for elements imported with a module. If those module elements are deleted with an update of the module OR the module is removed completely → LOST + FOUND

Case 2.3b: Elements are moved to another location which is then deleted with a module update/removal

If you move an element from module A under an element from module B and that element is deleted because of a module update/removal → LOST + FOUND

Case 2.4a: Using a “structural module” in different versions

If the structure module is integrated with different versions, it might happen that in the version that is imported last, some elements are missing.

E.g. V2 includes an element FolderXYZ, that didn’t exist yet in V1 but is used in Process 2. If Process 1 is updated/imported after Process 2, FolderXYZ will land in LOST+FOUND.

→If you use a common elements module (for structure, tailoring, etc.) which is imported into process modules, that are in turn integrated together somewhere else, always make sure that only process modules are integrated there that include the same version of the common elements module

Case 2.4.b: Common elements imported in different versions with different element identities

Should be a rare case, but if it happens it might be difficult to detect. It is a variation of Case 2.4.

It can happen that the elements in the common elements module get new identities.

For example,

if they were deleted and created again with the same name

if they were imported by an importer that always creates new identities.

other reasons for new identities :question_mark:

At first glance, they look the same because they have the same name, but because of the different identities they are different objects for Stages

Case 2.4.c: On-demand problems

If you use common elements with on-demand import, it might happen that with that on-demand import a folder element (or other parent element) is imported in module A.

At some point maybe, it is decided that the on-demand element is no longer needed in module A, and therefore also the folder element is deleted.

If this folder element is also needed for other on-demand elements from other modules in the integrated workspace AND if module A was the last module that was imported/updated in the integrated workspace AND is now updated again without that folder element, Stages thinks it needs to delete it but pushes it in LOST + FOUND instead, because it has sub-elements from other modules.