Hi,
i opened an issue on collective.solr:
but i don't know if this is a c.solr problem or folder_contents action.
Any ideas?
I fixed that with this patch https://github.com/plone/collective.indexing/pull/17 but this patch should be backported, see https://github.com/plone/Products.CMFPlone/issues/2428.
If you have some time to spare on backporting that patch I can give you some hints.
cool!
But i'm still on a 5.1rc2 (i can't use last 5.1.x version because of this bug), so i could use your c.indexing branch..or not? Why i need to backport it?
btw i tried it, and now Plone send only one POST to solr when i change the state of a folder (with some contents inside)..and the result is the same 
Maybe i'm missing something, so yes, give me some hints please
collective.indexing was absorbed in Plone 5.1 and should not be used anymore: https://github.com/plone/Products.CMFPlone/issues/1343
But when doing that the reindexObjectSecurity method was not touched: https://github.com/zopefoundation/Products.CMFCore/blob/45465748a70896875548fd068156dd01d6befb4c/Products/CMFCore/CMFCatalogAware.py#L95
The patch in https://github.com/plone/collective.indexing/pull/17 fixes that for plone < 5.1.
Let me know if this patch works:
from Products.CMFCore.indexing import filterTemporaryItems
from Products.CMFCore.CMFCatalogAware import CMFCatalogAware
def reindexObjectSecurity(self, skip_self=False):
if not filterTemporaryItems(self):
return
if not skip_self:
self.reindexObject(idxs=self._cmf_security_indexes)
def _reindex(obj, path):
obj.reindexObject(idxs=self._cmf_security_indexes)
self.ZopeFindAndApply(self, search_sub=True, apply_func=_reindex)
CMFCatalogAware.reindexObjectSecurity = reindexObjectSecurity
nope 
But collective.solr has a dependency to collective.indexing (so i have it on my buildout), and maybe this cause some conflicts.
I need to try to get rid of it on solr, and do some tests.
Uhm... then I am clueless.
If the problem is what I think it is some code is calling portal_catalog.reindexObject(obj) instead of obj.reindexObject(), see https://github.com/plone/collective.indexing/issues/14 for details.
Are you able to enter into that code with a pdb?
collective.indexing has been merged into the core without making sure collective.solr still works and making the necessary amendments:
If we remove the c.indexing dependency from c.solr, we have a Plone 5.1 only version of c.solr. This is something I would like to avoid because it means lots of backporting and keeping two branches ins sync. We could make a c.indexing release that just points to the Plone 5.1 code and keeps everything else in place...
Running c.solr with Solr 7 also leads to lots of test failures and there are for sure a few things that we need to fix/amend. I am not sure if running Solr 7 with c.solr right now is a good idea.
We might have a client that is willing to sponsor us to make c.solr work with both Plone 5.1 and Solr 7. I am more than open to get together and discuss how we can make this happen.
I was supposed to bring collective.solr to 5.1 while working on the PLIP, sorry about that 
but my second kid was born and... well no time for Plone or anything.
I might have some time in the near future but I can't promise it 
2 Likes
fyi i closed my original issue because i've found a solution.
It wasn't a strictly collective.solr or indexing problem:
solr schema had a required index (id).
When you change review state from folder_contents, a reindexObject(idxs=['review_state']) is fired.
c.solr's index method check if there are all the required indexes in the query, and if not, it doesn't update the solr index.
reindexObject doesn't pass 'id' key, so the index is never updated.
The funny thing is that if i try to update a review state from the toolbar, that method will fire reindexObject() without indexes list, and this will produce an index update in solr because is correctly handled.
My fix was to set id key in solr schema as not required.