Int field that works with both c.collectionfilter and plone.app.querystring

1

I have an int-field (priority: 1–5)

This does not work with collective.collectionfilter
If I add an indexer and saves it to the index as string, it works with collective.collectionfilter.
But, then it does not work with plone.app.querystring (int.largerThan and .lessThan

Is there a 'good' workaround for this. My current approach is to have two indexes and and another (hidden) field, since c.collectionfilter needs both the field and an index with the same name

2

There is a global INTEGER_IDXS in collective.collectionfilter.vocabularies which you could patch in your package and add your index id to it.

Thinking about this, collectionfilter could be more automagic and look at the index type to know if its an integer index -> issue Determine index type `int` automatically. · Issue #199 · collective/collective.collectionfilter · GitHub

3

Ops ... there is no IntegerIndex ... aha, thats why there's the global.
plone.app.querystring defines the IQueryOperations in the registry and maps them to the indexes. This would be the prefered solution for collectionfilter too, to add a registry field with "integer_indexes"

4

When I tried to work around this problem, it looks like the catalog index became 'ints' if my field was int. If I remember right, this is what happened:

  1. I made a field (type 'int') and a FieldIndex, did not work with collective.collectionfilter
  2. I made a field (type 'string') and a FieldIndex and a Field index and added an item with value '1'. Then I changed the type of the field to 'int', added another content item. It would produce an error 'can not convert int to string' or something similar.

Could there be a way to check a (Field) index to see if it 'is int' ?

5

So the best approach would be if Plone/Zope had an 'IntegerIndex' (a bit similar to the BoolIndex), not just 'FieldIndex'

That is almost 'more of a hack' than having two indexes for the same field (?)

6

I'd say its a feature of collectionfilter, that you can define indexes, which should be handled as "int" value holders. See https://github.com/collective/collective.collectionfilter/blob/main/src/collective/collectionfilter/vocabularies.py#L160 ... this gives you the ability to not clutter your catalog with unneeded indexes and columns. It could be more convenient for intergrators though if it would be defined in the configuration registry rather than a global in the module.

p.a.querystring has some similar strategy for the operations on objPositionInParent . See https://github.com/plone/plone.app.querystring/blob/master/plone/app/querystring/profiles/default/registry.xml#L599-L601

7

I have added the 'int field' to registry settings and made an update profile. I am not 100% sure about the update profile.

Should I make a pull request?

PS: Maybe I should add others, too?

INTEGER_IDX
GEOLOC_IDX
GROUPBY_BLACKLIST
DEFAULT_FILTER_TYPE

8

Cool! PR would be great, but if you don't mind, instead of forking the report, please create the branch directly on the collective organization, so others can collaborate better with your changes. If PR created, feel free to add me as reviewer.