erp5_core: setup a random id generator on portal_callable

If one callable has the default ID '1', it will break nearly all newContent calls on empty object

product/ERP5/bootstrap/erp5_core/ToolTemplateItem/portal_callables.xml

@@ -249,14 +249,38 @@
               <persistent> <string encoding="base64">AAAAAAAAAAQ=</string> </persistent>
             </value>
         </item>
+        <item>
+            <key> <string>categories</string> </key>
+            <value>
+              <tuple/>
+            </value>
+        </item>
+        <item>
+            <key> <string>description</string> </key>
+            <value>
+              <none/>
+            </value>
+        </item>
         <item>
             <key> <string>id</string> </key>
             <value> <string>portal_callables</string> </value>
         </item>
+        <item>
+            <key> <string>id_generator</string> </key>
+            <value> <string>_generatePerDayId</string> </value>
+        </item>
+        <item>
+            <key> <string>id_group</string> </key>
+            <value> <string>None</string> </value>
+        </item>
         <item>
             <key> <string>portal_type</string> </key>
             <value> <string>Callable Tool</string> </value>
         </item>
+        <item>
+            <key> <string>short_title</string> </key>
+            <value> <string>None</string> </value>
+        </item>
       </dictionary>
     </pickle>
   </record>

[Vincent Pelletier]

If one callable has the default ID '1', it will break nearly all newContent calls on empty object

Independently of the IMHO good thing of using just any id generator other than the (sadly still default) sequential document id generator, I think this is an implementation bug in newContent (or whatever is accessing the id "1" during newContent): such action should likely never be given a chance to acquire. The faulty access is likely currently implemented as some __getattr__ call, which should be changed to anything which does not acquire: __getitem__ and _getOb come to mind. Depending on how the result is used, __contains__ may be even better (I do not expect newContent to do anything at all with existing subobjects, besides detecting their presence, so fetching them itself seems pointless).