With zope.tal 3.6.0 - commit 26fadc4 (Increase the default value of
the `wrap` argument from 60 to 1023 characters, to avoid extra
whitespace and line breaks., 2011-08-20) from zopefoundation/zope.tal -
page templates keep the attributes on the same line and produce
slightly different output, although equivalent.

This commit updates the places where we do snapshot testing to the
new output. We discussed using lxml features to compare html and xml
from https://lxml.de/lxmlhtml.html#running-html-doctests but because
the corporate identity web pages are invalid html, it seems unsafe
to rely on lxml at this point. Once corporate identity web pages
are fixed this would probably be a good thing to do.

Most service worker precache scripts reference a favicon.ico, but this
is using the default favicon.ico from Zope and even though it was included
in all ERP5JS and OfficeJS web sites, this was mostly not used, only
web_renderjs_ui web pages reference favicon.ico.

There's a favicon.ico in erp5_xhtml_style skin folder, but the skin
folder is not in ERP5JS skin selection.

On Zope2, this caused ERP5JS and OfficeJS application use the default
Zope favicon. On Zope4, the service worker can not fill its cache
because of 404 errors.

To solve this, provide a favicon.ico in ERP5JS skin selection, by
copying the one from erp5_xhtml_style. We also reference it explicitly in
web site layout properties so that it remain in the cache.

OfficeJS applications do not use favicon.ico explicitly. They use icons
in their web application manifest, but this does not seem to be use as
favicon unless the PWA is installed. This part is not addressed by this
commit.

Globals.DevelopmentMode initial value is False but it is initialized to True at
Zope startup (App.config.{setConfiguration,DefaultConfiguration}).

zope.conf of Zope2 (zopeschema.xml) used to define event/Z2 log files and
properly configure logging but this is not the case anymore with
Zope4 (wsgischema.xml).

This adds path to event/Z2 log files as command line parameter as we probably
don't need further configuration such as message format (SlapOS recipe has never
handled it anyway).

This was still working with Zope 2.13 because the default output_encoding for
HTML was iso-8859-15 but this is not the case anymore with Zope 4. Moreover this
should be explicit rather than implicit anyway...

Revert "testBusinessTemplateTwoFileExport: Make output_encoding explicit as it should have always been."

This reverts commit 968991e7 which does not
actually work properly with Zope4.

SQLCatalog_trimInventoryCacheOnCatalog needs resource category on movement.

Also, `__code__` has been introduced in Python 2.6 (for forwards compatibility
with Python 3) as an alias to func_code which has been completely removed in
Python 3.

This fixes testFunctionalCore failures:
  [...]
    Module ZPublisher.mapply, line 53, in mapply
      code = f.__code__
  AttributeError: 'DefaultGetter' object has no attribute '__code__'

This fixes a failure due to Zope4 now defaulting to utf-8.

This seems to be used only in Localizer's ZMI. This is not compatible
with newer version of DocumentTemplate, but because we don't use, it's
better to remove the functionality

Use `portal_alarms/check_consistency` after configuration to make sure that every document created by configurator or part of the dependency business template is valid.

For now we have two exceptions (that are some TODO for the future):
 - Web Sites, because upgrader constraints are not ran by configurator at this point
 - Business Configuration, because most of the configurator item classes don't fully follow the protocol of constraints, their `fixConsistency` method always return "something needs to be fixed" without actually checking.

See merge request nexedi/erp5!1562

See Revert "zope patches: display OFSFile content using full available height in zmi".

This fixes testBigFile failures because of `size` not being set to 0 when `data`
is set to None.

This reverts commit a197365b as it does not seem
to be needed anymore.

Modify DTML templates likewise Zope4 removal commit:
  commit 1df76c1ea8911d7d9249eb6beab1fafd4ed5803c
  Author: Hanno Schlichting <hanno@hannosch.eu>
  Date:   Sun Jul 3 14:19:26 2011 +0000
      Removed `bobobase_modification_time` from `Persistence.Persistent`, you can use `DateTime(object._p_mtime)` instead.

This fixes failure on test_PROPFIND_on_document (testWebDavSupport).

also use the same pattern of clickAndWait and assertElementPresent
in all places, sometimes we used click and waitForElementPresent,
which should be equivalent because we click on a top level navigation
link

This reverts commit 8f5497d4.

This is not longer needed - with Zope 4 the ZMI is better and we now
have possibility to edit most of these through ERP5 user interface.
The main motivation is that these kind of patches are really hard to
keep up to date.

This reverts commit 88786a70.

This is not longer needed - with Zope 4 the ZMI is better and we now
have possibility to edit most of these through ERP5 user interface.
The main motivation is that these kind of patches are really hard to
keep up to date.

This reverts commit c89e308f.

