Roster objects have absolute path in UID catalog, which causes import error

[adaugherity]

...at least, I think that's what's causing it. After having trouble importing a Plone site to another server, I found that the problematic objects were Roster and/or Person objects, and when browsing the UID catalog, they were the only objects with absolute paths.

Example from a brand new Plone site with a roster and a couple people added:

>>> for obj in site.uid_catalog():
...   print obj.getPath()
...
/test/Plone-roster/roster
/test/Plone-roster/roster/doe-john
/test/Plone-roster/roster/roe-jane
front-page
news
news/aggregator
events
events/aggregator
Members

Note that all paths are relative, except the roster stuff, which has absolute paths.

If I rename the site via the ZMI, these paths do not change, and furthermore, if I then update the UID Catalog, the objects disappear entirely. Likewise, if I export a Roster object or a folder containing one and import it into another site, these objects are not listed in the UID catalog (everything appears to still work, but this is a bit disconcerting...).

The more serious issue is when exporting/importing a whole Plone site into a different path on another server, or into a different ZODB mount on the same server (we have a separate mount for each site). I can reproduce this 100% as follows:

1. Set up at least two FSes/ZODB mounts (e.g. with collective.recipe.filestorage).
2. Create a Plone site in one of those, e.g. /mount1/Plone-roster, install collective.roster, and add some roster content.
3. Export the site.
4. Delete the original site.
5. Attempt to import the site into a different ZODB (e.g. /mount2); it will fail with a KeyError:

   2017-03-27T16:42:38 ERROR Zope.SiteErrorLog 1490650958.80.256670746483 http://zopedev:8080/mount2/manage_importObject
   Traceback (innermost last):
   [ ... ]
   Module zope.component._api, line 136, in subscribers
   Module zope.component.registry, line 321, in subscribers
   Module zope.interface.adapter, line 585, in subscribers
   Module Products.CMFCore.CMFCatalogAware, line 262, in handleContentishEvent
   Module Products.CMFCore.CMFCatalogAware, line 188, in notifyWorkflowCreated
   Module Products.CMFCore.WorkflowTool, line 289, in notifyCreated
   Module Products.CMFCore.WorkflowTool, line 639, in _reindexWorkflowVariables
   Module Products.CMFCore.CMFCatalogAware, line 108, in reindexObjectSecurity
   Module Products.ZCatalog.CatalogBrains, line 74, in _unrestrictedGetObject
   Module OFS.Traversable, line 300, in unrestrictedTraverse
   - __traceback_info__: (['doe-john', 'roster', 'roster_test'], 'Plone-roster')
   KeyError: 'Plone-roster'

   If the original path exists, then the import succeeds, but the UID catalog still shows the old paths, and updating it causes those objects to be removed from the catalog, as described above.

This also holds true if the "original path" is just a hierarchy of folders created in the ZMI (e.g. /mount1/Plone-roster/roster_test/roster) not containing an actual Plone site. I discovered this by creating folders one at a time and seeing the KeyError move down the tree until it disappeared. So in the above error message, the object failing to import is catalogued as /mount1/Plone-roster/roster_test/roster/doe-john, but because /mount1 does exist, it throws the KeyError for /mount1/Plone-roster, which does not.

For some reason, it also succeeds when importing into a different folder path within the same ZODB (but the UID catalog paths are still wrong).

By contrast, with the portal_catalog (which uses absolute paths for everything), rebuilding it updates everything to the correct path, as expected.

I was finally able to move my site to the location I wanted on the target server by first importing it into a mount matching its original path, then with that still existing, importing it into the real target path and re-cataloging. Although as note above, the roster & personnel don't show in the uid_catalog any more, which scares me a bit...

This is on Plone 4.3.11, if that makes a difference vs. Plone 5.

[datakurre]

@adaugherity Could you please re-file this issue into https://github.com/plone/plone.app.referenceablebehavior/issues

It seems, this has been the implemented behavior of uid_catalog indexing in plone.app.referenceablebehavior from the beginning: https://github.com/plone/plone.app.referenceablebehavior/commit/22c6bc3b5ef943a300d6f6d211f15ffb637670ec

About roster. Roster objects need to be in uid_catalog only, if they need to be UID-linkable from Archetypes content (like Documents/Pages in Plone 4). uid_catalog-support is provided by Referenceable behavior, which is enable by default for Roster types. It can be disabled from Dexterity content settings (from behaviors tab of those types).