Its better to change the tests where they need to call getpath function of
portal_catalog to use portal_catalog.getpath instead of portal_catalog.getPath,
as we have overridden the 'getPath' function for CatalogTool class due to change
in inherited class.

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

	- Remove copy-pasting all code from CatalogTool, better to rely on inheritence
	- Remove unnecessary imports
	- Add argument id in __init__ class
	- Add functions _isBootstrapRequired and _bootstrap
	- Update BusinessTemplate installation according to changes made in ERP5Catalog and Tool

We try to move from using SQLCatalog to ERP5Catalog as the default Catalog inside
ERP5. The major difference is use of Folder class as the base for Catalog from
Products.ERP5Type.Core

Significant changes:
	-Add dtml form for creating ERP5Catalog object
	-Inherit from Catalog class from Products.ZSQLCatalog.SQLCatalog instead of copy-pasting the whole code again.
	-Add allowed_types for ERP5Catalog tool
	-Monkey patch some property setters and getters to maintain consistency
	-Update id and title for ERP5Catlog while class initialization
	-Set declarative securities and solve some inheritance conflicts
	-Add isRADContent for ERP5Catalog Class
 	-Solve inheritence conflict for _setPropValue function in ERP5Catalog class
	-Add SQL Method portal_type in allowed_types for ERP5Catalog class
	-Override getCatalogMethodIds cause it uses global variable in SQLCatalog.Catalog
	-Redefine security declarations
	-Add functions for object_actions of Catalog portal_type in ERP5Catalog object
	-Add filter_dict and _properties attributes for compatibilty
	-isIndexable should be function instead of Accessor property for Catalog object

Here, we are creating the SQLMethod class based on ZSQLMethods.SQL
class and XMLObject. Also, we are moving important attributes to
property in 'SQL Method' property sheets.

Loosen the security on methods which we will use in erp5 catalog view in
restricted environment. As suggested by \@vpelletier, this should be
accepted as all methods were restricted by default earlier.

/reviewed-on nexedi/erp5!229

erp5_calendar: Leave Request Period only use services as Resource

erp5_travel_expense: In expense report, remove useless rsvp.queue, do not overwrite special character

synchronize automatically data block web site

A Localisation Record is created when submit a expense record
only one received localisation record per user

erp5_travel_expense: localisation search should not prevent image preview

erp5_travel_expense: make sure localisation gadget is loaded

erp5_travel_expense: don't create localisation record when location is undefined

erp5_travel_expense: naming convention

erp5_travel_expense: Have Projects availables in Expense, define group on images and set source_section

epr5_payroll: update social_declaration view as transactions can be aggregated by several social declarations

It will allow to differenciate the Employer for which the Employee is working, and the Company to which the accounting and the payment are related

This reverts commit 6b6f1fe0.

This reverts commit 003e34c7.

The resource-to-account relationship is intended to be declared by
predicates (which are used here), but should only be explicitely set on
movements when they *differ* from these rules, as special overrides.
So, setting default accounts on movement is unnecessary work:
- predicate lookup is expensive, and business-model-specific shortcuts may
  be available which such generic implementation cannot implement
- multiplying unneeded relationships increases category table size, which
  is generally detrimental to performances