You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Collections call view @@qsOptions for the query field options. That view is defined in plone.app.content, but it delegates all work to QuerystringRegistryReader in plone.app.querystring. Registry reader "simply" dumps configuration for all queryable fields and operations (both enabled and disabled), including all distinct values for related vocabularies. For sites with a lot of editors, vocabulary for Creator field may become large (and all values are twice in the resulting JSON, once for all indexes and once for sortable indexes). Yet, if the sites is using LDAP (tested only with LDAPUserFolder), rendering @@qsOptions requires fetching full name for all users, who have created content in the site. With some bad luck with the current LDAPUserFolder caches, this may choke a single instance site for a while.
I don't see any obvious fix for this. Comments and ideas are welcome.
The text was updated successfully, but these errors were encountered:
Update the second default value of registry field plone.app.querystring.field.Creator.operations to plone.app.querystring.operation.string.is instead ofplone.app.querystring.operation.selection.any (can be done TTW)
Delete registry record plone.app.querystring.field.Creator.vocabulary (cannot be done TTW)
This replaces the nice selection widget for Creator criterion with a dummy string field.
Collections call view
@@qsOptions
for the query field options. That view is defined inplone.app.content
, but it delegates all work to QuerystringRegistryReader inplone.app.querystring
. Registry reader "simply" dumps configuration for all queryable fields and operations (both enabled and disabled), including all distinct values for related vocabularies. For sites with a lot of editors, vocabulary for Creator field may become large (and all values are twice in the resulting JSON, once for all indexes and once for sortable indexes). Yet, if the sites is using LDAP (tested only with LDAPUserFolder), rendering@@qsOptions
requires fetching full name for all users, who have created content in the site. With some bad luck with the current LDAPUserFolder caches, this may choke a single instance site for a while.I don't see any obvious fix for this. Comments and ideas are welcome.
The text was updated successfully, but these errors were encountered: