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

No need to use a opaque user id. If we use mail address, to enable
google login for an existing user, we just have to "create google login
with email address and validate google login".

A more apporpriate place would be a dedicated "signup using oauth"
page, relying on erp5_credential for the actual user creation.

ERP5ExternalOauth2ExtractionPlugin: document a bit how this plugin and ERP5LoginUserManager interact

erp5_oauth_google_login: Zope user should not see this action because to create a Google login is required that a person in ERP5 exists

We are expecting user_id instead of username

erp5_oauth_google_login: s/erp5_username/user_id/g to be with consistent with Base_getUserValueByUserId

ERP5ExternalOauth2ExtractionPlugin: Fix query to find logins properly. It should be squashed in 4089f516

login_form: Use ERP5Site_getAvailableOAuthLoginList to know if google login is supported or not. With this, we can extend to other oauth easily

erp5_credential: Add link to login in ERP5 with Google Account and use zocial.min.css to display it nicely

erp5_xhtml_style: Add link to login in ERP5 with Google Account and use zocial.min.css to display it nicely

Add margin-top to display zocial buttons not too close from other buttons or links

Google Login follow the same implementation of ERP5 Login(subobject of Person) and with an action in preferences, the user can add Google Login to his person.