This replaces ERP5Site_checkPythonScriptsWithPyflakes that I guess
nobody was using

This reverts commit 91bb6bec.

use pylint, at least here

Name is unchanged, but it will use
Products.ERP5Type.Utils.checkPythonSourceCode which uses pylint.

 .. except from Draft and Submitted state.

Document security should be based on group, site, function defined on
document, sometimes publication section and or follow up, but the owner
should only be considered in draft state.

For conveniance (and compatibility), Owner is also allowed to view in
Submitted state. The use case is for when a user submit a document he
will not be allowed to see, for example because he made a mistake when
choosing properties, user is still allowed to view the document and
there's no unauthorized error.

We want to allow a user to set properties before publishing a document
and later, once the document is no longer draft, the security of the
document will be depending on these properties.

We want to prevent users to get permissions on a PDF document that would
be created by interactions and they are not supposed to see. For exemple
when we generate a PDF invoice and store it in document module. In this
case, as the interaction runs as the user, this user will have Owner
role implicitely.

(cherry picked from commit 1664e541)

This action should only be possible if user have View History
permission.

erp5_data_protection relies on removing the "View History" permission to
make sure users cannot see the properties before protection in the
history tab. This was supported by Base_viewHistory, but not by ZODB
History

(cherry picked from commit d2c08463)

This way, guarded_getattr is used and accessor permission is applied.

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.

This reverts commit f547e874.

This reverts commit 814afaf3.

This reverts commit 7c8082a2.

The interaction should also be triggered if a Calendar Exception is changed.

Especially because we do not need them in predicate table.
This applies to many cell portal types.

Especially because we do not need them in predicate table.

Especially because we do not need them in predicate table.

Especially because we do not need them in predicate table.

predicate_category was already doing this correctly

Performance is still not optimal, but should be better than before. At
least it does not assume that movements will be in predicate table.

variation_category is implemented

If exception happens when contacting google server, just propagate it,
PAS will handle it.

fixup! erp5_oauth_google_login: Set access_type as offline to be possible refresh token in background and automatically

refreshing token was not working because of incorrect API usage

Happens when user has a __ac_google_hash cookie but token cannot be
found in token storage.
In that case login wouldn't be possible anyway, but we should not
pollute the logs.

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.

tell business template to keep z_catalog_stock_list when upgrading
erp5_calendar

Because CatalogTemplateItem uses a special preinstall method, their way
of computing modified objet did not support template_keep_path_list.

To support template_keep_path_list, we must give priority to
ObjectTemplateItem.preinstall, because BaseTemplateItem.preinstall does
not work with path.

Google Logins are created manually in the backend instead of automatically through Base_createOAuth2User

erp5_oauth_google_login: Set access_type as offline to be possible refresh token in background and automatically

access_type as offline indicates whether your application can refresh access tokens when the user is not present at the browser.

This value instructs the Google authorization server to return a refresh token and an access token the first time that your application exchanges an authorization code for tokens state.

Also the code was simplied to use oauth2client rather than http requests directly use persistent cache instead of ram cache to lose token if we restart all nodes