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.

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.

reorder methods, make some docstrings a bit more informative and fix
several typos

Replace it with a method on ERP5Type.Base so these activities get found
by CopySupport.unindexObject and flushed, rather than remaining on the
interaction workflow's context and failing when run.
It seems a lot more likely for a document to be deleted while interactions
are being spawned than an interaction workflow itself. So this should be
a net benefit in activity stability.

This currently only works because CookieCrumbler reacts on *all* urls which
contain the magic login & password fields. But the POST request body lacks
any value from submit fields, which bypasses the "logged-in" scripts, which
is harmless with current code but lack realism.

See merge request nexedi/erp5!1516

The initial idea was that publishing documents is something really exceptional, the "attach document" normal use case is typically use cases like attaching a PDF invoice to an invoice document in accounting, ie. most of the time it's with sensitive information that we don't want users to be mistakenly publish on the internet just because they selected a wrong value in the field.

Now we have a project with use cases where the attached documents needs to be published, we did not change our mind that publishing an attached document is an exceptional case, but we want to make it possible to configure so that in certain contexts, publishing documents is possible.

So we reuse the existing configuration by type based method idea and when the getPreferredAttachedDocumentPublicationState returns "published" we make it possible to publish by default.

Theses methods have always been using user_id, but where written at
a time where there was not such disctinction

This test case tries to provide message helpful for debugging in case
of assertion failure for assertUserCanPassWorkflowTransition, but
this was not correctly using new workflow API and in case of failure
there was an error like this:

  File ".../custom/test.py"
    self.assertUserCanPassWorkflowTransition(user, 'stop_action', packing_list)
  File "product/ERP5Type/tests/SecurityTestCase.py", line 237, in failUnlessUserCanPassWorkflowTransition
    if wf_transition.trigger_type == TRIGGER_USER_ACTION:
AttributeError: 'NoneType' object has no attribute 'trigger_type'

The previous implementation was using getGuardSummary, which no
longer exist in new workflow, so we implement similar logic here.

The new message changes a bit, it now look like this:

    AssertionError: User X can NOT pass stop_action transition on Internal Packing List at /erp5/internal_packing_list_module/20220218-22A38 (draft on delivery_causality_workflow, draft on internal_packing_list_notification_workflow, started on packing_list_workflow).
     Roles: [Owner, Member, Authenticated, Associate]
     Available transitions:
              deliver_action[packing_list_workflow]
                    Expression:
                    Permissions:
                    Groups:
            * stop_action[packing_list_workflow]
                    Expression: python: not(state_change['object'].getPortalType() == "Sale Packing List" and state_change['object'].getSimulationState() == "confirmed")
                    Permissions:
                    Groups:

1b1dbf60 (tests: also consider python unittest failures in
functional tests, 2021-06-16) was not counting properly the cases
where we have selenium failures. In that case we only want to count
selenium failures, if we add with the python failures from
status_dict, we report one extra failures.

The correct approach is to count selenium failures if any and otherwise
count python failures
Co-authored-by: Vincent Pelletier <vincent@nexedi.com>

Avoids duplicating items from that list.

Both so that changes to the list of core business templates are applied on
upgrade, and to avoid uninstalling core business templates, if no other
maintained-up-to-date business templates depend on them.
Also, improve the documentation of the erp5_upgrader version of this
script.

But make it non-publishable.

The main reason is to use portal type setters, and not set the properties
directly: setting the properties directly bypasses interactions which
trigger type refresh, which hence prevents such changes from being applied
to the types until something else would cause a reload.
While at it:
- modify the property sheet list once only instead of once per added
  property sheet
- only modify the property sheet list when fixit is true
- improve constraint message to actually tell what is being detected
- do not report a constraint error when no change is necessary
- follow naming conventions: avoid abbreviations, variables holding
  documents must end in "_value"
- avoid single-use local variables

This reverts commit 77b3f202.
For some obscure reason, this affects unit tests related to inventory
unit conversion. There seems to be too much code to cleanup to keep this
patch for now, so drop it.

Document/WebSite&erp5_web: introduce web site language priority convention to fix report language issue on renderjs ui

1. [Browser is supposed to send something between 0 and 1]( https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Language )

2. [Localizer will set 2 or 3 for cases where user selected language]( https://lab.nexedi.com/nexedi/erp5/blob/08be2f8cc936fbdc3d5bafb4355c3a475198abc1/product/Localizer/Localizer.py#L149-172 )

3. all print scripts seems set selected language priority to 10

so here we introduce a convention that site language priority should be 8(>3 and < 10) to fix report language issue

Fallback to modification_date if a document does not have an effective_date.

Indexation activities may spawn further activities, and for_each_activity
expects the number of activities after a test to be zero.

System user should be more reliable than whatever user has ownership of
catalog tool (which may have its account closed or its roles changed).

CMFActivity: Fix ActivityRuntimeEnvironment.getPriority when activity was not loaded from an SQL queue.

This happens when activities are being flushed from the ActivityBuffer
directly, without being inserted into and then loaded from the SQL queue.
It is unclear whether there are uses of this pattern besides
testCMFActivity, but it is easy enough to fix.

Checking activity presence/absence is not enough: it risks both false
negatives and false positives. Instead, manually poison the catalog's
content and check which value we retrieve after executing spawned
activities (if any).

it's not finished, rework if need

- Remove trailing whitespaces
- Follow guidelines
- Fixup types

Also, use it in Products.ERP5Type.tests.ERP5TypeTestCase.

The only use 'my_' has above 'your_' is to provide a default field value
without needing a TALES expression. This only gets applied based on the
field ID in the form being rendered. Field libraries are never meant to be
rendered, so using 'my_' is always (if harmless) pointless. What really
matters for the field naming convention (which exist to avoid collisions
with form properties) is that *some* prefix is used, be it 'my_' or
'your_'.
So update this check rule to tolerate 'your_' prefixes in addition to
'my_'.
Also, use 'not any([...])' instead of 'not 1 in [...]'.

I guess this is the intention of the unnecessary pair or parentheses.