FieldIndex does not update when field updated to be empty value

Plone Support Add-on Development
1

We have a content type with this field as part of its schema in a 5.2 site

pmid = schema.TextLine(
    title=_("PubMed ID"),
    default='',
    required=False,
)

And then a simple FieldIndex of the same name added to the portal_catalog. There is no custom indexer for this index nor any special processing by the form handler; it is very vanilla. The problem is that if this field is emptied TTP on a form and saved, the old value remains for the "pmid" index.

Doing some debugging, there is new (to 5.2) behavior used in Products.ZCatalog by the base class used for most indexes: https://github.com/zopefoundation/Products.ZCatalog/blob/5.0.1/src/Products/PluginIndexes/unindex.py#L253. When clearing this field TTP, Dexterity sets this value to None and this condition causes this index to do nothing. If this were a new object being indexed that would be fine, but it seems like a bug that this does not update the existing index. If it can't index a value of None, shouldn't it attempt to unindex if it finds old data?

There are potential workarounds in the form of creating custom indexers or even a change to plone.indexer, but addressing the issue in Products.ZCatalog seems the better move. I have attempted to test this in an otherwise vanilla Plone/Zope environment but please let me know if this problem is not reproduceable in a 5.2 env.

2

Isn‘t there a flag for indexes to ignore None or not?

3

A bug in dexterity (maybe zope.schema): as you have defined the field default as '', the field value should never be None (which means unset) but instead get the default value.

A bug in Unindex: it should interpret a None value as: there is no index value for this object and update the index appropriately; it must not interpret None as "do nothing".

4

@zopyx I'm not sure what you are referring to, where is this setting?

@dieter When it's not clear that a specific package is to blame I tend to make a report in CMFPlone, is this the right procedure? I want to make sure any report is well targeted, but with so many interconnected parts it sometimes seems to require a higher level moderator to determine which should address it.

5

Somewhere...can not recall..but there was something related, somehow, somewhere...sorry

6

This is indeed the recommended procedure.

However, you might more quickly get a solution when
you target a problem report directly to the respective package
(provided you know this package).