This commit allows the domain field to become foldable such that it will
display its domain in the form of facets (similar to the search bar's
ones) when it is folded. Also applies this functionality directly to the
mass_mailing form view.
task-3339512
closesodoo/odoo#126789
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
Better tag selection
====================
The block was originally hooked onto the `external` tag under the
assumption that this was the tag used to allow external requests.
It's not, it's the tag for the "external" test suite, which is only
one of the test suites allowed to perform external calls. Hook again
onto `standard`, this might have some false positives (allow requests
which we'd rather block), but it should have a lot less false
negatives (block requests we want to allow).
Make Overrides Easier
=====================
Currently `_request_handler` raises a regular `ConnectionError`, this
is an issue because it passes some requests through, which could
themselves trigger genuine `ConnectionError`.
When overriding `_request_handler` to implement fallbacks for bespoke
URL mocks, these two cases need to be distinguishable as overrides
likely want to handle blocked requests, not actual failures.
Therefore `_request_handler` should a dedicated exception. This
exception should be a subclass of `ConnectionError`, so that blocked
requests are treated as regular connection failures by normal Odoo
code.
Class-scope
===========
Originally `_request_handler` was scoped on the instance with the idea
that it'd be a `mock` object, which individual tests could
`configure_mock`. This turned out not to work correctly, because
`Mock.side_effect` does not receive a `self`, hence the `Session` was
inaccessible and it was not possible to passthrough local requests.
While I moved to a regular `lambda` (because a direct method didn't
work either), I forgot to remove the `request_mock` attribute, and
didn't think that the block could now be lifted up to the class
scope. Doing this, requests performed during a "standard" test case's
`setUpClass` are now also blocked, which they very much should be.
closesodoo/odoo#128977
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
The goal of this commit is to prepare ground to remove
lazytranslate function _lt() and keep only _t()
for a better understanding of the use of the translation function.
In this commit,
the translate function _t() has been updated to return the translation
if they are loaded. If not, it throws an error.
the lazytranslate function _lt() returns _t() function.
Corollaries :
Steps in test tours are now a function that returns an array of steps
to avoid any interpolation of _t in this ones before translations has
been loaded.
Example :
registry.category("web_tour.tours").add("example", {
test: true,
steps: () => [
{...},
{...},
],
});
task-3292454
closesodoo/odoo#124157
Related: odoo/enterprise#43153
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
The Reserve Bank of India (RBI) issued a directive (amended subsequently
in December 2020 and March 2021) that introduces additional security
measures for recurring payments on India-issued cards. These measures
include:
- Banks must register cardholders and create an e-mandate through a
one-time process, using additional factor authentication (AFA)
like 3D Secure (3DS).
- Banks must alert cardholders at least 24 hours before charges take
place and give them the ability to opt out of transactions.
- Recurring transactions over 15,000 INR (or equivalent in other
currencies) must go through AFA each time.
Stripe has worked with a partner platform to support that, but we must
manipulate the PaymentIntent and SetupIntent objects directly through
their dedicated API, which the Checkout API does not allow. Therefore,
we must now integrate with the Elements API and implement a direct
payment flow instead of the current payment with a redirection flow
powered by the Checkout API.
After this commit, Stripe will create an e-Mandate for every
Indian-based card newly saved in Odoo.
task-3322020
closesodoo/odoo#123573
Related: odoo/documentation#4719
Related: odoo/upgrade#4748
Related: odoo/enterprise#42196
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
When the loader takes a long time before having a website ready to be
shown (due to many features selected), it is confusing for users who
think the page stopped working. They tend to refresh the page, provoking
bugs. To improve the UX, this commit adds:
- a browser warning to prevent the user from closing the tab/refreshing
- several waiting sentences, depending on the features chosen by the
user (the screen switches between them every 10 seconds)
- a loading bar whose progression shows the number of installed modules
- a solid background instead of a transparent one as there is no value
in seeing the preceding background at that point
This commit also removes the secondary loader, once the website has been
created, to avoid the bad UX of having one long loading, then a refresh,
then another loading with the same look.
task-3100223
closesodoo/odoo#118525
Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
*: web_tour, website
When no transformation is applied on an image, changing the quality
sometimes increases its storage size.
This commit makes sure that the original image remains used if only the
image quality is modified and if this makes its storage size bigger.
Fixes#61619
task-2835144
closesodoo/odoo#103398
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit extracts the calculation of the number of bytes within a
base64 data URL to a method named `getDataURLBinarySize`.
task-2835144
Part-of: odoo/odoo#103398
With ab4f45b, the domain validation done
on confirmation in the domain selector dialog was removed. Now that we
have a new route /web/domain/validate (see previous commit) that allows
us to quickly check the validity of a domain, we can reintroduce the
validation.
closesodoo/odoo#128913
X-original-commit: fa7788fac3c48e95dcbe78abb66ac5c284d27c56
Related: odoo/enterprise#44291
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
When a domain field value is edited via the debug textarea, no
search_count is done for performance reasons. A single exception is done
when saving the record. Then we check the validity of the domain created
in the debug textarea in order to avoid to save an invalid domain in db
(and get tracebacks,..). The problem is that a search_count can take a
very long time to be executed if the domain is valid. Here we introduce
a route /web/domain/validate in order to quickly check the validity of a
domain and use it in domain field in order to fix the above mentionned
performance issue. Note that the search_count is still done if it useful
but does not have to be waited anymore.
X-original-commit: 40288221c39ff8fba41cd6ac231ab33600dc0cd4
Part-of: odoo/odoo#128913
Co-authored-by: Oliver Dony <odo@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Currently, users cannot deregister from Peppol.
There is an option to migrate away (i.e. request a migration key) but not every provider supports migration.
It is not straightforward to deregister from Peppol once a participant is marked as "prepared for migration",
so the users really should deregister instead.
Also, it is important to run the cron one last time for the user to fetch new documents/message status updates
they've received since the last time the cron ran.
closesodoo/odoo#128867
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Step to produce:
=================
- Create MO of serial tracking product.
- Start workorder.
- Click on continue consumption button.
- Enter quantity to consume then click on validate button.
- Then when we click on Continue button quantity become zero or negative.
Issue:
========
If the product tracking is serial and quantity is already set to 1 in this case
it write the same 1 value in serial tracking order because of that it calls
'_update_component_quantity' method again it will make the quantity zero.
After this commit:
=====================
Prevent the quantity becoming zero.
Task id: 3212121
closesodoo/odoo#128665
X-original-commit: 907129be7efba2a0b68f9bef14c6a22c1be8861a
Related: odoo/enterprise#44183
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
The goal of this PR is to remove all dependency to legacy assets in the wysiwyg because the wysiwyg is loaded on a lot of form view through the html_field, thus defeating the purpose of the legacy assets being lazy loaded.
To remove the dependencies, all the legacy widget that the wysiwyg uses had to
be converted to owl. In order to finish the PR faster, only a partial conversion
of the widgets is done, changing only the part of the code that was necessary
for it to work instead of rewriting the whole widget from scratch. Another pass
should be done to convert all those widgets to fully embrace the owl paradigm.
task-3175256
closesodoo/odoo#118966
Related: odoo/upgrade#4750
Related: odoo/enterprise#42141
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
The goal of this commit is to remove all dependency to legacy in the
wysiwyg because the wysiwyg has to be loaded on a lot of form view
(through the html_field).
To remove the dependencies, all the legacy widget that the wysiwyg
uses had to be converted to owl. In order to finish the PR faster,
only a partial conversion of the widgets is done, changing only the
part of the code that was necessary for it to work instead of
rewriting the whole widget from scratch. Another pass should be done
to convert all those widgets to fully embrace the owl paradigm.
task-3175256
Part-of: odoo/odoo#118966
In a subsequent commit, the ImageCropWidget will be converted into
an Owl component called ImageCrop. To match the new name, this commit
rename the file.
task-3175256
Part-of: odoo/odoo#118966
In order to match the filename with the only classname of that file,
this commit rename `wysiwyg.js` to `MassMailingWysiwyg.js`.
task-3175256
Part-of: odoo/odoo#118966
Before this commit, when recurring meeting were created with alarms, there were
as many cron trigger created as there were events in the recurrence.
After this commit, only one trigger is created for the first event starting in the
future and the next cron trigger is created once the trigger of the first event is
called by the cron.
closesodoo/odoo#118738
Taskid: 3270442
Related: odoo/upgrade#4706
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Before this commit, when a ir.cron was walling _trigger, the ir.cron.trigger
records were not returned. it would prevent to use them later easily without
making a search.
Taskid: 3270442
Part-of: odoo/odoo#118738
Before this commit: Body content is the same as tmeplate
After: Body content is the same as the template
*: hr_recruitement, sale, survey, website_slides
closesodoo/odoo#128953
X-original-commit: 388e340a52fd5775c1702f8952a1e959fa5cef48
Related: odoo/enterprise#44309
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
To reproduce:
1. Create a new mail group with privacy "Everyone"
(menu: Website / Configuration / Mailing Lists / Mailing Lists)
2. As an anonymous user, go to /groups and click on its name
3. A 403 Forbidden error is displayed:
`You are not allowed to access 'Email Aliases' (mail.alias) records.`
This commit is a followup of odoo/odoo@cd2f330bec where global
mail.alias access rights were revoked, so we have to check if alias
is valid as superuser.
closesodoo/odoo#128915
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, only the cross icon "x" top right of the popup would
be able to properly close the popup and set a cookie to prevent that
popup to open again later.
There is no way through the UI to make a button in the popup do the same
behavior.
This commit now add this behavior to any `.btn-primary` element inside
the popup, except a few ones like the newsletter input group button and
the website form submit one.
Note that we have a way in stable to do that, but it's through code.
People have to add the `js_close_popup` class to the button. This class
is there for this reason, but it's obviously limited to tech people
only or our support.
task-3377306
opw-3328135
closesodoo/odoo#124432
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
**Description of the issue/feature this PR addresses:**
- Increase user experience in creating website themes
- Eliminate redundant creation of 1 record leading to unnecessary model
`ir_model_data` contraints error
**Recreate the Situation**
- Install the website module
- Choose `a business website` in line 1, `fashion designer` in line 2,
`get lead` in line 3 on `configurator - step 2`
- Choose random paletee on `configurator - step 3`
- `Build my website` on `configurator - step 4`
- Suppose in this step that we have a bad connection to the api
`https://website.api.odoo.com`, the error `duplicate key value violates
unique constraint` will appear.
**Reason**
- When a user creates a website, the `configurator_apply` function is
called to the api `https://website.api.odoo.com`. If the connection time
exceeds 5s, the `configurator_apply` function will be called again.
Maximum of 3 times
- Each time `configurator_apply` function runs, will create records of
model `ir_model_data` at `set_images` function. This function will
create records with a name field like
`configurator_1_s_cover_default_image`.
- If this function runs again for the second time, it will also generate
a `configurator_1_s_cover_default_image` for the second time. This will
result in a `duplicate key value violates unique constraint` error.
**Before commit:**
- When creating a website theme by industry, if the user's connection to
odoo's api has a delay, it will cause an api contraints error of model
`ir_model_data`
**After commit:**
- Check if the record of model `ir_model_data` has been created before,
if created then skip
closesodoo/odoo#128959
X-original-commit: 56ccf4efeb946e2e0b6ef54b977b6d8b070306ee
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
In Switzerland, states are really important. Each state has its rules, its
language, its culture, its parliament, etc. It's quite frowned upon to send an
invoice/offer or even to have backend management using German terms when we're
in a very French-speaking state.
So in this PR, we will add states in the missing languages
closesodoo/odoo#128954
Task: 3268058
X-original-commit: f309fd06cd46a767fee742ec9f634b46a2edf70f
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Before this commit, livechats in mobile were shown in the "Chat"
tab in both discuss app and messaging menu. This is alright, but
there's a dedicated tab for "Livechat", which was empty as a result.
The intended showing in mobile is to keep livechat away from "Chat",
and instead populate the "Livechat" filter.
Task-3430253
closesodoo/odoo#128934
X-original-commit: cf4b72582bbb52c7cd4bc17733f4dbbc84f9b321
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
If an inactive currency is given as company currency write values,
it is unarchived, but before the company update.
Therefore, if the unarchiving of the currency enables the multi-currency,
a default pricelist will be created for the company, but with the wrong
currency since it still wasn't updated.
This commit postpones the automatic creation of pricelists after the update
of the company, making sure the currency of the pricelist is the expected one.
opw-3423706
closesodoo/odoo#128958
X-original-commit: f7c90e4e1c5b6a3335e7c9b9e209a786d4238434
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
In the context of an urgent htmlField `commitChanges`, there is no time to wait
the response of `rpc` calls, therefore this commit proposes to use the same
strategy as `_toInline` for `savePendingImages` and not await the result of
the promises before a first `updateValue` if the commit is `urgent`.
This will allow to save most of the changes during a `beforeunload` scenario.
ENTERPRISE PR: https://github.com/odoo/enterprise/pull/42644
task-3372343
closesodoo/odoo#128949
X-original-commit: ba94629cb7fd1381871c37d34104f2511a4d4863
Related: odoo/enterprise#44307
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
In 9deb1e6aa902a09c4f invisible duplicate were added for boolean groups.
But the added test could fail on master when installing only base
module: in this case, there is only the group "base.group_allow_export"
that is shown as a selection group because it is the only field of its
category. When we install other module, the field become a boolean group
that is handled by the aboved mentionned commit.
The previous fix and test didn't take this case into account, with
customization this could be a real issue.
With this commit, hidden selection field are also handled and the test
test_reified_groups pass in master when installing only base.
related to #120310closesodoo/odoo#128944
X-original-commit: b22fc41d63bded2435cd330517d407abab5035ee
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Before this commit:
In table selecting a list and on deletion/backspace page crashes.
After this commit:
The selected list is now deleted.
task-3383168
closesodoo/odoo#128943
X-original-commit: c7d3d247269ce27a10da39df5848cc10f9f6627b
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The number of invalidation during the test is quite large and
the crons cal also spam this log sometimes.
Waiting for further cleanup, removing this log to avoid spaming runbot
logs and making them harder to read.
closesodoo/odoo#128921
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Purpose:
--------
This commit makes the the avatars shown in many2one properties in kanban
cards smaller, as they were abnormally big.
Task-342200
closesodoo/odoo#128912
X-original-commit: 9ae4be80c68faafd7a09ea3cbeaf45e9b8eeaa71
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Before this commit, the `keydown` and `keyup` events of the call feature
were in bubble mode, which could prevent them from operating when some
other listeners would prevent the propagation of the event.
Since push-to-talk is supposed to always be usable, the listeners
are now in capture mode.
It was first made apparent with the addition of a `stopPropagation()` in
the `chatWindow` here: https://github.com/odoo/odoo/pull/127638closesodoo/odoo#128897
X-original-commit: 1466a6bc471ed583966e959b47f10bdc64837732
Signed-off-by: Didier Debondt (did) <did@odoo.com>
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
This commit partly reverts 59afbf6686 and
provides an alternative solution. In this solution, records.web_read()
returns a list of dicts where the key 'id' corresponds to each record.id
in records, which enables to reliably relate each record to its values.
This also fixes the implementation of web_read() on new records where
the fields contain a reference field with some context.
closesodoo/odoo#128878
Signed-off-by: Raphael Collet <rco@odoo.com>
Considering the valid odoo version in the manifest version
The message before of this commit was:
Modules should have a version in format ``x.y`` or ``x.y.z``
It looks like it enforces to removing the odoo version part as invalid
But it is not, in fact, it is already supported
It is important since OCA enforces ``{odoo.version}.x.y.z`` format
It was already discussed here:
- https://github.com/odoo/odoo/pull/118420#issuecomment-1635047100
The message after this commit is:
Modules should have a version in format `x.y`, `x.y.z`, `16.4.x.y` or `16.4.x.y.z`.
Notice the Odoo version "16.4" is the current {odoo.version} for the moment this commit was done
It avoid confusing about the valid formats to use
closesodoo/odoo#128810
Signed-off-by: Christophe Simonis (chs) <chs@odoo.com>
The opportunity is taken to make the feature reactive.
Also fix traceback if favorites can't be fetched from external API.
Part of task-3265211
Part-of: odoo/odoo#128799
This commit uniformises the different discuss option
panel by introducing a dedicated component.
Before this change, every single discuss panel would
look different: font size/weight, text in lower/upper
case, margins...
Moreover, in the chat window, the close panel button
was absolute positionned which could overlap with the
content of the panel. Moreover, the cross icon looked
strange with the one of the chat window header.
This commit introduces the `ActionPanel` component in
order to solve those inconsistencies and replaces the
cross icon by an arrow left one.
part of task-3332872
closesodoo/odoo#128742
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
*: point_of_sale, pos_adyen, pos_hr, pos_mercury, pos_restaurant
Adds online payments in Point of Sale using the payment module.
The pos_online_payment module is meant to be used by shops for paying online instead of using a physical terminal and by restaurants for paying an order either from the paying station or in the self-order process (smartphone used to order and pay online).
The module depends only on point_of_sale (and account_payment to support online payments).
The online payments support for self-order will be added in another commit.
The feature can be used by configuring a special pos.payment.method for one or many pos.config.
Operation:
The frontend session user can enter one or several online payment method lines (with or without other payment methods).
When he validates the order, if the online payment amounts are valid, a popup with a QR code is displayed on the frontend screen and on the customer display. This QR code allows the customer to open the payment page to pay online for the order.
The amount to pay for an order on the payment portal is the remaining unpaid amount or a lower amount if several online payments lines are used. Therefore, at any time, the customer will be able to pay the amount of the order that is unpaid, without requiring a staff operation to update the amount to pay.
When an online payment is done for a POS order, the generated account.payment is linked to the POS order through a pos.payment that is created with the online payment method configured for the pos.config, and the POS order paid process is triggered (it is the responsibility of the server to finalize the validation of POS orders that have at least one online payment, and not the responsibility of the POS session web client). If for any reason, there is no longer any online payment method configured for the pos.config of the order, a new one can be created automatically and exceptionnaly used to link the done payment with the POS order. This guarantees that any online payment saved by the payment module will be linked to the POS order.
The session web client is notified of successful online payments through web socket communication, to make the cashier screen automatically and quickly react to payments.
If several online payments are used for a single POS order, they are processed one after each other.
Working principles:
- The POS session web client is not allowed to save online payments on the server. Only the Odoo server, which handles the payment, can save online payments for a POS order.
- The POS session is only responsible for saving the order (especially other payment methods) and the next online payment amount to pay (in case of several online payments) on the server before the online payments are made by the customer, and for displaying the online payment status and the link (QR code) to open the payment page.
That means that modifications that are made after the order is fully paid are not taken into account by the server.
- Before validating an order, the POS session checks with the server if any online payment has been made for that POS order. If the user wasn't aware of one, the validation process is aborted, notifying him.
- The sensitive online payments data is received by the frontend user with RPC to the server when validating an order, cancelling an online payment or receiving a notification through the POS bus (web socket communication).
This data is used to update the cashier data for the specific order.
- No sensitive information is sent through the POS bus (web socket communication).
Indeed, the bus communication is only protected by the name of the channel, and there is no mecanism to prevent several attempts. Therefore, no sensitive information is sent through it, only a notification to invite the local browser to do a safe RPC to the server to check the new state of the order.
- Online payments for a POS order cannot be modified or removed when they succeeded. Checks ensure to never allow an online payment to make the total paid amount greater than the total amount of the POS order.
- If the frontend user clicks on the "Cancel" button of the online payment popup, the order can potentially still be paid online. Indeed, the order will be removed from the server only if it was added only for the online payment flow, and any order that is not paid can be paid on the online payment portal (if the customer has the web link).
This behavior ensures that in a shop, starting an online payment and then cancelling it doesn't prevent the user to close the POS session. And it ensures to don't delete a draft order that is used for other flows, like in a restaurant or when there are trusted POS configs.
Payment portal features:
- The payment portal pages of a POS order are protected with its access_token.
- If the amount of the order has changed when the customer clicks to pay, an error is fired to notify him and give him the choice to continue or abandon the payment.
- An exit_route argument (an URL) can be passed to allow the customer to exit the payment portal at any time (with a button), which could be used for self-order flow.
- A button to go back to the payment page is displayed when an error occurs during a payment transaction, which allows the customer to retry a payment without needing to scan again the QR code.
- If the customer is not logged in in the payment portal (most frequent case), it is considered as the public user partner for the payment flow to don't give him privileged access to sensitive data like payment tokens.
- The accounting process of online payments for POS orders is made in the same way that the pos.payment.method that have split_transactions to True.
- The POS customer of a POS order has no link with the customer making an online payment for that POS order.
- The payment portal is made using the pos.order id and not the pos_reference because the latter is not guaranteed to be unique.
Some tests have been written, especially one that simulates a whole online payment flow starting from nothing, creating an order, requesting an online payment, faking this online payment by doing web requests to the payment portal, then finally closing the POS session to check that there is no accounting issue.
The design of the payment portal is temporary.
closesodoo/odoo#123237
Task-id: 3276404
Related: odoo/enterprise#41776
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Purpose
=======
Make it possible to attract attention to a small section of a text document (e.g. task spec, knowledge article, etc.) via a new "bloc" called "Banner".
Specifications
==============
Add 4 commands in web_editor.
Each command will add a banner of the following types and will come with their associated icons:
- Banner Info: alert-info - info-circle
- Banner Success: alert-success - check-circle
- Banner Warning: alert-warning - exclamation-triangle
- Banner Danger: alert-danger - exclamation
Task-2782426
closesodoo/odoo#120690
Related: odoo/enterprise#41716
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
Make it possible to attract attention to a small section of a text document
(e.g. task spec, knowledge article, etc.) via a new "bloc" called "Banner".
Specifications
==============
Add 4 commands in web_editor.
Each command will add a banner of the following types and will come with their
associated icons:
- Banner Info: alert-info - info-circle
- Banner Success: alert-success - check-circle
- Banner Warning: alert-warning - exclamation-triangle
- Banner Danger: alert-danger - exclamation
Task-2782426
Part-of: odoo/odoo#120690
Julien Carion (juca)