collective / collective.roster Goto Github PK

...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.

Working on it during PLOG 2019 in Sorrento

https://github.com/collective/collective.roster/blob/master/src/collective/roster/behaviors/groups.py#L82

why is the token derived from group (which is a tuple ) instead of normalizing the title or the id?

i use "id_from_normalized_groupname | groupname" for the roster groups.

on testing the value of the checkboxes are value="normalized_groupname-normalized_groupname" which is redundant... and somewhat hard to test...

wouldn't it be nicer to just normalize the title (the second part of the group tuple) for the token or use the plain id (first part of tuple)?

i wouldn't mind, spending that time, if there are no problems i don't see.

regards, iham

I've to installed the add-on. It works i can create persons, groups and so on..
But the problem comes when i try to put the content accesible. If create a roster on the root of the site it doesn't appear in the main menu, if put it inside a folder i can't select it as a default view for that folder. Maybe i'm doing something wrong or i need to add some behavior to the roster content type to deal with that issue.

Traceback (innermost last):
  Module ZPublisher.Publish, line 138, in publish
  Module ZPublisher.mapply, line 77, in mapply
  Module ZPublisher.Publish, line 48, in call_object
  Module Products.CMFCore.FSPythonScript, line 127, in __call__
  Module Shared.DC.Scripts.Bindings, line 322, in __call__
  Module Shared.DC.Scripts.Bindings, line 359, in _bindAndExec
  Module Products.PythonScripts.PythonScript, line 344, in _exec
  Module script, line 11, in prefs_reinstallProducts
   - <FSPythonScript at /my/site/portal_quickinstaller/prefs_reinstallProducts>
   - Line 11
  Module Products.CMFPlone.QuickInstallerTool, line 100, in upgradeProduct
  Module Products.GenericSetup.upgrade, line 194, in doStep
  Module Products.GenericSetup.tool, line 349, in runImportStepFromProfile
  Module Products.GenericSetup.tool, line 1226, in _doRunImportStep
   - __traceback_info__: plone.app.registry
  Module plone.app.registry.exportimport.handler, line 49, in importRegistry
  Module plone.app.registry.exportimport.handler, line 94, in importDocument
  Module plone.app.registry.exportimport.handler, line 281, in importRecords
  Module zope.dottedname.resolve, line 38, in resolve
ImportError: No module named IBundleRegistry

Obviously the step itself (added in 07ac100) is Plone 5 specific, but this product still supports 4.3, right? Probably this step should be flagged as "only for Plone 5" so the control panel doesn't keep prompting me to do an upgrade which will fail.

I guess a corner case is if this is fixed like this (so the 16/17 step is ignored in Plone 4), but I later upgrade the site to Plone 5, would I need to manually run the step afterwards?

making the title field read only and use it to display a combination of last_name, first_name and position is a really elegant solution!

but ... i do get confused by the way it is implemented:
https://github.com/collective/collective.roster/blob/master/src/collective/roster/person.py

i don't any bit of code there.
i mean ... i do. but it doesn't make sense to me.
especially setting the title twice (combine last_name and first_name and in a second step add a position AND translating those strings. (the translating-thingy puzzles me completely)

i would:

1. remove the subscribers for object create/update and the adapter PersonNameFromTitle
2. make the IPerson schema a behavior instead of being "only" a schema
3. add a factory to that behavior
4. that factory implements a title setter and stores "last_name first_name, position" (by using that method, it will also index correctly without subscribers)

any suggestions or traps to know?

If I try to set a short number [telephone] I get a not valid message.

3 letters short numbers a quite common in European offices :)

plone.app.referenceablebehavior is not a dependency in collective roster, but uses it. why?

no big deal to change that, i guess, so i'd volunteer ;)

@hvelarde Could you please enable Travis-CI for me when you are online? Thanks a lot, again :)

#15 Add support for Python 3. For Plone 6 we must update IObjectEvent location from zope.component.interfaces to zope.interface.interfaces