Previously a 10mm margin was added between the top edge and the image below.
The way the margin was added only offsets the picture by 10mm without
adjusting the image size (see PR #143383).
This may lead to an overlap between the image and text
below (depending on the dimensions of the image).
This fixes this issue by putting the 10mm margin "inside" the image
instead of "outside" of it. Thus the size of the image is adjusted correctly.
closesodoo/odoo#144687
X-original-commit: 1676436f522399e78877725d99e845550f1b5c9a
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
This commit's purpose is to give back to the portal user the access
rigth to read on the model project.milestone. This access was removed
because it was judge that it was not needed to give access to portal
user to an entire model. The issue it created is that while the name_get
still works, it is no longer possible to do a search on the milestone
field on the portal sharing
step to reproduce :
- install db with project and demo data
- log in with mitchel admin
- open the project app
- click on the 'share' option of the deco addict project
- select 'edit' and type 'joel' in the partner section. Select the
suggested portal user 'my company joel willis'
- click on 'send invitation'
- log out and log in with the portal user
- select the project menu
- click on the shared project 'deco addict'
- start typing in the search bar and select the 'milestone' option
An access right error is raised.
source of the issue :
The name_search function is not executed in sudo and since the
portal user has no read access on the project.milestone model,
an access right error is raised.
Solution :
Give the read access to the project.milestone model to portal user.
Ideally, that is something we'd like to avoid, but since the other
option is to execute the name_search in sudo, giving read access is the
better option. An ir.rule was also added to ensure that the portal user
has only access to the milestone linked to his shared project. A local
script was added, and the version of the manifest was changed in order
to trigger the script when the module is updated.
Some tests were added.
affected version 16.0 -> 17.0 (another fix will be applied in master)
ticket -
https://www.odoo.com/web#id=3548142&cids=1&model=project.task&view_type=formclosesodoo/odoo#144525
X-original-commit: d74a6ca46d208fbbe5142bcbb39d8985ee1e1f23
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit:
When we are in a call in full-screen mode, if we have a tour marker
visible in the background, it also becomes visible in the call.
After the commit:
The tour marker is not visible if we are in a call in full-screen mode
task-3502417
closesodoo/odoo#144640
X-original-commit: 7975f404bf98ed7fb9d701ef9951dedca7ec6072
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Current behaviour:
When coloring a word multiple colors,
then wanting to re-color it a unified color,
there is a traceback.
Steps to reproduce:
1. Go to Settings
2. Click on Configure Document Layout
3. In Company Details, select a word
4. (eg: YourCompany)
5. Color half in yellow and half in red
6. (eg: Your in yellow, Company in red)
7. Then select the whole word
8. Color it in a unified color (eg: black)
9. Traceback
Cause of the issue:
range.setEnd(...endPos(last)) was throwing a warning:
During applyColor, Sanitize is called,
which merges similar nodes. (using moveNodes)
After the merge, out of n similar nodes,
only the first one is still contained in the document.
opw-3502124
closesodoo/odoo#144619
X-original-commit: 43a5aec38809f3e7e29b278704fc2143d6cc236e
Signed-off-by: Nicolas Bayet (nby) <nby@odoo.com>
Signed-off-by: Antoine Demany (ande) <ande@odoo.com>
Issue:
When triggering an orderpoint, the date will be set to midnight UTC.
This will cause issue with users in timezones UTC-x, as it will display
the date as the day before.
This is a so-so fix to reduce the number of impacted users by moving the
orderpoint date from 0.00 to 12.00.
opw-3579318
closesodoo/odoo#144587
X-original-commit: 201ade0cfb0dc34021d6eded28630d8df2f27ab0
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Steps to reproduce:
- Create a Batch transfer and create two reciept in it
each with a serial tracked product in them
- Confirm the batch transfer
Bug:
in the detailed operation tab of the batch transfer (use existing lots/
create lots) options of the picking type are not respected and lot id is
displayed instead of lot name (many2one instead of char field)
Fix:
keep the same batch transfer as in the pickings that constitute it
opw-3541324
closesodoo/odoo#144582
X-original-commit: 53498d92f1f4de516f4452dd44d3a2c12fd5eb02
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Currently there is a traceback in case of a 100% discount on an invoice line.
This commit fixes the issue by computing the discount differently.
Previously it was tried to calculate the discount amount from the
discounted value and the discount factor.
This is (mathematically) not possible if the discounted value is 0.
After this commit we compute and use the undiscounted value in case
the discount is 100% to compute the discount amount.
The computation was adapted from '_prepare_edi_vals_to_export' from account.move.line
Reproduce
1. Install l10n_es_edi_tbai
2. Select the Spanish company
3. Settings > Accounting: Ensure "Test Mode" is set in Spain Localization section
4. Create a new invoice with Spanish customer
5. Add a line with a 100% discount
6. Confirm the invoice
7. Process the invocie with TicketBAI
8. Error / Traceback
opw-3572426
closesodoo/odoo#144571
X-original-commit: 74aa7136fea8bd0f962c577fba89bbd4f7618742
Signed-off-by: Cedric Snauwaert <csn@odoo.com>
Signed-off-by: Sven Führ (svfu) <svfu@odoo.com>
Currently, the arrow of a popup is not taken into account when computing
its position resulting in an overlap with its parent element in some
cases. This commit fixes this situation.
Steps
=====
- Install module project_enterprise
- Create a project with a milestone set at the end of the current month
- Assign this milestone to a task with planned dates set
- Open the Gantt view of the project
- Hover the milestone diamond
Issue
=====
- The popup displaying the milestone name is partually overlapping the
diamond resulting in a flicker when the mouse is positioned on the left
of the diamond.
Cause
=====
Margin-bottom and margin-right are used in the style of popover. This
has no effect on the positioning of the popover that relies on left/top properties.
Fix
===
Those are replaced by negative top/left margins
task-3457106
closesodoo/odoo#144546
X-original-commit: d10d38c8ff67b0912055d9cfd680d606b24aebc0
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
will get multiple company with multiple currency record
as it will try to calculate multiple template
cost currency field value. we need to do iteration
for template record then it will resolve the error.
Error has been introduced during upgrade.
```
File "/home/odoo/src/odoo/saas-16.4/addons/product/models/product_template.py", line 189, in _compute_cost_currency_id
self.cost_currency_id = self.company_id.currency_id or self.env.company.currency_id.id
File "/home/odoo/src/odoo/saas-16.4/odoo/fields.py", line 1306, in __set__
self.write(protected_records, value)
File "/home/odoo/src/odoo/saas-16.4/odoo/fields.py", line 3087, in write
cache_value = self.convert_to_cache(value, records)
File "/home/odoo/src/odoo/saas-16.4/odoo/fields.py", line 3010, in convert_to_cache
raise ValueError("Wrong value for %s: %r" % (self, value))
ValueError: Wrong value for product.template.cost_currency_id: res.currency(2, 139)
```
closesodoo/odoo#144523
X-original-commit: a8d884b8fb47ad0ac3960ffc5f84f5c6316d20a6
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Atul Patel (atp) <atp@odoo.com>
The main issue is partially fixed by https://github.com/odoo/odoo/pull/144228
There is an extra issue where jump/load around in the past was not
properly resetting the thread loaded state, and the "load newer" was not
waiting for the jump to be completed before loading newer messages
because the loaded state reset was not taken into account, and also a
scroll restore to bottom was applied too early (there should be none, as
the jumping already highlights the message).
Technically the same thread component was re-used, but the visible hook
and the loaded state should always be reset when there is a jump with
gap (load around).
Extra assertions are added to ensure the expected scenario is fully
explicited and awaited in this test.
runbot-46308
closesodoo/odoo#144520
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
With this improvmenet now user can select the currency Chinese Yuan Offshore and use it.
opw-3599124
closesodoo/odoo#144472
X-original-commit: 0e431aded4a7d6ff8dd8ac03860859a19518e254
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
Before this commit, rtc join/leave sounds were played on every
tab. This can be due to two issues:
- notifications related to the current user should not play sound
since it is already played by the tab that triggered the action.
- only the main tab should play the sound.
This commit implements this behavior.
Steps to reproduce the issue:
- Open two tabs
- Start a call on the general channel
- Notice that the "join" sound was played twice
- Leave the call
- The same applies for the "leave" sound
task-3355352
closesodoo/odoo#144436
X-original-commit: dfbd95f
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this commit:
- Attempting to press the Enter key in the emoji picker when the search result
was empty would lead to a traceback error.
After this commit:
- Now, Pressing Enter key in the emoji picker with an empty search result no
longer triggers a traceback error.
task-3576930
closesodoo/odoo#144434
X-original-commit: d9ea54fe8b3cf73da0e32155f2f08803ffe7440a
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
During upgrades, customization modules are defined in the database but
their codebase is not in the addons path.
Because of this, when running an upgrade the manifest of such modules
does not exist which makes `_generate_primary_snippet_templates` fail
because it cannot locate some default keys.
This commit adapts the access to the manifest in order to use a default
value in case the manifest is not available.
closesodoo/odoo#144222
Related: odoo/design-themes#751
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
If the first theme that generates configurator templates has the same
block used several times within a single page, a unique constraint is
violated because it tries to create several identical
`configurator_<pagename>_<s_snippet_name>` templates.
This commit avoids this by only considering unique snippet names.
The issue typically appears with `s_title` on `theme_monglia` and
`theme_real_estate` if they are installed by themselves.
Part-of: odoo/odoo#144222
When shapes were extracted to configurator snippets in [1], some
configurator-specific snippets were created that do not appear on pages
of the specific theme.
Because in [2] the call to `_generate_primary_snippet_templates` is done
on a full list of themes instead of only the installed ones, the problem
was not noticed: if any theme defines a block, it's website-side
configurator-specific template is generated.
This is not the case during an upgrade: the templates are generated only
for the installed themes. Because of this some "useless" configurator
templates trigger an error when importing their XML definition because
their parent template does not exist.
This is fixed in design-themes by adding those templates in a pseudo
page `_` in the `configurator_snippets` entry of each theme's manifest.
This commit makes sure to not consider that `_` page name as an actual
page name.
In master, the templates will be removed instead.
[1]: https://github.com/odoo/design-themes/commit/d206c119720d557c11320ebb3d7339890b8f9efa
[2]: https://github.com/odoo/odoo/commit/928eeca714a161f6bc03343e4dc8af9b050b9841#diff-f49a1e9eda23df9f1d48121ba376a5fabafe70ea18b29d4eab23d737e5d4eeb6R446
Part-of: odoo/odoo#144222
Previously, if a tour was added to the registry after the tour service
started, it would not be registered and could not be started. A previous
PR ( odoo/odoo#125055 ) fixed this behaviour, but did not auto-start the
corresponding tour if needed. This commit fixes that.
It also runs "auto" tours in exclusive mode, ie only one tour at a time,
to prevent the check delay from being impacted by other tours which can
lead to unwanted behaviour, especially with bootstrap modals, which are
not immediately closable as soon as they start displaying, and can cause
some test tours to fail.
Tours that auto-start no longer reset to the first step when refreshing
the page, and when multiple tours are running in parallel and can show
their pointer on the same screen, the tour with the highest
priority/lowest sequence is now the one to show their pointer, instead
of it being the one that was started first.
task-3377185
closesodoo/odoo#143598
X-original-commit: 4bba22763436645e94b484fc1cca3752effa9a25
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
For orderlines with a price of 0, the receipt will now display the
price as 'Free' instead of '0.00'.
closesodoo/odoo#143285
Related: odoo/enterprise#51338
Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>
The website_page_controller_expose is a technical model for portal and
public, not for employee
The side-effect of the change was that, before this commit, the
category Website was no longer a selection but a list of boolean only
accessible in debug mode
closesodoo/odoo#144342
Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>
A function that returns the list of missing modules is needed to know if
the the customer needs to changi his plan when importing an industry
module.
closesodoo/odoo#144241
Signed-off-by: Pierre Masereel (pim) <pim@odoo.com>
For multi language website, when request http:/localhost/en/something,
Odoo reroutes from the requested path /en/something to the new path
/something with lang=en_US in context.
If the new path is a unicode string like http:/localhost/vi/xin-chào,
http:/localhost/ru/привет, a error should occur at
werkzeug._compat.wsgi_decoding_dance() because the path was not latin1
string.
The utf-8 encoding followed by a latin-1 decoding is required by the
WSGI specification[^1]. latin-1 is used as an encoding passthrought:
that encoding has a representation for all the 256 bytes, i.e. it is
impossible that decoding a text will raise a ValueError. The WSGI spec
uses this trick to save values until the actual charset (present in
the Content-Type header) in known.
[^1]: https://peps.python.org/pep-3333/#a-note-on-string-typesclosesodoo/odoo#143898
X-original-commit: 9b69b87c08b1d62b3581fe651bee692a4f217dff
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Because the class was imported in this file, unittest was discovering
it again and was running the TestHttpStatic cases twice: once because
of its inclusion in the test_static.py file, once more because of its
inclusion in the test_web_server.py file.
Changing the import solved the problem, since it is a python module
object that is now exposed and not test case classes, unittest doesn't
discover the classes.
closesodoo/odoo#143840
X-original-commit: 8067d3bf3d9f73b95595a16100096aafff5c2075
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Since [1], the colorPalette component is mounted on a new App via the
attachComponent compatibility util. The new App is subject to target
validation, which fails in mass_mailing and raises a traceback.
This happens because the element for mounting the color palette is
created by the top window's document and later attached to the iframe's
DOM tree. Unfortunately this holds true for the entire sidebar is
mass_mailing.
Commit [2] apparently added some flexibility to the attachComponent
util, temporarily disabling target validation when about to mount an
App. But, due to the asynchronous nature of mounting an App, this was
not enough for the present case, as the original App.validateTarget
function is restored before it gets called when mounting the
ColorPalette.
This commit fixes this localized issued, leaving a large-scale fix, in
which the snippets menu elements are properly created by the correct
document, for a future commit on master. This will have to take into
consideration the fact that the code for the snippets menu is shared
between mass_mailing and website, and that, in the latter, the snippets
menu sits outside the iframe, thus, it is part of the top document tree.
Alternatively, the snippets menu should be refactored and converted to
owl.
task-3605859
[1]: https://github.com/odoo/odoo/commit/36061a4ab017a463c1d5bf838334cb4c0fac25ee
[2]: https://github.com/odoo/odoo/commit/6a30ab13536a2dc0a8f23df32962cd1ceec71a5dclosesodoo/odoo#143340
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Co-authored-by: Jinjiu Liu <jili@odoo.com>
Prior to this commit, the demo restaurant had a start category but
this is not wanted anymore. We thus remove this start category.
closesodoo/odoo#142212
Signed-off-by: David Monnom (moda) <moda@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
pos*: pos_online_payment, pos_sale, pos_self_order
Prior to this commit, different tests were using the demo data
to run which was causing problems when the demo data were not installed.
In this commit, we add products, categories, floor, table, etc. at the
setup of the test so that the test can run without demo data.
X-original-commit: 6ef51b11f7f67a1f17225541cb2341a178a98aad
Part-of: odoo/odoo#142212
Versions:
---------
- 15.0+
Steps to reproduce:
-------------------
1. Have multiple languages and Studio enabled;
2. create an event template;
3. add a question;
4. add translation to question;
5. use template to create event.
Issue:
------
Translation doesn't get copied from template to event.
Cause:
------
The `_compute_question_ids` method copied the questions by *manually*
recreating them. It didn't use the `copy_translations` method like the
regular `copy` methods does.
The reason the questions were recreated is because question records
cannot link directly from event template to event, as changes to the
event shouldn't affect the template.
Solution:
---------
Use the `copy` method instead while setting `event_type_id` to `False`
to satisfy the restriction.
opw-3572599
closesodoo/odoo#144451
X-original-commit: 73d603b65fca33773557012c4ba38da1bc98271d
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Levi Siuzdak <sile@odoo.com>
Whether a question can belong to itself is too philosophical of a
question for an error pop-up.
opw-3572599
X-original-commit: c798bbbde6fc6e8e42e144f90c163a2ae40a49b8
Part-of: odoo/odoo#144451
Odoo may allow prediction to occur when importing an EDI.
i.e. predicting the product, account and taxes of each line.
By default, those predictions will overwrite the actual value.
Though it may be helpful in some cases, there should be a way
to opt-out of the this automatic overwrite and to have a more
flexible way to do those predictions.
Here is how this is now possible:
1. With `disable_onchange_name_predictive` one can
indicate their desire to opt-out of the prediction overwrite
(i.e. the default behavior).
2. They can then use the `_predict_product`, `_predict_account`,
`_predict_taxes` methods to create their own way of prediction.
Placeholders for those were created to allow their use even if the
prediction module isn't present.
NB: As the module in charge of predictions (`account_accountant`)
is not always installed the `edi_prediction_enabled` context key is
used to indicate whether the prediction methods can be used or not.
In the case of this fix, the key is setup in the `l10n_it_reports`
module, as this module is always installed if `account_accountant`
and `l10n_it` are installed.
This way of predicting is useful for cases demanding a less generic
approach to prediction. e.g. For the Italian EDI module the account
of a line can be predicted without any limitation as it is not a value
imported by the EDI. Whereas, its product and taxes should be predicted
only if none were imported.
opw-3201391
opw-3172035
closesodoo/odoo#144437
X-original-commit: 9a87ec149a95239fbfceee60c2aecf4322fa964a
Related: odoo/enterprise#51901
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Soam Le Dortz (sold) <sold@odoo.com>
Before this commit:
Pressing Enter after selecting text does not remove the selected text.
After this commit:
Now pressing enter after selecting text removes text.
task-3541359
closesodoo/odoo#144433
X-original-commit: bbd8b56ab1e91985b879c52af2a13517bf305127
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
This commit addresses an issue where archived product variants were
taking precedence over active variants with the same combination,
rendering the combination unusable in the sales app.
Steps to reproduce:
1. Install Sale & enable product variants
2. Create a product with two attributes, each having two values
3. Make a sale for each variant
4. Remove one of the attributes and save
5. Add back the same attribute with only one of the values
6. Make a new quote with the product; Option is not available.
After this commit:
Archived variants will no longer exclude a combination if an active
variant with the same combination exists.
opw-3538366
closesodoo/odoo#144431
X-original-commit: ceb540da0898cc27999c8ee30329051102e0f8f3
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Walravens Mathieu (wama) <wama@odoo.com>
Co-authored-by: Victor Feyens <vfe@odoo.com>
Steps to reproduce:
- create a bill
- add a product line
- add a payment reference
- save it
- change the payment ref
- confirm
- register a payment
Issue:
The memo is not the updated payment reference
Cause:
The memo is computed by taking in priority the `line.name`
https://github.com/odoo/odoo/blob/a39050e15195eb095b3480899cedb5cb458fa6cc/addons/account/wizard/account_payment_register.py#L139-L145
And whenever we change the payment reference, the line.name is not recomputed if it has already been set
opw-3476835
closesodoo/odoo#144362
X-original-commit: 367754e760e41eee605176f1a712190a0cc388a1
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
1) Create + Confirm two MO's for product
2) Merge Confirmed MO's together
3) Mark MO as Done
4) Press Apply on Immediate Production
4a) Stops consumption due to no Components being declared
4b) Would expect the Consumption Warning Wizard to be triggered here to allow use of "Validate & Set Quantities" button
It happens due to #85301 the purpose was to avoid the rules from
stock.move. However for other functionalities of MO like manual
consumption. We would like to keep the standard behavior.
Call the classic action_confirm but after manualy updated the stock.move
opw-3577267
closesodoo/odoo#144350
X-original-commit: dcf13fd1127436abb3c6a5f225f8f99d571330a3
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Steps to reproduce:
-------------------
- go to ecommerce;
- click on "Product A";
We see the breadcrumb: All Products / Product A
- go to shop page;
- go to the category of "Product A";
- click on "Product A";
We see the breadcrumb: All Products / Product A
instead of: All Products / Category / Product A
Cause:
------
The template used for the breadcrumb is cached.
Solution:
---------
Use the `t-nocache` attribute to re-evaluate this part
of the template each time it is rendered.
opw-3582971
closesodoo/odoo#144327
X-original-commit: b735269c390d2117336e29651193726ccf050636
Signed-off-by: Thomas Lefebvre (thle) <thle@odoo.com>
Prevent error: "[BR-S-10]-A VAT breakdown (BG-23) with VAT Category code
(BT-118) "Standard rate" shall not have a VAT exemption reason code
(BT-121) or VAT exemption reason text (BT-120)."
We should not provide a tax exemption reason for standard rates when the
customer is Norvegian. It is not allowed in UBL Peppol Bis 3.
no task/no ticket (noticed the error in the IAP logs).
closesodoo/odoo#144287
X-original-commit: 5b62e301b91a3f39857c2c7f18729e10796ef194
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Julien Van Roy (juvr) <juvr@odoo.com>
Steps:
- Open Timesheet
- Configuration > Time Encoding > Change Encoding Unit to Days
- Now select Reporting > By Employee
- When you select Measures, you can see Billable Days and Non-Billable Days
- Now select Reporting > By Project / By Task
- When you select Measures, you can see Billable Hours and Non-Billable Hours
Issue:
- Even after changing the Encoding Unit from Hours to Days, still we are able to
have Measures in Hours instead of Days
Cause:
- Records are not made for project and task which changes on the change of
encoding unit.
Fix:
- adding records in 'timesheet_analysis_views' for project and task for graph
and pivot views so that it updates when changed the encoding unit.
Technical Explanation:
'timesheet_uom' is used to define the unit of measure for time entries in a
timesheet. It represents the measurement unit that is used to record and track
time spent on specific tasks or activities. For example, it could be set to
'hours' or 'days' depending on the organization's requirements.
'float_time' is used for representing time durations or intervals. It allows
users to input and display time values in a decimal format, such as hours and
minutes. The float_time widget provides a convenient way to handle time
calculations and representations.
These two concepts serve different purposes but can be related in the context of
tracking time-related data. The timesheet_uom field determines the unit of
measure for time entries, while the float_time widget allows for inputting and
displaying time values in a convenient decimal format.
If we use 'timesheet_uom', the data on the server side will always be displayed
in hours or days, which could be confusing for the user. Another issue arises
when the work hours for a day are not 8 hours but rather 7.5 hours. The
conversion is not accurate since it assumes 8 hours per day in all cases.
Hence, by using 'float_time', the process of exporting the data can be
streamlined.
closesodoo/odoo#144274
Task: 3387850
X-original-commit: e344716716fc0fcd1f81fce5b00cc7a5996b1e85
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
When a nav list is open, if there is a new props provided, a error
could be thrown. Reproduce:
1. write "@aUser #ge" in the composer
2. click on the @aUser => traceback
The problem is because when NavigableList is open,
the `props.optionTemplate` will change before `state.options`,
leading to a mismatch between the template and the record.
This commit solves the issue by removing syncing
props.options and state.options altogether.
This felt needed to enrich options with id,
but this is unnecessary because the forged id
was simply the index of option in the list.
closesodoo/odoo#144260
X-original-commit: b41f25bc7b41799bd34e27e8e1013d7a85320bcc
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this commit:
Copy pasting table in firefox gives us traceback because the firefox does not
support :has() selector.
After this commit:
Now it will not give any traceback.
task-3591148
closesodoo/odoo#144256
X-original-commit: 224c42e4dedbb18b7f023756d652bb935d5d9829
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Steps:
- Open field service
- Go to Calendar view
- Click on any data, so that the popover opens.
- Click on the SMS button to send a message.
Issue:
- When we try to send the message, the traceback comes with the message
'Component is destroyed'.
Cause:
- When we try to send the message using 'Send SMS', before that the popover
opened gets destroyed. The popover and wizard are different 2 components and
hence we aren't able to control them.
Fix:
- We are performing load and notify methods only if the status of the component
is not destroyed.
task-3386925
closesodoo/odoo#144255
X-original-commit: 49b5054d0d530c3935cf053ae994dbebc12f1e04
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Summary
-------
Taxcloud taxes are always 0 on payment page.
Steps to reproduce
------------------
* install `website_sale_loyalty` and `website_sale_account_taxcloud`
* configure taxcloud
* enable 'Detect Automatically' on the 'Automatic Tax Mapping
(TaxCloud)' fiscal position
* go to ecommerce, and add a product to cart
* go to cart
* proceed to checkout
You should see that the taxes are still 0 on the payment page
Cause
-----
The issue comes from the `shop_payment()` override in
`website_sale_loyalty`. The taxcloud taxes are computed with
`res = super(WebsiteSale, self).shop_payment(**post)`,
but they are immediately cleared with
`order._update_programs_and_rewards()`
opw-3539027
closesodoo/odoo#144250
X-original-commit: 051470a16f3a76689eaeb6db57ac3d98a60c1f4d
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>
Comparison feature had been lost in the OWL refactoring.
steps to reproduce:
- go to sale report, set a filter to current month
- enable comparison to previous period
- save to dashboard
before this commit:
- dashboard did not use the comparison filter
after this commit:
- dashboard uses the comparison filter
opw-3584559
closesodoo/odoo#144239
X-original-commit: f7caee48c7c11ed601d49cf31ddd14b564f9b896
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
The IntersectionObserver was sometimes started and called its callback
before the scroll was restored, in which case the load more button was
always visible, leading to loading more messages than intended.
To fix, delay the starting of the visible until the scroll is restored.
runbot-35533
closesodoo/odoo#144228
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Currently, increasing the rounding factor for a currency is not allowed
if accounting entries have already been generated in that currency.
However, the restriction currently only applies to the current company.
And since currency records are shared between multiple companies, a user
can create a new company with no accounting entries and then change the
currency's rounding factor, affecting all companies.
This commit checks for the restriction on all companies, and fixes a few
tests that were broken by this change.
opw-3586785
closesodoo/odoo#144226
X-original-commit: 7f8b76ac7ad3730a662203aa88a03d067c1230cb
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>
The order of the imports have been changed in websocket_client.py to
follow odoo guidelines
closesodoo/odoo#144188
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Issue:
- Before this commit when we see helpdesk team form view some of the features
names are not aligned with checkbox
Cause:
- Issue was caused because of the icon size is large and so it features names
were not aligned
FIX:
- we have removed the font size of the icon so that text get aligned with the checkbox
task-3463622
closesodoo/odoo#144184
X-original-commit: 9b52a265056d9ee1e82537d1e8bd93b00911d127
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Sven Fuehr