This is not longer needed - with Zope 4 the ZMI is better and we now
have possibility to edit most of these through ERP5 user interface.
The main motivation is that these kind of patches are really hard to
keep up to date.

In the changes from ExternalMethod 2.13.1 -> 4.5, now ExternalMethod
define __code__ (and __defaults__) to a computed attribute calling
getFunction, but getFunction is different in our patched class, so
when unwrapMethod tries to get __code__, it will raise and mapply
will not consider the external method as being callable, so a simple
__repr__ of the ExternalMethod will be used as response body when
published.

By defining __code__ to something using our patched logic, this
problem does not happen.

There's also a TODO because DevelopmentMode is now True, which uses
a different code path which was causing TypeError, because getPath
returns None, which os.stat does not accept.

Creation date is defined as the oldest date of any workflow history on the
considered document.
Modification date is defined as the newest date of any workflow history
on the considered document.
As soon as there is more than one workflow on a given document, these
values can differ: they are set with the wall-clock time at the moment
the workflow history of each workflow is initially filled, so one can land
just before a second change and the other right after.
So comparing them is meaningless, catalog or not, and just causes this test
to be unstable.

Because we want to check consistency on all documents created by
configurator, we also need documents created during the test to be
consistent (or deleted)

We had trade phase duplication:
 - `trade_phase/default/*` were provided by erp5_simulation_test
 - `trade_phase/trade/*` are provided by erp5_configurator_standard_categories

so the former was only for testing and the later were actually used in
instance configured by configurator.

But in some paths from configurator_standard_*template, which are also
used on configurated instances, were using trade_phase/default (the one
from test). Some rules were referencing these categories, but apparenlty
not using them.

To fix this confusion, use trade_phase/trade/* everywhere, and install
erp5_configurator_standard_categories where needed in tests.

BusinessConfiguration have a resource category, but it's the workflow,
it's not really a resource, so some APIs from the base Amount class are
not available. Because they have no meaning on BusinessConfiguration
anyway, define the broken APIs to return nothing.

This fixes errors trying to use check_consistency alarm on Business
Configurations.

Tools also contain documents, so it makes sense to check them as well

These documents were probably edited before they had correct property
sheets, because they had local properties as incorrect type, as reported
by PropertyTypeValidity:

    <ERP5Type.ConsistencyMessage for PropertyTypeValidity type_check on portal_gadgets/erp5_persons (message: Attribute gadget_type should be of type lines but is of type <type 'str'>)>
    <ERP5Type.ConsistencyMessage for PropertyTypeValidity type_check on portal_gadgets/erp5_gadget_new_sale_opportunity (message: Attribute gadget_type should be of type lines but is of type <type 'str'>)>
    <ERP5Type.ConsistencyMessage for PropertyTypeValidity type_check on portal_gadgets/erp5_gadget_contact_person (message: Attribute gadget_type should be of type lines but is of type <type 'str'>)>

For historical reasons, EncryptedPasswordMixin.setPassword was public
and did its own security checks, this was the case since 7d0882ef (
setPassword have to do explicit security checks…, 2007-11-12), this was
because we wanted to support cases where user can edit the login ("Edit
portal content" permission), but not changed the password ("Set own
password" permission).

Also, we wanted to support the case where login is edited through a view
form, in that case we have a my_password field that is empty and we
don't want to set the password to None in that case.

For these two reasons the API to set password was very complex and
behaving differently from other accessors: usually setSomething(None)
just set something to None, ie. "unset" something, but for passwords it
was not the case. Also we had to introduce _forceSetPassword method,
which sets the password without security checks, so that it can be
called from unrestricted code for cases where user does not have the
permission to reset password (like in the reset password scenario).

Since d1312cdb ( make edit check the security remove all useless
security declaration on private method, 2008-05-23), edit supports
restricted properties, so we can simplify all this and make setPassword
a more standard accessor, ie:
 - setPassword has a security declaration, so if it is called from
  restricted python the security will apply at `__getattr__` time.
  `edit` method will also check security
 - setPassword(None) reset the password.
 - The logic to not change the password when editing in view mode is now
  `edit` responsability. ie. `login.setPassword(None)` resets, but
  `login.edit(password=None)` does not reset.

This also correct some usage of the lower level API (`pw_encrypt` and
`pw_validate`) which were never supposed to use `None`:
 - `pw_validate` was called with None when a user without password was
  trying to login, causing a TypeError that was cached by PAS and logged
  with level debug (and refusing login). Now the error is no longer raised.
 - `pw_encrypt` was called with None (but apparently only in the tests,
  when doing `user.newContent(portal_type='ERP5 Login', password=None)`)
  and this was creating a login with password `'None'` with AccessControl 2.
  With AccessControl 4 this was an Error.