This commit is a revert of revert 561b3461a0
and 97ba860fd38c530d3f3678f676754862afad0f11.
Previously we split moves when no picking, now we consider it
unnecessary.
Task 2446915
COM PR #66583
ENT PR odoo/enterprise#16554
* sale_product_matrix
Before this commit, if we created a new row in an editable list view,
do not "touched" it and clicked out of the list then the record tried
to be saved and threw error notifications.
Now, that flow will discard the record to make it consistent with the
form view which discards the record when we leave the form.
task-2431691
closesodoo/odoo#68382
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
PURPOSE
Attract the attention of the user on messages that need action from him in the
mass of messages that are sent in a channel.
SPECIFICATIONS
Highlight messages mentioning the current user in a channel.
Task-2365956
closesodoo/odoo#66889
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
As no global rule is defined for system, people belonging to both system
and a functional group may be limited in their rights about sms templates.
For example install event_sms -> admin is member of system and event manager
groups. He cannot edit templates other than related to event.
With this commit members of system may write, create or unlink all templates
independently from their functinal groups.
Task ID-2495426
Followup of odoo/odoo#64626closesodoo/odoo#68535
X-original-commit: e0c1563993da918a0fbc2e31a13f3fe6a7ea2916
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Several documentation pages have been removed lately.
Indeed it holds more adavanced functional or technical
flows and less basic pages. eLearning notably is more used.
A link to SMS documentation is still present in base_setup
but related documentation has been removed so it is leading
to `404 Not Found`.
This commit fixes the issue by removing the broken help link from
settings.
taskID-2489666
closesodoo/odoo#68532
X-original-commit: 3b3581c3e600c38318403543cae2f8d0c9ac5673
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
- Connect with Admin
- Go to Contacts, edit himself by adding a Private Address
- Create an Internal User without "Access to Private Addresses" right (i.e. User X)
- Go to any app implementing chatter (i.e. Sales)
- Create a SO
- Add the created Private Address as follower
- Make sure User X can access the record (i.e. Sales: Administrator)
- Connect with User X and open the SO
An Access Error is raised while trying to fetch data about the followers.
This commit prevents to:
- add a private address as follower of a record
- add a private address as Recipient in full composer
- propose private addresses when adding a mention to a partner
opw-2428936
closesodoo/odoo#68493
Task-id: 2463622
X-original-commit: 20536e1bbeb641539c0de44364f8376e7cef651b
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
Following 7a235c19ff, use an alternative
API to the method autocommit(). Several functions managing databases
use a connection in autocommit mode to execute some commands outside of
a transaction.
closesodoo/odoo#68491
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Before this commit:
The google synchronization dis not properly synced event in some conditions. Some use cases were not properly tested.
Recurrent events were regularly badly synchronized with Google.
Several issues occured:
- events not follow recurrence were duplicated on both Google or Odoo and sometimes deleted when the recurrence was reapplied.
- the base_event (first event of the recurrence) was duplicated
- miscalculation of the event google_id when they were part of a recurrence but did not followed the rrule.
- improper data handling from google. Odoo objets were created with incorrect values
- attendee state was not properly sync from Odoo to Google
- whole recurrence deletions from google were not properly sync in Odoo
- when time fields of a recurrence were modified on Google, modifications were ignored on Odoo
- Event timezone were not properly saved on the recurrency. (Odoo saves it on the recurrency and Google on the event)
- Odoo considered that all public events are writable bu Odoo users. That would trigger errors as Google implement an access right model on public events
- lack of tests
- a lot of weird behaviors resulting from these problems.
closesodoo/odoo#68412
Taskid: 2456498
Opw: 2299834
X-original-commit: dcfc8b7896f079e8e4474392807d9c53cb7e94f3
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Co-authored-by: Lucas Lefèvre <lul@odoo.com>
Co-authored-by: Arnaud Joset <arj@odoo.com>
Before this commit, when a module wasn't correctly defined (e.g.
wrong format for dependencies, wrong format for module name, name
already defined...), an error was thrown but only in debug mode.
In non debug mode, the problem was simply ignored, which is wrong.
An example of harmful consequence would be the following: if
someone defines a new test file and uses an already used module
name, he won't be notified of his mistake unless he runs the suite
in debug mode. If he doesn't, the runbot won't detect it either as
it runs tests in non debug mode. It would then lead to one of the
two test suites not being executed.
Fun fact: a lazy loaded file was actually loaded twice, but we were
only notified in debug mode. With this change, it made the test
suite fail all the time, no matter the mode. We simply removed the
file from the page source, and let the first test needing it lazy
load it.
closesodoo/odoo#66918
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
PURPOSE
Before this commit, the "payment from odoo" flow (direct) required
tokenizing a payment method before processing a payment, rather than
directly processing the payment, and eventually tokenizing the payment
method later. In practice, this often meant that a 'validation'
transaction had to be processed and immediately refunded in order to
generate a temporary token. Then, a second "payment by token" flow had
to be executed to process the intended payment.
This implementation was too rigid for most modern payment providers'
APIs. Indeed, they mostly expect single processing for a given payment
and usually offer the possibility to tokenize the payment method after
the payment, rarely before. Because of this, the implementation of many
providers was either difficult, limited, or even impossible.
Among the various incompatibilities, we find: support for direct
payments but not tokenization, lack of support for authentication during
tokenization, absence of hosted page dedicated to tokenization, etc.
As another cascading consequence of this implementation choice, several
providers could not be migrated to newer APIs after that the ones
implemented in Odoo were deprecated.
The goal here is thus to 'invert' the payment flow implemented in Odoo.
As this means re-writing most of the payment module and of its provider
implementations, the opportunity is taken to deeply clean and document
the code of the impacted modules.
SPECIFICATIONS
- Lift the limitations listed above by inverting the generic direct
payment flow to first create and process a transaction, then tokenize
it if requested.
- Remove the `payment_flow` field on `payment.acquirer` and let the
acquirer choose the appropriate flow according to the use-case.
- Filter acquirers offered to the customer based on the use-case.
- Add overridable hooks at key steps of the payment flow to allow
implementing new providers with minimal effort (both in Python and
JavaScript).
- Move all module-specific logic and fields to where they belong (e.g.
let Subscriptions filter out acquirers based on their support for
tokenization, move `qr_code` in `payment_transfer`, ...).
- Homogenize the inheritance strategy of acquirer modules.
- Standardize the implementation logic in other modules' controllers.
- Improve the traceability of payments through stored fields and logs.
- Remove the public read right on `payment.acquirer` and enforce the
use of access tokens in all modules' flows.
- Fix all bugs that were inherent to the old implementation.
- Replace the previous testing suite (which was mostly commented-out for
years) with a new one that allows testing of both routes and flows
with different test configurations (user, transaction context, ...).
LINKS
Enterprise PR: https://github.com/odoo/enterprise/pull/12528
Upgrade PR: https://github.com/odoo/upgrade/pull/2291
task-2085989
closesodoo/odoo#56187
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Co-authored-by: Antoine Vandevenne <anv@odoo.com>
Co-authored-by: Victor Feyens <vfe@odoo.com>
Co-authored-by: Arnaud Joset <arj@odoo.com>
Co-authored-by: Kevin Baptiste <kba@odoo.com>
Co-authored-by: Barad Mahendrasinh <mba@odoo.com>
Co-authored-by: Prakash Prajapati <ppr@odoo.com>
Co-authored-by: Adrien Horgnies <aho@odoo.com>
This commits drops the direct payment flow supported by the SetupIntent
API in favor of the payment with redirection flow, supported by the
Checkout API only.
See the merge commit for more details.
task-2333040
Co-authored-by: Antoine Vandevenne <anv@odoo.com>
In this commit, we take the opportunity to replace the previous unsecure
API with the new FlexCheckout API that implements payment methods
validation in a hosted page. Payment processing is still done with the
DirectLink API.
This commit also renames the module `payment_ingenico` to
`payment_ogone` as well as the referring strings ("Ogone" instead
of "Ingenico", ...).
A dedicated [MOV] commit is not used because neither the [MOV] commit
nor the adapted [REF] would be valid on its own.
See the merge commit for more details.
task-2333029
task-2313907
task-2334015
Co-authored-by: Antoine Vandevenne <anv@odoo.com>
This commit also renames the module `payment_odoo_by_adyen` to
`payment_odoo` as well as the referring strings ("Odoo Payments" instead
of "Odoo Payments by Adyen", ...).
A dedicated [MOV] commit is not used because neither the [MOV] commit
nor the adapted [REF] would be valid on its own.
See the merge commit for more details.
task-2390665
This commit also drops the payment with redirection flow in favor of
the direct payment flow only, while preserving the currently used APIs.
See the merge commit for more details.
task-2333030
Co-authored-by: Adrien Horgnies <aho@odoo.com>
This commits also switches the Adyen implementation from the Hosted
Payment Pages API to the new Checkout API, hence replacing the payment
with redirection flow by a direct payment flow.
See the merge commit for more details.
task-2479832
This commit replaces the old online payments API of the `payment`
module with the new one and adapts to it all the implementing modules.
See the merge commit for more details.
task-2085989
task-2119838
task-2165982
task-2289255
Co-authored-by: Victor Feyens <vfe@odoo.com>
1. Have a product with cost A
2. Have a pricelist which modify the price of the product to B based on
the quantity
3. Create a sale order with the pricelist. Under the "Optional
Products" tab add the product and match the pricelist requirements
No price modification will occur, because there is no reaction to the
quantity change
opw-2480696
closesodoo/odoo#68494
X-original-commit: ab24134abb81399acd6ee49c4553aa0930384e37
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
As this backport already exists in saas-14.2 and master, only the
`lxml.html.Element` part is kept in this commit which is a safer way to
build the widget.
closesodoo/odoo#68483
X-original-commit: c891d61802018a14944c22d01316872427a40284
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Commit [1] tweaked the empty (unset) fields css rules s.t. they
have a non null height in readonly, to reduce the shift between
readonly and editable form view. This only concerns form view,
but the changed rule also applied in list view. As a consequence,
empty fields increased the rows height in list views.
https://github.com/odoo/odoo/commit/288b24cbdf54ac0dbee7e012f074fac9a0c68238closesodoo/odoo#68482
X-original-commit: 020b814b3be055c6bf795153dce6079810d34b1c
Signed-off-by: Michaël Mattiello <mcm-odoo@users.noreply.github.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This reverts commit cfd68df.
The fix was to not value the subcontracting location while it has to be
valued.
closesodoo/odoo#68499
X-original-commit: b1ba8b48f69919d18b946e4f602b9a136e835d51
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
odoo/odoo#64626 attempt at improving sms.template rules seems quite broken
* do not restrict system group to calendar.event: this makes no sense.
With this fix admins can now only use templates being linked to calendar
event if calendar_sms is installed which is not really smart. Not sure
what was the exact original purpose;
* ir.rule in hr_presence has no use on hr.manager group if they do not
have any access through access rules. Indeed they are currently
restricted to read access as all standard internal users;
Task ID-2191254
COM PR odoo/odoo#68445
ENT PR odoo/enterprise#17340closesodoo/odoo#68495
X-original-commit: 9353dedaf9111e5ee3ab5ed98e3571d5ac83cae8
Related: odoo/enterprise#17359
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
sms.template model has several record rules to give access to templates
linked to models managed by certain groups (like crm.lead for sales managers)
These record rules were meant to restrict access to certain model to create,
write and unlink, but not read.
This is leading to issues when trying to read a template on other models.
Indeed people should always be able read sms.template content.
Unit test were also added to the sms module to ensure that a member of
group_user can always read a sms template.
Unit test is added to ensure admin always has full control on sms.templates.
Task ID-2191254
COM PR odoo/odoo#68445
ENT PR odoo/enterprise#17340
X-original-commit: 6a00157f79be30a6efd6d039504c57be07c449fd
Before this commit the latest posts snippet implemented the lookup for
its templates and its rendering procedure.
After this commit a new blog posts snippet is introduced which relies on
the dynamic snippet mechanisms.
task-2477207
See https://github.com/odoo/upgrade/pull/2262closesodoo/odoo#67334
Related: odoo/upgrade#2262
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
PURPOSE
Improve mail_client_extension: be more modular, clean code organization,
support contact and multi-records, ease helpdesk integration.
SPECIFICATIONS: CODE CLEANING
mail_client_extension: split authentication and main controller code. Purpose
is to ease code understanding and split authentication code from business
related code.
crm_*: split crm code from mail_client_extension. Purpose is to allow the
user to use the mail_client_extension without needing to install CRM, this
will also allow the usage of the mail connector in other modules without
the need for CRM.
Rename {crm/mail}_client_extension to {crm/mail}_plugin: easier to read
and to work with.
SPECIFICATIONS: CONTACTS / MULTI RECORDS SUPPORT
This merge adds support for searching multiple contacts using a text query in
the email plugin rather than forcing the user to stick with a single matching
contact. This is done to give more functionality to the user and to enable him
to perform actions (log emails, create opportunities...) on other contacts
and not only on the matched contact. Also add the ability to log emails into
contacts.
Legacy and deprecated routes/methods/actions have not been deleted in order to
ensure that older versions of the plugin would still work after this update,
these are now marked with a comment.
See sub commits for more details about this PR's content and technical
challenges.
LINKS
Task-2427737
closesodoo/odoo#66139
Com-pr: odoo/odoo#66139
Ent-pr: odoo/enterprise#16913
Upg-pr: odoo/upgrade#2156
Related: odoo/upgrade#2156
Related: odoo/enterprise#16913
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit the latest posts snippet implemented the lookup for
its templates and its rendering procedure.
After this commit a new blog posts snippet is introduced which relies on
the dynamic snippet mechanisms.
task-2477207
https://github.com/odoo/odoo/pull/67334
The purpose of this commit is to isolate the move operations that happen
before the refactoring of the blog snippet into a dynamic snippet so
that the refactoring diffs can be understood.
task-2477207
https://github.com/odoo/odoo/pull/67334
This commit adds support for searching multiple contacts using a text query in
the email plugin rather then forcing the user to stick with a single matching
contact. This is done to give more functionnality to the user and to enable him
to perform actions (log emails, create opportunities...) on other contacts
and not only on the matched contact.
It also brings the following changes:
- Enable the user to create a lead with the email message being directly set
in the description field, as the user would probable want the email message
to be included in the lead, this is done through the "crm_lead_create"
method, which the plugins will use in order to create the lead and send the
related information, the plugin would then directly redirect the user to the
lead form view realted to the created lead in edit mode.
- Extra information about the contact (leads, tickets...) are returned directly
with the contact using the _prepare_contact_values method which other modules
could override by adding new keys in the returned dictionary to provide more
data, this is done in order to eliminate the need for the get_modules method
and also to avoid adding new routes in the sub modules, it also eases the
future maintenance of the plugins as we can freely add new data without
breaking older versions of the plugins
- Adds the ability to log emails into contacts, and refactors the logging
method to make it able to log emails into all "loggable" models, these
models are returned by the mail_content_logging_models_whitelist method
which can also be overriden in sub modules to add new loggable models,
Thus eliminating the need for creating new routes/methods in sub modules
if we want to log emails into new models
- In case the partner is present in the database, no longer implicitly enrich
and link a company to the partner, as this can lead to some undesired
behaviour (the partner will for example have his related invoices with the
newly linked company header), the user would still be able to do this but
only if he explicitly clicks on the enrich button, for this reason the new
"res_partner_enrich_and_create_company" route has been added in order to
enrich a partner if the user wants to.
- Add a state to Odoo to know which script Gmail should execute when the
user is redirected to Gmail.
- change route names from mail_client_extension/... to mail_plugin/...
because the old mail_client_extension makes route names too long and
is too verbose.
Legacy and deprecated routes/methods/actions have not been deleted in order to
ensure that older versions of the plugin would still work after this update,
these are now marked with a comment.
Task-2427737
UPG-PR: https://github.com/odoo/upgrade/pull/2156
COM-PR: https://github.com/odoo/odoo/pull/66139
The tour bubble "animation" that makes it to bounce up and down can cause
issues when its position is at the edge of the bottom of the screen.
In the CRM tour, this would make the window constantly resize to show a
scrollbar and then resize to hide the scrollbar, creating quite a sickening
effect visually.
While waiting for a more "robust" solution on the framework side, we solve this
occurrence of the issue by simply moving the tooltip position on top of the
button instead of below it.
Task-2476595
closesodoo/odoo#68470
X-original-commit: cdb7a8ad7647649ad8f595454aa9dc0464117568
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
- split the mail_client_extension module onto two modules:
1) module mail_client_extension having mail/contact specific code,
depends on iap and contacts only
2) module crm_mail_client_extension having crm specific code,
depends on CRM and mail_client_extension.
Purpose is to allow the user to use the mail_client_extension
without needing to install CRM, this will also allow
the usage of the mail connector in other modules without
the need for CRM.
- add the module_mail_client_extension field to the
res_config_settings model of the base_setup module
in order to enable the user to install the
mail_client_extension module directly from the settings
- move the crm_lead model from the mail_client_extension_module
to the newly created crm_mail_client_extension_module, as this
model is no longer needed by the mail_client_extension module
because it no longer not implemants CRM functionality
- move the iap_enrich_api model from the crm_iap_lead_enrich
module onto the iap module as it is only related to contacts
and not to CRM, this way it can be used in other modules such
as the mail_client_extension module without the need for CRM
module
Task-2382870
UPG-PR: https://github.com/odoo/upgrade/pull/2156
COM-PR: https://github.com/odoo/odoo/pull/66139
This commit splits the code located in the mail_client_extension module into
two separate files, an "authentication.py" file containing authentication
related code and a "mail_client_extension.py" file containing everything else.
Purpose is to better organize the code and to avoid having a bloated main
controller.
This commit does not change anything functionally, it only moves and refactors
code.
Task-2382870
UPG-PR: https://github.com/odoo/upgrade/pull/2156
COM-PR: https://github.com/odoo/odoo/pull/66139
Currently the non-reserved moves in the availability report are sorted
by priority, date, id (same as reserved moves). This commit makes it so
non-reserved moves are now sorted by reservation_date first + the
previous ones (i.e. different sorting logic from the reserved moves).
The idea is to make it easier to reserve moves according to the set
reservation_method logic. Unfortunately there isn't an easy way to split
the sorting logic and we need to search for some overlapping moves
ordered in a different way.
closesodoo/odoo#65730
Task: 2418907
Related: odoo/upgrade#2143
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
yhu-odoo