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
	- Explicilty add manage option tabs in Catalog Tool

Move from SQLCatalog to ERP5Catalog as the default Catalog inside ERP5.
The major difference is use of Products.ERP5Type.Core.Folder as Catalog
base class.

Significant changes:
	-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

Create the SQLMethod class based on ZSQLMethods.SQL
class and XMLObject. Also, move attributes to
property in 'SQL Method' property sheets.

These methods will be used in erp5 catalog view in restricted environment.
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.

And, change in files where this was being used

Earlier, In ERP5Site, we use property 'isIndexable' to have control over indexing and unindexing.
This was usefull specially in case of bootstrap. To have this control, we had a function
`isIndexable` in SQLCatalog which we used to switch for enabling-disabling indexation. (769f9fb2)

This is a preparative commit for case where:
Now, as we move to ERP5 based Catalog, which itself is an ERP5 Object, hence it has an accessor `isIndexable`
of itself which we plan to disable for now(as we don't want circular dependency while indexing
catalog in itself). But as we did have a function `isIndexable` in SQLCatalog which had control
over the indexing, we needed to rename this property for ERP5Site.

Hence, now we use property 'isIndexingRequired' for ERP5Site and use to have overall control
over indexing process.

Please note, we do not intend to change the same property name for any other object. Its just
for ERP5Site.

This would also remove the need of evaluating the globals every time.

to fit original script behavior, from erp5_web skin folder.
Also fixes "KeyError: TraversalRequestNameStack" from
`WebPage.getDocumentValue(reference)` on the "View" skin selection.

To make it easier for users to change their preferences, so that they do not have to create the preference themselves, we tried to pre-create a user preference ready to be configured for each user.  

It was 59860df3 :  an interaction to create a user preference on `Person.setReference` which is more or less the time when this person become a user ( but not really - this was already a weakness of this approach).

This calls `Person_createUserPreference` that initialize the preference by introspecting the assignments of the person. This already had a problem that it was working only if the assignments were created before the reference was set on the person.

With the new user management introduced in !185 this interaction moved to `Person.setUserId`, which is called in Person's init script. This had the following problems:
 - All persons have a user id, so all persons have a preference. For sites with many persons that are not actually users, this create useless preferences.
 - During init, person does not have assignments yet, so `Person_createUserPreference` could not use information from assignment to create preference.

The suggested change is to create the preference only when the user click on *Edit my preferences* button.

This is done by adding a new `portal_preferences.getActiveUserPreference` method that returns the active user preference and create it if not already existing, this way we do not have to put logic in the user interface scripts.

All *Edit my preferences* links should use it like it was done in f62e6651

The `person_interaction_workflow` was completely remove, as the other interaction it was containing - clearCache when deleting the person - was useless . We had to adjust a few tests that was passing thanks to this interaction.

/cc @gabriel @vpelletier @kazuhiko @tc 

/reviewed-on nexedi/erp5!273

Base.edit has this feature of not actually modifying the properties when
the new property value is same as the current one, so when we do
`movement.edit(price=x)`, this will cause an implicit getPrice.

As price lookup is a bit slow, do not lookup price in this case.

/cc @vpelletier @kazuhiko @romain 

/reviewed-on nexedi/erp5!259

Fix for [#20160719-1B69F57]( https://nexedi.erp5.net/bug_module/20160719-1B69F57 ) 

These after clone methods in transformed resources are being too clever and behave very badly when the transformation itself is cloned.

The suggested approach is to stop initializing int index & reference when cloning transformed resources ("transformation lines"). This behavior is kept when adding new transformed resource. This become consistent with what we have, for example, with Sale Order Lines in Sale Orders. 

/cc @luke @seb @gabriel @kazuhiko @romain @Nicolas 

( see also nexedi/erp5!148 for more )


/reviewed-on nexedi/erp5!258

Abort transaction, we do not need changes made by test to persist.

Execute pending activities before removing persons, the pending
activities might be relying on the existence of persons.

This changes API on a script that some projects have customized, but
getActiveUserPreferecnce "should work" even with an old script not
returning preferences.

In that case, first call to getActiveUserPreference will create
preference but not return it, but next time getActiveUserPreference is
called, the preference will probably be indexed and will be returned.

This method creates a user preference if no preference exists.

We do not need to pre-create user preferences, especially that creating
them too early creates one preferences for each person created in person
module and does not allow Person_createUserPreference to create
preference based on person's assignments are they are not created yet.

We do not need to clear cache when deleting user logins anymore. This
problem was fixed differently.

Adjust tests that was relying on cache being cleared when persons ar
deleted:

testERP5Web.TestERP5Web.test_15_Check_LastModified_Header was never
isolated from test_14.

test_14 was filling Base_getWebDocumentDrivenModificationDate cache and
this cache got clear when the persons where being deleted during
tearDown. When removing this interaction clearing cache, we revealed
this weakness. Choosen solution was to clear cache before checking
response headers, to make sure we don't get something filled by a
previous test.

Tests should not need to reindex modules