Feature Discussions

[king]

FirstSpirit generated links become invalid after:

- export/import

- move actions of editors within the same FirstSpirit project

- when FirstSpirit content is moved from one project to the other

The current situation:

• FirstSpirit does not offer a core functionality to guarantee consistent links for the following link-types:
  1. Publishing-Links (pointing to the live-system, that delivers FirstSpirit-generated content)
  2. Portal-Links - links pointing on start- and loose pages provided in a portal framework (like SAP Netweaver)
  3. KMC-Portal-Links (see above)
• Using these links in external documents (like PDFs, DOCs, PPTs, etc.) or applications (like browser bookmarks) is not practicable, because these links become invalid when:
  • objects (medias and page-references) are moved within the FirstSpirit editor system (e.g.: from one part of a tree to another one)
  • projects are exported and imported from one FirstSpirit- to another FirstSpirit-server
• The consequence:  
  • huge manuel effort to guarantee that links are updated in all external documents/applications -> costs

Technical part:

• Links might be generated in two ways, basiclly (shown here for the first mentioned link type "Portal-Links" within the FirstSpirit "fs-portal.fsm" module configuration dialog box):
  
  1. using a numeric ID value (FirstSpirit assigned sequential ID for the object)
     • Example link: https://xxx.domain.tld/irj/portal/anonymous/?NavigationTarget=HLPFS://542033/542034/542035/542036/542037&
       NavigationContext=HLPFS://542033/542034/542035/542036/542037
  2. alphanumeric UID value (FirstSpirit assigned UID for the object)

  • Example link: https://xxx.domain.tld/irj/portal/?NavigationTarget=HLPFS://wcms_c_Bosch_20GlobalNet/wcms_c_BGN/wcms_c_02_20Organization/wcms_c_Board_of_Management/wcms_c_Board_of_Management&
    NavigationContext=HLPFS://wcms_c_Bosch_20GlobalNet/wcms_c_BGN/wcms_c_02_20Organization/wcms_c_Board_of_Management

• The core problems:

1. when using the numeric ID solution:  
   • FirstSpirit-IDs and their combination used in the above example link change when:  
     • Media/Page is moved to another part of the tree by the editor (path of FirstSpirit-IDs change due to the change path within the FirstSpirit tree)
     • FirstSpirit-Project containg this media/page is ex-/imported on another FirstSpirit server (FirstSpirit automatically generates new FirstSpirit IDs for each object when importing it)
2. when using the alphanumeric UID solution:  
   • FirstSpirit-UIDs and their combination used in the above example link change when:  
     • editors change the UID name of the object (this could be done since FirstSpirit 4.2)
     • editors move objects (media/pagerefs) from one part of the tree to another one (due to the move of the object, the UID-path within the link will change, too)
     • UIDs are not unique project-global, just within a project and only within a store-type (e.g. the site store). It might be possible, that the same UIDs are used within the page- and sitestore as well
   • Possible inconsistencies:  
     • when an object is deleted, its UID name is given back to the FirstSpirt UID-pool, that the system uses to automatically assign UID names to new objects
     • when creating a new object, this object might be assigned the UID that formerly belonged the deleted object (so the bookmarked link potentially points to a resource that is totally different to the one that has been deleted)
     • renaming of FirstSpirit projects is impossible - due to the FirstSpirit project name prefix being used to unify the reference names used on the server

• Solution suggestion:
• 1. integration of a new BerkeleyDB attribute for each object that guarantees the following mandatory criterias: 
     • immutable against editor changes like moving of objects in other tree-parts
     • project-locally and globally unique
     • export-/import stable
     • invisible for editors (to prevent changes) -> system attribute character
  2. removing the path notation to build the links
  3. providing a configurable option to use this attribute to build the links

[MichaelaReydt]

Hello Holger

thank you for your idea to improve FirstSpirit. It is important for us to learn from the experiences of our customers and partners. For this reason we appreciate feedback and any suggestion.

We have evaluated the issue once again, but have no plans for a realisation in the near future. Therefore, we can not consider your feature request at this time.

Best regards,

Michaela