otherwise it is acquired from BudgetLine, which is bad because:
- the value of catalog.has_cell_content will be wrong
- hasCellContent is slow and this was called for all cells in a budget line

 * support budget cell's getInventoryQueryDict
 * raise NotImplementedError for budget cell variation. We can't
   implement this unless we generate dynamically a date time field on
   budget line's view.

Still TODO:
 * Test
 * group_by slot_index should not be needed
 * think more about a generic "domain budget variation" ?

TODO: discuss wether this can be an useful addition

We have in ZODB some PropertyGetter as new style classes (there are also
some cases in the XML exports in the repo, search for _dt_reconstructor
)

We no longer use pypdf but use pypdf2, due to some bugs, we have some
pypdf objects in object database, so create a fake module so that we can
load them.

In a prefious version of this patch we have left some
Products.ERP5.NameObject in the database and saving new version of the
docuement (edit) fails with:
PicklingError: Can't pickle <class 'Products.ERP5.NameObject'>:
attribute lookup Products.ERP5.NameObject failed

HACK: disable bank_reconciliation_aggregate_* related keys, since we added these columns directly in stock table for performance

Signed-off-by: Aurélien Calonne <aurel@nexedi.com>

Note that after applying this change it's important to clear preferred timezone
for system preferences, as they have priority over user preferences

This is wrong, I still have to understand how DMS can be used to upload
a file while making sure that if a file with same reference already
exists it is not edited in place but always a new version is created.

Only user action transitions needs permission/role guards.

This workflow is not really related to security

edit method has security definition on the class, gard is not needed
here.
This cause compatibility issues, in the past it was not necessary to
have any permission to call edit from restricted code.

This action is typically used to add notes in history in scripts,
including in cases where user does not have modify portal content
permission on the document.

Wrapping a method in a workflow method should not change the
publishable state the method.
If the original method is not publishable, wrapping it in a workflow
method should not make it publishable.  If the original method is
publishable, then the wrapped method should still be publishable.

This was always intended to work like this, as we can see in the code
comment in `WorkflowMethod.__init__` but was not properly tested and got
broken at some point.

It's important to restore the behavior, because workflow methods such as
`validate` should not be published, users must only be able to use the
user interface transitions freely, workflow methods transitions are
only available if developer expose them in a script - and perform the
necessary consistency and security checks in that script.

Only "user action" methods needs a security declaration.

This can hide bugs, especially when updating business templates.

TODO: if we drop this we can also drop the command line flag

This is not supposed to happen and can hide errors.

This addresses the problem of
https://nexedijs.erp5.net/#/bug_module/20180719-135FAA8 a KeyError
raised when some categories in a subtree are modified and some are
removed and the corresponding base category is also installed as a base
category.

The problem was that both CategoryTemplateItem, which is in charge of
updating the base category and PathTemplateItem, which is in charge of
updating the categories listed as path both use the same
ObjectTemplateItem.install method, with the same object_to_update dict.
ObjectTemplateItem.install uninstall all objects that are listed in
object_to_update and not in self._objects so something like this
happened when business template from
test_update_business_template_with_category_having_subcategory_tree_modified
is updated:

  1. PathTemplateItem.install is called for the base category,
portal_categories/test_category/modified/removed looks removed, so it is
backed up. Because the the parent paths are not parts of self._objects,
trash tool will create simple trash folder for
portal_categories/test_category/modified

  2. PathTemplateItem.install is called for the paths,
portal_categories/test_category/modified is modified, so the previous
version will be backed up. At this point trash tool looks in the trash
bin and the path for portal_categories/test_category is already present,
so trash tool sees that path exists and does not return subobjects, so
after portal_categories/test_category/modified is modified, the subjects
such as
portal_categories/test_category/modified/container_in_which_child_is_added
are not restored and creating 'added' caused a
KeyError('container_in_which_child_is_added')

The approach is to make CategoryTemplateItem.install only consider base
categories - ie. objects where path is portal_categories/* and not the
subobjects, because they don't belong to CategoryTemplateItem but to
PathTemplateItem.
Co-authored-by: Georgios Dagkakis <georgios.dagkakis@nexedi.com>

Business template have some logic to keep uids when updating objects:
during installation, when an object is modified, business template first
remember the uids for this object and all its sub-objects,
replaces this object with the new version then recursively set the uid
on updated objects, so that updating an ERP5 document by business
template does not change its uid because this would break catalog.

When an object containing sub-objects is updated, it becomes a new
object in ZODB and sub-objects of the previous object are set as child
of the new object. This works even if the case of sub-objects being
instances of ZODB Broken class, except that the step where we restore
the uid fail as it's not allowed to modify a broken object.

Instead of unconditionnally setting the sub-objects uids, check that we
actually need to set it, because if it's already the expected value then
we don't need to touch the object.