Also, url that is published in
test_14_AccessWebSiteForWithDifferentUserPreferences
iotherwise the response is the redirect, making the test fail

in case we publish with different languages

renderJS gadget HTML uses relative URLs to link to there javascript/CSS files.
Absolute URL calculation is resolved dynamically by the browser when loading the gadget.

When accessing an ERP5 web section without a trailing / in the URL, the browser will calculate absolute URL from the parent document and not the web site itself.

Example:
In http://foo.com/web_site_module/bar , the relative URL couscous.js will be resolved http://foo.com/web_site_module/couscous.js
If couscous.js is a document from DMS (Web Page for example), such URL can not be resolved and leads to a 404 error.

One solution to solve this is to redirect (302) the browser when accessing a Web Section (Web Site is a web section) directly in ERP5.
Example:
http://foo.com/web_site_module/bar ->  http://foo.com/web_site_module/bar/
But  http://foo.com/web_site_module/bar/view should not redirect

- The conversion server is supposed to be configured in a system preference,
  so do this instead of using a normal preference.
- _getConversionServerDict -> _getConversionServerUrl, to make clear that
  cloudooo is now configured by a url, instead of a host/port couple.
- Refactoring: From the moment where setUpERP5Site() sets up things
  automatically, we don't the "same" duplicated code throughout many test to
  redo cloudooo configuration.
- In the promise file, the volatile/persistent memcached url were swapped.

configuring host / port was still compatibility

This commit contain a testing business template for the receipt recognition module
test the "Receipt" type update as well as the OCR success and fail on a set of poor

This commit contain binary files that are test images..

This commit contain the business template that take a receipt image as a source,
binarize then segmentize it, and apply OCR on it. It then extract the meaning
with regular expressions. The image should already be loaded inside the
image module before it can be read.

The business template contain:
	* The receipt recognition module
	* An extension containing the code that binarize, crop and
	  segmentize the image then analize it.
	* A new type "Receipt" that contain a source image and the
	  field that contain the "total" value
	* A portal skin folder containing the extension externalMethods
	  aswell as the conversion script that call the recognition and
	  update the Receipt "total" field

Improvements (not limited to this list):
	- Easier loading of picture: directly from the receipt page.
	- Easier loading of picture 2: from phone with OfficeJS
	  (or any renderJS) application?
	- Detect when images are sideway and rotate them straight
	- Better "boxing" and segmentation: some lines are deleted from
	  the original image during the segmentation when they are too
	  close from other
	- Modify the neural network (lstm) to increase weight of signs
	  like $, euro, / and numbers
	- Use of a faster/smaller neural network: Most of the time is
	  lost with the loading of the neural network
	- Caching the neural network: See previous statement.
	- Extract currency, date and receipt emettor.
	- Use a neural network for the meaning extraction?

Avoid iterating over all columns known to catalog to then restrict to a
single table by using SQLCatalog API.
Only check for one range column suffix as code anyway relies on the triplet
of columns to be consistently present. Document this in the code and get
rid of now-unneeded range_column_set mechanism.

str.encode() first performs an implicit conversion to unicode using
sys.getdefaultencoding(), which is usually 'ascii'. The 'isort' module
changes the default encoding to utf-8, leading to UnicodeEncodeError
instead of UnicodeDecodeError. Let's simplify all this.

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.

Required as preparation for migrating to ERP5 catalog which itself has an accessor
`isIndexable` which we plan to remain disabled all the time. So better to rely
directly on isIndexable from erp5 site object.

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

/reviewed-on nexedi/erp5!314

/reviewed-on nexedi/erp5!313