Check objects only indexed since last alarm run.

bt5/erp5_administration/SkinTemplateItem/portal_skins/erp5_administration/Alarm_activateCheckConsistency.xml

@@ -50,12 +50,20 @@
         </item>
         <item>
             <key> <string>_body</string> </key>
-            <value> <string>active_process = context.newActiveProcess().getRelativeUrl()\n
+            <value> <string encoding="cdata"><![CDATA[
+
+kw = {}\n
+\n
+last_active_process = context.getLastActiveProcess()\n
+\n
+if last_active_process is not None:\n
+  kw[\'indexation_timestamp\'] = \'>= %s\' % last_active_process.getStartDate().ISO()\n
+\n
+active_process = context.newActiveProcess().getRelativeUrl()\n
 query_string = context.getProperty(\'catalog_query_string\', \'\')\n
 # the query sould be something like "validation_state:!=deleted validation_state:!=draft portal_type:Organisation" etc\n
 portal = context.getPortalObject()\n
 \n
-kw = {}\n
 \n
 if query_string is not None:\n
   kw.update(SearchableText=query_string)\n
@@ -63,7 +71,9 @@ if query_string is not None:\n
 kw.update(parent_uid=[portal.restrictedTraverse(module).getUid() for module in context.getProperty(\'module_list\') or []])\n
 \n
 portal.portal_catalog.searchAndActivate(method_id=\'Base_checkAlarmConsistency\', method_kw={\'fixit\': fixit, \'active_process\': active_process}, activate_kw={\'tag\':tag}, **kw)\n
-</string> </value>
+
+
+]]></string> </value>
         </item>
         <item>
             <key> <string>_params</string> </key>

bt5/erp5_administration/bt/revision

-141
+142
\ No newline at end of file

[Jérome Perrin]

@luke do you remember if there was a strong reason to choose indexation_timestamp and not modification_date here ?

I feel they are more or less equivalent, except cases where some documents consistency would depend on others documents.

On example I could think of would be sale order lines would have a constraint "source must be defined" and source is acquired from parent sale order ? so probably it's better to use indexation timestamp and not modification date.

I came with this question with !537 (merged) because I noticed timestamp in mysql is converted to "connection timezone" according to http://www.mysqltutorial.org/mysql-timestamp.aspx . Apparently we never set it so it seems UTC. Since catalog also convert dates in query to UTC , it should work (with the changes from !537 (merged) )

[Łukasz Nowak]

indexation_timestamp was chosen, because information in catalog can change without modification of the object, so modification_date would be wrong check. The sale order example seems the case for indexation_timestamp.

[Jérome Perrin]

Thanks, like for example when an interaction would just call a setter and not use edit workflow... that makes sense.