Before this commit:
There is an obsolete method 'channel_fetch_listeners' which is not needed now.
After this commit:
Removed this obsolete method.
Task-2827899
closesodoo/odoo#91876
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
*: account_payment, sale, website_sale
Users should not be able to discard the tokenization of their payment if
they pay for a subscription.
This commit introduces a new helper method to better predict when the
tokenization checkbox should be shown or hidden. This also ensures that
the behavior will be the same across all modules.
task-2695201
closesodoo/odoo#91860
X-original-commit: 1d8dc53f8ed2a967b35213bc913cdfbc42ff15bc
Related: odoo/enterprise#27568
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Prevent edition on e-commerce products header bar.
Since we cannot save any change done in the header object anyway,
And some edition would trigger error.
We put the all bar in a read-only mode.
task-2745151
X-original-commit: e2f7b8fad76dc816b2f6864340d3740446117cdb
Part-of: odoo/odoo#91840
Set `phone` and `mobile` fields on `res.partner` to unaccent=False since phone
numbers are unlikely to have any accent. This will also make it easier
to add indexes on these fields in the future.
Part of task-2832241
closesodoo/odoo#91788
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
In some case, when removing format on element with multiple textNode,
the code generate a traceback.
The loops in `toggleFormat` provide a limit element `closestDecorated` to
the `splitAroundUntil` util. However this limit element can be split and
dumped by the format removal. In this case the reference was never encountered
in the DOM by the `splitAroundUntil` code and will bubble all the way to the
`<html>` TAG an try to split it, which generate an error.
We fix it by getting the `closestDecorated` in every loop.
task-2850686
X-original-commit: 2d93345c38f55c276370d0059d562d28320db2fb
Part-of: odoo/odoo#91786
Add some unit test for strikeThrough format.
Those tests reveal some bug in the current formating code.
task-2850686
X-original-commit: 4d8e1dc381d01bb254d2e806a335a40733608f2e
Part-of: odoo/odoo#91786
This commit improves the layout of the `o_RtcActivityNotice_button` to
increase its visibility.
task-2853027
closesodoo/odoo#91289
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Purpose
=======
In this commit, we will fix the loops that occur when you send an email
to an alias (to create a ticket e.g.). In that case Odoo can reply
"Your ticket has been created" and then the auto-replier of the user
can reply to this email and the loop occurs.
Specifications
==============
To solve this issues, we add 2 system parameters
- <mail.gateway.loop.minutes>, 120 minutes by default
- <mail.gateway.loop.threshold>, 20 by default
When an email is sent to an alias, we look on the last records created
<mail.gateway.loop.minutes> minutes ago. If we overcome the limit
<mail.gateway.loop.threshold> the email is ignored.
Alias creation detection
========================
To detect the number of records created by a specific email address we
use the `_primary_email` attribute set on the model.
Task-2294034
closesodoo/odoo#78597
Related: odoo/enterprise#21772
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When customer pays for the order and cashier validates it and creates new order, customer screen does not update.
This means that new customer can still see the previous order until cashier starts adding new products to empty order.
With this fix customer screen will update after cashier clicks on "New Order" button.
fixes OPW-2734487
closesodoo/odoo#91868
X-original-commit: c8c7a2f9da1d0f5b6e0725f56269d7e4b4802d80
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Total invoiced is computed with `active_test=False` [1], however the
corresponding action didn't have that context. Since Odoo 14 `child_of` domain
filters out unaccessible records (including archived ones) [2].
Fix it by adding the context to the action.
STEPS:
1. Have a active contact that has an amount invoiced (invoices pointing to this contact name).
2. Click through on the amount invoiced button, and receive a list of relevant invoices.
3. Now go back to the contact, and archive the contact.
4. The smart button containing the amount invoiced stays the same.
5. Click through on the smart button again
BEFORE: no invoices
AFTER : listed invoices corresponds to the computed total value
[1]: https://github.com/odoo/odoo/blob/574ca75ab6fa583aabc0c1cfc65206e72864e546/addons/account/models/partner.py#L379
[2]: https://github.com/odoo/odoo/commit/3e1b960acf3f6a726338476ba9e62e5ef5c84ef9
opw-2853525
closesodoo/odoo#91828
X-original-commit: bf96188abbf8ad19d1a2f8f82a1e6248245778b5
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Ivan Elizaryev (iel) <iel@odoo.com>
This commit adds a test to make sure the timesheet linked to
the task is no-billable.
task-2723662
closesodoo/odoo#88889
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
This commit adds a test to check the email is correctly sent when the email
is linked to a project stage and a project arrives in that stage.
task-2723662
Part-of: odoo/odoo#88889
This commit adds a test to ensure the timesheet linked to a SOL is
linked to the invoice of the SOL when the SO containing this SOL is
invoiced.
task-2723662
Part-of: odoo/odoo#88889
tasks assigned to the current user should be in the 'inbox' stage by default.
tasks with no project set should only be visible to the users assigned to them.
task-2723662
Part-of: odoo/odoo#88889
-Test the creation of sub-tasks through the notebook
-Set a parent task on an existing task
-Test the creation of sub-sub-tasks
-Check the correct nb of sub-tasks is displayed in the 'sub-tasks' stat button
and on the parent task kanban card
-Sub-tasks should be copied when the parent task is duplicated
-The parent task should take into account the timesheets of its sub-tasks
task-2723662
Part-of: odoo/odoo#88889
Step to reproduce:
Install purchase, stock and accounting
Create a product in a database with USA localization.
Create a new product category and select the manual valuation option.
Purchase the item, receive the item and create the Vendor bill
Current Behavior
On the journal entries you will see that the stock interim accounts
are impacted (the accounts uase for an automated stock valuation)
Expected Behavior
The used account is expenses
Explanation:
The problem comes from the fact that we don't reset/set these accounts
when changing the property valuation of a product category.
opw-2746384
closesodoo/odoo#91811
X-original-commit: 2cb9c7afb2d9e096f0c8e1ada2908b720b6e5ade
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Fockedey Martin (mafo) <mafo@odoo.com>
This feature isn't available as of now, and users that wants to do
this would have to use the similar report in Sale as a workaround.
As this is not always possible nor great, introduce this new measure
to display the line total tax included.
task id #2831312closesodoo/odoo#89654
Signed-off-by: Florian Gilbert <flg@odoo.com>
Upon deleting a column in the project task view a popup will be
displayed warning the user that the stage will not be deleted but
instead archived.
Prior to this commit that popup would be displayed regardless of the
group by option that is selected. However this could lead to issues when
opening the archive wizard with an id from another record.
closesodoo/odoo#91872
X-original-commit: 24d307716cbd9e05a32dde108838e16d04309116
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
* use the latest translation API (with fallback on english text if
translation doesn't include expected placeholders)
* indent/split translations to avoid excessive line lengths
closesodoo/odoo#91743
Signed-off-by: Julien Castiaux <juc@odoo.com>
The pa index should only be XXXXXXX when the foreign partner is not
identified. In this commit we change the condition on the template such
that if the pa index is defined, we always utilise it. If the pa index
is not defined but the partner is italian, we use '0000000', and when it
is not defined and the partner is not italian, we use 'XXXXXXX'.
closesodoo/odoo#91871
Task-id: 2858092
X-original-commit: bf468affa2d86967b3b63a0be62063061b7b263c
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Daniel Kosky (dako) <dako@odoo.com>
Add move_reverse_cancel=cancel back to context when reconciling moves with reverse moves.
Bug introduced in commit https://github.com/odoo/odoo/commit/e9262bfc8c775953ebe150f36ce0ab8dcb04d4bd
Database : Reproducible in v14, v15
On a Mexican company (with l10n_mx) with multi currencies enabled.
- Set rates for USD to be different at invoice and at payment date
- Create an invoice at date 1 in USD
- Create a payment at date 2 in USD for invoice generating a difference exchange move
- Try to reset the payment to draft
-The traceback (ZeroDivisionError: float division by zero) will appear.
Tickets : 2857549, 2856162, 2855038, 2852663, 2852859, 2857381
closesodoo/odoo#91841
X-original-commit: 7be0fc1d611d54f27ebd7e7b1fef9b1842cc9ae2
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Since Chromium 97, folded `<details>` content has non-zero computed
width and height which returns false-positive QUnit
`assert.isNotVisible()` calls.
In a nutshell, this was introduced in https://bugs.chromium.org/p/chromium/issues/detail?id=1185950
when Chromium implemented the ability for "Find in page" to search in folded
`<details>`. To do so, the `content-visibility` rule was used instead of
`display: none` which, even if functionally similar, has an impact on the
values returned by `getBoundingClientRect()` (i.e. used in
`assert.isNotVisible()`.
A regression report was filled in https://bugs.chromium.org/p/chromium/issues/detail?id=1276028
to highlight this change of behavior. What emerged from this report's
discussion is that Chromium has no intent to revert this change and
instead put the emphasis on avoiding to use `getBoundingClientRect()`
and similar methods for visibility check (even pushing a proposal for a
`Element.isVisible()` API; cf. https://github.com/w3c/csswg-drafts/issues/6850).
This commit works around this issue by forcing the content to `display:
none`, like in the previous Chromium versions.
closesodoo/odoo#91833
X-original-commit: b718e7eb5ceb827f59ac395577408b7bc54aa3f9
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Purpose of this commit to improve generic usage of project
app.
So, in this commit done following changes:
- change the placeholder of the name to 'e.g. Monthly review' in
project_update_view_form
- set the 'analytic account' of the project on the tasks by default
- change the placeholder to 'e.g. Product Launch' in project_milestone_view_form
- the 'cabinets' milestone should be linked to a milestone service,
not a manual one so change data to milestone in demo data
- rename the 'rating' stat button into 'last rating' in view_task_form2
- set another employee than Mitchell for the 'customer care (prepaid hours)'
SOL field in sale_service_demo_data
- display a separator on the right of the stat button so remove unwanted
properties in project_rightpanel.scss
- add the 'name' field to the 'fields to export' when 'i want to update data'
is set to true
- remove the 'Getting Things Done (GTD)' example from kanban examples wizard
- add a 'tasks due today' filter that should return tasks whose deadline falls on
today's date in view_task_search_form
task-2809188
closesodoo/odoo#88271
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Profiling: creation of ir.profile records for each models population
Rollback: allow triggering multiple times the same population,
without any risk of records conflicts (& having to recreated a clean database)
Note: those two options are mostly recommended for small models population.
Indeed, profiling slows down the population, and large/medium population is
already quite slow for some models (and it seems that the rollback breaks as well
for some advanced models).
Part-of: odoo/odoo#85537
When moving some products between two warehouses thanks to an internal
transfer, the forecasted inventory becomes incorrect
To reproduce the issue:
1. In Settings, enable "Multi-Warehouses"
2. Let WH01 be the existing warehouse. Create a second one WH02
3. Create a storable product P
4. Update the quantity of P:
- 3 in WH01/Stock
5. Create a planned and internal transfer T:
- Source: WH01/Stock
- Destination: WH02/Stock
- Ignore the warning
- Operations:
- 1 x P
6. Mark T as todo
7. Open the Forecasted Inventory:
- Filters:
- Forecasted Stock
- Product: P
- Group By: Warehouse
Error: The report is incorrect, it says there are 3 P in WH01 and 0 in
WH02 (should be 2 and 1). It becomes worst if T is done (the quantities
in the past become incorrect)
We should be able to move a product between two warehouses thanks to an
internal transfer (so the warning of the step 5 should be removed).
Moreover, the `report.stock.quantity` should consider that use case.
When processing a stock move, the SQL view translates it as an in-move
or out-move for a specific warehouse. For instance, if the SM comes from
a warehouse and goes to a location without any warehouse (e.g., customer
location), the SM is considered as an out-move. But here is the issue:
in case of an inter-warehouse SM, both source and destination have a
defined warehouse.
Therefore, we need to:
- Duplicate the inter-warehouses SM (so we have one in and one out)
- Fake the values (no destination warehouse for the out move, no source
warehouse for the in move)
Also, before duplicating all SM, we filter out some useless SM:
- Draft and cancelled ones
- SM done more than 3 months ago (because the report only works for [-3
months; +3 months])
Considering some tests:
(SM are confirmed. Each test has been repeated 5 times to get an
average)
| | |
|:-------------------------------------:|:--------:|
| 5000 SM, 0% inter-wh, without the fix | ~715 ms |
| 5000 SM, 0% inter-wh, with the fix | ~710 ms |
| Impact | 0.99x |
| | |
| 6666 SM, 0% inter-wh, without the fix | ~911 ms |
| 5000 SM, 33% inter-wh, with the fix | ~999 ms |
| Impact | 1.10x |
| | |
| 7500 SM, 0% inter-wh, without the fix | ~1004 ms |
| 5000 SM, 50% inter-wh, with the fix | ~1097 ms |
| Impact | 1.09x |
The impact is not that significant
OPW-2752017
task-2822157
closesodoo/odoo#91772
X-original-commit: b1efc0243bbf886bbef42a32587f4a818fa34e64
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
When creating a quiz, the answers were not displayed in the
many2many_tags and void tags were displayed.
This commit ensures that the answers is always displayed even
if the record is not yet created.
task-2849896
closesodoo/odoo#91770
X-original-commit: d9223a280ad386e671359a9633efddf424b371d6
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Until now, when we add to patch the ui size, we would have patched one of the following:
- config.device.{isMobile,size_class}
- (wowl) env.isSmall / env.services.ui.{isSmall/size}
- (legacy) env.device.isMobile
- (legacy/wowl) browser.innerWidth
The issue is that patching one does not affect the others resulting in an incoherent state.
In order to ease ui size patching, the `patchUiSize` method has been introduced. This method
take either a size or a width as parameter (eg. SIZES.SM, 1920) and affect all the properties above.
task-2582313
closesodoo/odoo#91540
Related: odoo/enterprise#27428
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Improves UX by adding placeholders to clarify the purpose of some inputs and
changing some field layout to ease the edition (with the use of multi-lined
editor).
Details:
Some placeholders have been added:
- description field of survey.question
- default_note field of mail.activity.type
- summary of mail_activity_type_view_form
Some field layout have been turned into multi-lined editor:
- default_note field of mail.activity.type
- write a message in mass mail mode (email_compose_message_wizard_form)
added border for field help of edit action (class oe-bordered-editor)
Task-2766291
closesodoo/odoo#85046
Related: odoo/enterprise#24599
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Prior to this commit an user could try to add a product to cart that does not
exist anymore because it was deleted while the user /shop page wasn't refreshed.
This commit avoids this (rare) use case to happen.
TaskId-2835736
closesodoo/odoo#91752
X-original-commit: 7aeec2921d7159f0c7fa4c8caf2d00f802c69264
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Steps to reproduce:
- Have two companies set up
- In settings, check for company 2 the Files Centralization
- For a Product, upload a document
Issue:
The document will not appear in Documents.
It will only appear if the option is checked for company 1
Cause:
The company_id is not fetched correctly throughout the process.
There is a similar solution for the specific `documents` upload route:
https://github.com/odoo/enterprise/blob/bdf712d66c3e5cee70a6b424b69a618fe655a39f/documents/controllers/main.py#L147-L149
Solution:
Get the id directly from the cookies
opw-2774365
closesodoo/odoo#91751
X-original-commit: 46db92d5211c215d07448676e619154390b7147f
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: yosa-odoo <yosa@odoo.com>
Revert the possibility to install languages from the form views
of opportunity/lead and partner.
We consider that the quick installation of languages is too
advanced and admin people can go through the dedicated menu if
need be.
task-2839020
closesodoo/odoo#91750
X-original-commit: 5a616997659b2359ec946883b620e2fae6d6c39d
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit adds a unit test to check if the value of
`analytic_account_balance` field in a project is the one expected when a
timesheet is added into this project.
The analytic account balance value expected should be equal to
`timesheet_cost * timesheet_unit_amount * -1`, where:
- `timesheet_cost`: the employee cost or the cost set on an employee mapping
defined in the project.
- `timesheet_unit_amount`: the number of hours/days set on the timesheet.
task-2783686
closesodoo/odoo#87405
Related: odoo/enterprise#25006
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
This fix will try to write a new amount value on the tax when an
invoice is created from POS, that will raise a user error preventing the
creation of the order.
This reverts commit 2b9592cb0ecef235d708ed7810d0613ccd946124
OPW-2855694
closesodoo/odoo#91719
X-original-commit: d3cce0e3ae13859954d6907a3cb16fb0e1a95f86
Signed-off-by: Masereel Pierre <pim@odoo.com>
Before this commit, iframes DOM mutations were not taken into account to
update the tour manager. So in the context of mass_mailing, displaying
the web editor in an iframe, the tours were updated at the right moment
by chance (no mutations for 750ms in the global document and in the
iframe document).
This commit adds an o_iframe class, used to define an iframe that will
render a part of Odoo. An observer is added in the tour service to
monitor the addition of such iframe, and sets an observer on that iframe
to correctly update the tour manager, counting the iframe DOM mutations
for the 750ms delay.
In addition to this observer, the iframe's HTML content is added to the
final document HTML log when a tour crashes (directly between the
<iframe></iframe> for convenience, copy/pasting it in a browser just
ignores what's in between).
Also, when the tour_service is initialized in an o_iframe, it will not
run the tours.
This fix targets the saas-15.3 as it is needed to avoid a race condition
introduced with [1] (introducing a tour which relies on DOM updates
inside the mass mailing iframe). This could be backported if the need
ever rise (it should really have been the case since [2]).
[1]: https://github.com/odoo/odoo/commit/52d32e26c34bef10823582ef5c1f840492b73d7a
[2]: https://github.com/odoo/odoo/commit/971629b9fe40911c3a9765c9fb746ea1c55d3560closesodoo/odoo#91718
X-original-commit: ea35bd06c84b7101224c3b3dd24d1780e13232a9
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
There is 2 issues regarding the responsiveness of the cookiebar:
==== Problem n°1: ====
======================
By default, `.modal-dialog` receive a O.5rem margin.
```css
.modal-dialog {
margin: 0.5rem;
}
```
But it only takes effect in small resolution, as starting from SM (576px,
see _breakpoints.scss), the margin is set to 0. `.modal-dialog` receive:
```css
@media (min-width: 576px)
.modal-dialog {
margin: 0 auto;
}
```
On top of that, the `.modal-dialog` has a `min-height` of 100%, which is
getting too big in XS, as there is a 0.5rem margin, which adds up on top
of the 100%
```css
.s_popup[data-vcss='001'] .modal-dialog {
height: auto;
min-height: 100%;
}
```
It results in a modal height bigger than the screen size, ultimately
creating a scrollbar for just a few pixels (2 * 0.5rem margin), making
the cookies bar partly hidden by the screen.
==== Problem n°2: ====
======================
The buttons from the cookies bar "discrete" template are simple `<a/>`
elements inside a `div.col`.
Those links have no bottom margin like a paragraph would have.
In LG screen, it is fine as the col containing those links is next to
the other col containing the paragraph which adds the margin bottom,
making elements not stuck to the bottom edge of the screen:
------------------------------
| COL-LG | COL-LG |
| <p/> | <a/> <a/> |
| | <-- bottom margin set on <p/>
------- screen edge ----------
But in lower resolution, as both col would be on top of each other, the
`<a/>` would be stuck to the bottom screen border.
--------------
| COL-LG |
| <p/> |
| | <-- bottom margin set on <p/>
--------------
-----------------
| COL-LG |
| <a/> <a/> | <-- Against the screen bottom edge
-- screen edge --
======================
Steps to reproduce:
- Install Website
- Enable cookie bar in the Settings
- Go on the Website with a mobile screen width
opw-2784233
closesodoo/odoo#91712
X-original-commit: 843e57694dd73ed4b7fca0460a4cf9b166820843
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Claude Thibault (thcl) <thcl@odoo.com>
Co-authored-by: thcl-odoo <thcl@odoo.com>
How to reproduce:
Have 2 different tabs open on the same draft invoice
Tab 1: add a new invoice line
Tab 2: change the partner
Tab 1: save
Tab 2: save
Before the fix:
The new invoice line from tab 1 has the partner from before the change,
but the other lines have been updated to the new partner.
Expected:
All invoice lines have the same partner as the invoice itself
This use case can be reproduced like this manually, but it can happen
easily even on one tab because the OCR acts like the second tab if users
start to edit the invoice before it is scanned.
Note that in a perfect world, a warning would be raised to prevent any
loss/mischief due to concurrent editions of the same record but that's
beyond the scope of a bugfix made on a stable version.
opw-2777390
opw-2762347
opw-2741859
closesodoo/odoo#91705
X-original-commit: 2c5450af8d6f5934e6ab2095c3307b432fa3036a
Signed-off-by: William André (wan) <wan@odoo.com>
If applied, this commit will fix the following bug by fixing
the url used to ping the server
Steps to reproduce:
1- open apps with debug mode
2- click on updates
3- the server is read as if it is offline
Bug:
in ecfe85db84 all links are changed
static/src/(img|fonts) => static/(img|fonts) however in this specific
case the server is remote
(https://apps.odoo.com) and it still needs /src/
Fix:
add /src to the url
OPW-2791531
closesodoo/odoo#91112
X-original-commit: bf629cf3063119a5c819f74329a51a0e1a7c172f
Signed-off-by: Géry Debongnie <ged@odoo.com>
Ipsita Borisagar