To use some private functions from Catalog Class in restricted ERP5 environment,
we create extensions here and use external method to call them.

!WARNING!  : External methods in restricted env.(Debugging currently)

manage_schema is not needed in case of CatalogTool for now.

We are keeping the views for catalogs inside erp5_core portal_skin to
maintain consistency

Using CopyContainer to use functions from inherited class also and maintain
consistency between them.

inside ERP5.

This is the 1st step in moving ZSQLCatalog inside ERP5. Therefore,
we try to remove the dependencies on OFS one by one. Here. we change
this for Folder module and also reomved the monkeypatching of
getPath(which is being used in CopyContainer in CopySupport). The
reason for doing so is to imply using getPath from Base for CatalogTool
objects which was earlier directed to ZSQLCatalog as it use ZSQLCatalog
as one of its base class.

While trying to use module `Products.ERP5.Core.Folder` in ZSQLCatalog,
circular dependencies in Base caused error, so for testing we try to
defer the imports to local context where they are specifically needed.

p Please enter the commit message for your changes. Lines starting

erp5_catalog: Prefer using CopyContainer from OFS due to inconsistency between CatalogTool and CopyContainer in ERP5Type

The commit 7e84b4e8 did break the instance, this can be considered
as the revert.

getpath function in ZSQLCatalog takes an extra agrument which is
not needed while using getPath in Base.
This process can be counted as a step in the transition of Catalog
inside ERP5. Though ZSQLCatalog is also a part(read: content) of Catalog Tool,
its better to move it side by side with keeping in mind no failure in the
tests of ERP5.

This step is needed due to the use of BaseTool as Base class for CatalogTool
due to which there were conflict between getUrl from the Base and the one
from the BaseTool.

The function reindexObject at CatalogTool has bee renamed to reindexCatalogTool
in the commit 3b760022 . For CMFCatalogAware to be compatibile to use in
CatalogTool, we need to renmae the patched reindexObject here also.

erp5_catalog: Change name of reindexObject method to use it as a new method for CatalogTool inside ERP5

This bt5 would be handling the views for the transitioned/moves erp5
catalog into erp5.

Changes from Ni Yan, and Sven Franck

Changes from Ni Yan

Otherwise this is interpreted as text/html after sending html emails

knowledge_pad/worklist gadget: support displaying a worklist that does not respect the (%(count)s) convention

* Worklist must include (%(count)s) to include the number of document in that worklist
* The role of users who have to take care of the documents must be defined on the worklist

There's no magic in this patch series: it is known that HBTreeFolder2 has
limitations about the ids that can be set without conflict, and this can't be
fixed without causing compatibility issues with existing data.

The patches contain:
- some optimization
- bug fixes
- detection of id conflicts before causing data loss

This will also allow us to use a newer version of ZODB. Recent BTrees failed
on the following line of `_setOb`:

        if len(id_list) == 1 and not htree.has_key(None):

(None is not valid key for comparison since
 ZODB commit bb5aac21277f43333d6450064dc6670c8c280e40)

The long story about id conflicts is that a HBTreeFolder2 can't store 2 objects
<A> and <A>-<B> where <A> does not contain '-', and that's the rule followed by
_getOb/_setOb/_delOb. However:
- Conflicts are detected by testing the type of the value, which means
  HBTreeFolder2 can't store values of the same type as the one it uses
  internally (i.e. OOBTree).
- For performance reasons, _htree_iteritems and getTreeIdList use a stricter
  rule: they assume there can't be 2 objects <A> and <A>-<B>, regardless of the
  presence of a separator in <A>. Maybe this rule should be enforced in _setOb.

/reviewed-on nexedi/erp5!112

It was an unefficient adaptation of BTreeFolder2 code.

These methods have probably never been used.

getTreeIdList is still required by Folder_reindexAll.
getTreeIdList is not immediate anymore but the reindexing of a folder should
anyway be reimplemented to not depend on this method: only one tree is indexed
at a time, which is unefficient when they're small.

_getOb and similar methods are reimplemented in a faster and safer way.
It now checks it is only used to return leafs.

Similarly, _delOb now refuses to delete trees at the root.

__getattr__ wrongly returned wrapped results (__of__).

Since commit 055d0a69
("HBTreeFolder2: make object{Ids,Values,Items} really lazy"),
_fixCount() does nothing because objectIds() was optimized in a way that
len(self.objectIds()) already returns self._count()