Google has removed the feature that allowed sitemap submissions. Now,
it's standard practice for Google to crawl the /sitemap.xml. This commit
permits to show a notification message when the user clicks on the
button to submit a sitemap.
task-3323849
closesodoo/odoo#152700
X-original-commit: fb842f682bb8b2600d861a5e0bb92503857bd2de
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
There are multiple types of Identification Numbers in Romania and if you invoice
to a natural person, you are also required to send an electronic invoice.
Thus, we will add a check to allow the two TIN numbers that needs to be correct.
Example of valid tax number 'RO1234567897 or 'xyyzzaabbxxxx' or '9000xxxxxxxx'.
-Tin1: For xyyzzaabbxxxx, 'x' can be any number, 'y' is the two last digit of a
year (in the range 00…99), 'a' is a month, b is a day of the month, the number 8
and 9 are Country or district code
-Tin2: 9000xxxxxxxx, start with 9000 and then is filled by number (range 0 to 9)
Also stdum also checks the CUI or CIF (Romanian company identifier). So a number
like '123456897' will pass.
This commit will remove some test that are not relevant anymore since we can't
apply a vat number that don't follow the legal convention.
closesodoo/odoo#152649
Task: 3716671
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
The express checkout button is handled by Stripe, so we have no control over it. Upon
inspecting Stripe's code, it looks like the button simply fills the available width. The
button just above Stripe's button ("Sign In"/"Process Checkout") sets the available width,
so if it's narrower, Stripe's button gets truncated.
This PR sets a minimum width on the container around Stripe's button. This seems to work
for different screen sizes and locales. The problem with this fix is that it could break if
Stripe's button content gets wider. Unfortunately, since the button is displayed in an
iframe, there's no better fix AFAIK.
opw-3430099
closesodoo/odoo#152510
X-original-commit: 75b6fe71896f1dcce5ed6ebca0e096a45aa891e9
Signed-off-by: Louis Tinel (loti) <loti@odoo.com>
Steps to Reproduce
===================
1. Create an event (e.g. starting at 9:00 AM)
2. People arrive early and attempt to scan a badge at 7:30 AM
--> An error occurs: "Not part of an ongoing event"
Technical Reason
=================
-> Before this commit we were considering both date and time due to this
is_ongoing was set as false.
-> So to support early entrance we remove the old condition and added a
new condition.
After this Commit
=================
It will let you scan badges and verify attendee as long as event is not
finished.
Task-3596660
closesodoo/odoo#151703
X-original-commit: https://github.com/odoo-dev/enterprise/commit/3a2e4f123f1b3ff2eb1c444d14891eddd7e7ebac
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
You should be able to create analytic plans with analytic group.
But currently, you need Access Right's group.
We should put a sudo there.
closesodoo/odoo#151328
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
The generated facturae files do not pass the FACe platform checks. The
platform itself didn't give us any useful information.
A feedback from the Spanish government said though:
> We detected inconsistencies with the field `<ds:DigestValue>` from the
tag `<xades: SignaturePolicyIdentifier>`
Although not explicitly mentioned, we should apparently use SHA1 for the
digest value of the Signature Policy instead of SHA256.
opw-3673349
opw-3716276
closesodoo/odoo#152720
X-original-commit: e5d69a73e2e781d00f67c0590a8fc13b09a06ebf
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
Issue:
When using a mercado pago invalid access token with extra tabs, we get 403 response from mercado pago without a body
which raises and exception while handling this exception we fail to parse the response as it has no body.
line causing the issue: https://github.com/odoo/odoo/blob/9764e6f7fe39a10f3b04e1764110d8c274d0431a/addons/payment_mercado_pago/models/payment_provider.py#L70
Steps to reproduce:
1- Enable mercado pago as a payment provider
2- Set a valid access token for mercado pago with extra tabs
3- Go to website
4- Fill the cart
5- Checkout with the cart using mercado pago
6- You see error message of unhandled json parsing error
Solution:
We should wrap parsing the response in a try statement to handle the responses without body
opw-3654133
closesodoo/odoo#152858
X-original-commit: 952a64423e7cabf7cd3ef700dff7be2bfba1b56a
Signed-off-by: Omar Abosamaha (abom) <abom@odoo.com>
The iot build fails following the installation of the new
linux-image-6.1.0-rpi8-* packages
The base image is recent enough to skip the upgrade during the build
The "apt upgrade" command is therefore removed from the build
closesodoo/odoo#152828
Signed-off-by: Yaroslav Soroko (yaso) <yaso@odoo.com>
The compatibility was broken in a couple of points, clients
are required to update the `l10n_it_edi` or cannot send invoices
to the Italian EDI. Updating the module fixes the errors.
These two errors may appear:
```
[...]
File "/home/odoo/work/odoo/odoo/fields.py", line 1216, in __get__
raise ValueError(f"Compute method failed to assign {missing_recs}.{self.name}")
ValueError: Compute method failed to assign account.move.send(<NewId 0x7ff2da360eb0>,).l10n_it_edi_warning_message
[...]
File "/home/odoo/work/odoo/addons/l10n_it_edi/wizard/account_move_send.py", line 57, in _compute_l10n_it_edi_warning_message
action = error_data['action']
~~~~~~~~~~^^^^^^^^^^
KeyError: 'action'
```
Original broken PR: odoo/odoo#142596closesodoo/odoo#152824
Signed-off-by: Josse Colpaert <jco@odoo.com>
Commit [1] moved (almost all of) the code of formatFloat from
views/fields/formatters.js to core/utils/numbers, to make it
accessible in the frontend. A formatFloat function was kept in
formatters.js to handle the false case, which makes no sense in
number utils, but is useful for fields. However, a lot of imports
have been updated to use the numbers.js instead of formatters.js
(i.e. they no longer benefit from the support of false), whereas
they are actually formatting field values, so they should have
kept using the formatFloat from formatters.js
This commit adapts the places where the formatFloat to use must
come from formatters.js, not numbers.js.
[1] https://github.com/odoo/odoo/commit/054ca0a19aaf297f420a1b478b93ae26f1b943b8
task 3722043
closesodoo/odoo#152810
Related: odoo/enterprise#55919
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
When filtering column had too much attributes, scrollbar
would appear. Scrollbar was deleted but ability to scroll
is left.
task-3609062
closesodoo/odoo#152769
X-original-commit: 1be3fa46062d83ca8438dc2e44ba3904467c6710
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: anko-odoo <anko@odoo.com>
Before this PR:
Canceling an activity linked to an event produces error because of non provided
thread.
Steps to reproduce:
- Create an activity with event (call or meeting) in chatter
- Try to cancel this activity
- There is an error about undefined thread and activity remains on the chatter
After this PR:
- Thread is provided in `onUpdate` method to use in `load()` in chatter
- `activityService` deletes the activity with event in `unlink` patch
closesodoo/odoo#152737
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit, printing a receipt would result in an additional
empty page being printed. This not only wasted paper but also caused
issues. The problem was related to the notification element on the
print page. By removing this element, the issue has been resolved.
opw-3706233
closesodoo/odoo#152731
Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>
Trying to call the get_lines() method of the stock.traceability.report
model was failing using the external API, due to the response containing
None values. Making sure that False is returned instead of None fixes
this.
The XML-RPC client error is the following:
closesodoo/odoo#152712
Typeerror: cannot marshal None unless allow_none is enabled
X-original-commit: 76ba5fc08e76c3163cd21ccfa710cdcc82340c89
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Current behavior:
If a customer has no email set, creating an invoice for that
customer and clicking on send and print will not generate a snailmail
for the invoice, even if, the checkbox (checkbox_send_by_post) is True.
Expected behavior:
A snailmail should be sent to the customer.
Steps to reproduce:
Using module_account from saas-16.2 to 17.0.
Create a customer invoice for a customer without email > print and
send > check "By Post" > send and print.
Cause of the issue:
The action action_send_and_print defined in account_move_send.py
filters the moves that trigger a mail creation in the var "success".
This variable filters out all moves without a partner_id.email.
This makes perfect sense for emails but not for snailmails.
However, creations of both types of mails are triggered by the
_hook_if_success method taking "success" as an argument.
Fix:
To allow snailmail creations and correctly trigger email creation,
we filter the moves with a partner email after the _hook_if_success
method and only for email creation, not for snailmails.
opw-3668487
closesodoo/odoo#152506
X-original-commit: b17a2c594aed08248c30842c62d2030de3087b51
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: Lancelot Semal (lase) <lase@odoo.com>
This shouldn't change anything regarding SEO, but is worth a try.
It will also impact the link suggestion when creating a link in the
editor, but having pages listed first also have sense there, or at least
it won't be worst.
The idea for the SEO part is that if the sitemap order (if too long)
would have some impact as crawlers might have a limited crawling budget
for your website and it will only crawl the first pages it finds.
Are those "first pages" impacted by the sitemap order? It's almost sure
it's not, as Google definitely knows how to crawl on its own, and is
even probably ignoring the sitemap most of the time.
Also, pages:
- Are probably always important content since you created manually a page to
write something, while (some) controllers might just be content you
care less about. Pages are probably always important while we can't
say that for controllers.
- Should be fewer in number than controllers most of the time
- Have a lastmod set, as opposed to controllers
- May be created at any time, meaning a new crawler visit is needed,
while controllers are almost never added in production, installing a
new module is something very rare. Exception is about record's
controllers which are "created" at any time like pages (eg a new
product controller page)
For all those reasons, this commit reverse the pages vs controllers
order in the sitemap.
This is coming from our prod where some pages are yet not indexed while
they have been published months ago.
closesodoo/odoo#152350
Signed-off-by: Jérémy Kersten <jke@odoo.com>
DeepL translated "false" as "ложный" (the adjective form), but
we expect it to be "ложь" (noun form) when importing xml. This
fix will ensure that the string is correctly converted into a boolean.
I have recorded this as a separate commit for posterity and so it isn't
accidentally changed again in the future.
closesodoo/odoo#152285
Related: odoo/enterprise#55637
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
For a first iteration, Russian translations were done using DeepL using
1 large .pot file of all the standard modules to translate (e.g. no
localizations, no test modules, etc). Unfortunately for some reason
doing a msgmerge with the existing ru.po files didn't seem to work, so
old "Translators" metadata at top of files were lost (maybe they will be
re-added during next Transifex sync?)
Part-of: odoo/odoo#152285
The module `pos_viva_wallet` was added in v17 stable and it's
translation file/configuration was forgetten when that happened.
Therefore we add it in now because it should probably be translated
Part-of: odoo/odoo#152285
The table linked to analytic items can be pretty huge, and searching by
account needs to be fast.
For instance, this index can be used when deleting an account because of
the foreign keys.
closesodoo/odoo#151366
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
**Issue Description**:
Users encounter a misleading confirmation page when a payment is canceled or fails in version 17.0 and higher of our website. Specifically, upon a payment error, users are directed to /payment/status with an error message. However, selecting the "Skip" button redirects them to a confirmation page titled "Thank you for your order", suggesting successful payment. This misleading information can lead to confusion, especially since it results in the card being cleared for public users despite non-receipt of payment.
**Steps to Reproduce**:
1. Navigate to the 'Shop' section of the website, add a product to the cart, and proceed to checkout.
2. Click the "Pay with demo".
3. Select "Canceled" as the Payment Status and then "Pay".
3. Click the "Skip" button during the payment process.
4. Observe redirection to a confirmation page with the title "Thank you for your order", implying successful transaction.
**Proposed Solution**:
This issue, present in versions 17.0 and later, is due to a modification in the <template id="confirmation">, where the "Thank you for your order" title is now displayed regardless of the payment state. To resolve this, we propose introducing a conditional check to display this title when the payment state is "pending" or "done", ensuring accurate representation of the transaction status.
opw-3688785
closesodoo/odoo#151304
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
On a big database, the search for journal entries is basically not
usable.
This is because there is a missing index on the reference, as well as a
complex OR generated by the clause `('move_id.partner_id', 'ilike', self)`.
This commit will of course add the index, but will also remove the
clause because it is almost always possible to find the journal entry
via the partner by using the right filter instead, and since it is not
really an easy to discover "feature" it is most likely not even used.
On the test database, queries went from over 2 minutes to less than 1
second.
closesodoo/odoo#151222
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Before this commit, users were unable to successfully revert the 'done' status
of slides.
Technical Reason:
In this commit https://github.com/odoo/odoo/commit/f956e83c744bd9c970d3f16ce1cb3cff8bba2f6b, the transition from qweb.render to the
Owl render engine (renderToElement) was done. This caused a problem when trying
to undo the 'done' status of slides. The issue was that using 'true' as a
boolean in Owl turned it into an empty string. This fix solves the problem by
making sure we use '0' or '1' as boolean values in Owl.
After this commit, user can revert slides 'done' status.
Task-3667904
closesodoo/odoo#151006
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
Since #135113, calls to /im_livechat/get_session can become very
expensive on large databases with a long history of livechat sessions.
Operators who have thousands of past livechat sessions (channels) can
cause the SQL query in get_operator() to take multiple seconds.
When the livechat is set to auto-popup and there are lots of visitors,
this can become very significant.
This patch changes two aspects:
- introduce a CTE for the RTC session part, in order to avoid a
JOIN cardinality between livechat channels and channel_members - we
only care about channel membership for a RTC session
- restrict the selection of livechat channels created within the last 24h,
considering that we only care about messages sent in the last 30
minutes anyway
The second part may change the result ordering in the present of old
channels (>24h) with recent messages - but that is rather unlikely, and
an operator will be selected anyway.
This change makes a huge difference on a database with 300k livechat
channels and 1 million `discuss_channel_member` records, from several
seconds to >50ms. The results are identical or extremely similar in most
cases, and the database only needs to look at a few hundred records
instead of millions.
closesodoo/odoo#150968
Signed-off-by: Olivier Dony (odo) <odo@odoo.com>
Steps to reproduce the bug:
- Enter edit mode.
- Click on the "Theme" tab in the options panel.
- Click on "Add a Google Font" in the "Font Family" select.
- Paste the address of a font page in the input.
- Disable the "Serve font from Google servers" toggle.
- Save the dialog.
- After the reload, click on the "Theme" tab.
- Open the "Font Family" select.
- Click on the "Remove" button for the recently added font.
- Confirm your choice to close the dialog.
- After the reload, click on the "Theme" tab.
- Open the "Font Family" select.
- Bug: the font has not been removed.
This bug appeared with commit [1]. With the transition to the Owl
render engine, the 'true' value passed as a parameter in the
'delete_google_font_btn' template, defining whether a font is local,
wasn't being set as the attribute value in the template.
In this Owl context, 'true' indicates the attribute's presence, not its
value. To address this, we replaced the boolean 'true' with the string
'"true"' to ensure the parameter value is correctly passed to the
template.
[1]: https://github.com/odoo/odoo/commit/f956e83c744bd9c970d3f16ce1cb3cff8bba2f6b
task-3714768
closesodoo/odoo#152715
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Steps to reproduce the bug:
- Create a storable product X1:
- Route: MTO + buy
- Vendor: Azure Interior
- BoM:
- Type: subcontractor
- Subcontractor: Azure interior
- Component: any component
- Create a MO:
- product: P1
- Component: X1, qty: 3
- Confirm the MO
- Go to the created PO
- Confirm the PO
- Go to the picking
- receive 2 units of P1 and validate it
- create a backorder
- Cancel the backorder
- Try to update the purchased qty in the PO line to 2
Problem:
A traceback is triggered:
File "/home/odoo/src/odoo/addons/purchase_stock/models/purchase.py", line 542, in _prepare_stock_move_vals
'picking_id': picking.id,
AttributeError: 'bool' object has no attribute 'id'
Solution:
When updating the quantity in the purchase order, if no picking requires
an update, it is better to avoid creating a new picking and new moves.
opw-3681064
closesodoo/odoo#152577
X-original-commit: 0da5d6cc0c94320ad39fe9b930dde4b0ef6feff5
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Steps to reproduce:
- Create a new user with no affiliated sales team
- Activate custom mail server with an alias domain
- Login with new user
- Check pipeline in CRM
- The empty pipeline message will show the wrong alias
Issues:
The alias displayed is not for the team of the user.
opw-3608263
closesodoo/odoo#152563
X-original-commit: f862673885aa8fad9b8b225d020cd2757d7be013
Signed-off-by: Mattis Megevand (mmeg) <mmeg@odoo.com>
Since commit [1], which removed jQueryUI for the drag and drop, the
history when editing breaks easily.
Steps to reproduce:
- Drag and drop "Text-Image", save and go back to edit mode.
- Click on a column, move it to the right using the arrow and then to
the left, still with the arrow.
- Undo: no issue, the column went to the right.
- Undo: nothing changed => the column should have gone to the left.
- Undo: the column goes to the left => there should not be a third undo
since we only did two changes.
- Redo: no issue, the column goes to right.
- Redo: nothing changed => the column should have gone to the left.
- Nothing to redo anymore => the column never goes to the left again.
This happens because with the new drag and drop, an `o_draggable` class
is added on the elements when their editor are started, which adds
mutations in the history. Even though it does not explicitely add a
step, these mutations are well reverted when undoing/redoing (e.g. this
is what happens when nothing changes in the steps to reproduce).
This commit fixes this history issue by ignoring the mutations linked to
the `o_draggable` class.
Note that commit [2] already fixed other `o_draggable` class issues.
This commit therefore fixes them in a more general way.
[1]: https://github.com/odoo/odoo/commit/7594d71ca8610d5947e80f325ccb57abc23c2c76
[2]: https://github.com/odoo/odoo/commit/32a6729dd094d53eb4a653ebb9d69d2b8cbe2390
task-3698536
closesodoo/odoo#150687
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Steps to reproduce the bug:
- Add a delay (for example 5 seconds) at the beginning of the
`/sale/get_combination_info_website` route.
- Add a delay (for example 10 seconds) in a `willStart` method in the
`Wysiwyg`.
- Go on a product page and enter edit mode.
- Click on the the product image.
-> The "Replace" button does not appear.
In this situation, the added delays represent slow rpc answers. Let's
analyse the flow of instructions in order to better understand the
problem:
- When you go on a product page, the `WebsiteSale` public widget is
started. `_getCombinationInfo` of `VariantMixin` is then called through
the `start()` of the public widget. As the rpc is taking time to answer,
`_onChangeCombination()` is not directly called.
- When entering edit mode, the `WebsiteSale` public widget is destroyed.
Due to the edit mode, the `o_editable` class has been added on editable
elements.
- After the first added delay and thanks to the rpc answer,
`_updateProductImage()` is called through `_onChangeCombination()`.
Because the `editor_enable` class has not been added to the document
body yet (due to the second added rpc), the `_updateProductImage()`
method replaces some elements of the DOM and by doing so, removes the
`o_editable` class of some elements. Consequently, the snippet option
linked to the image is not displayed.
The problem here is that the `_updateProductImage` method is called even
if its associated public widget has been destroyed. To solve the
problem, we first check that the associated widget is alive before
handling the result of the rpc answer in the `VariantMixin` mixin.
Note that the first idea was to use `this._rpc()` instead of
`ajax.jsonRpc()` in the mixin. Indeed, the advantage of using
`this._rpc()` is that it already ensures that the associated widget is
alive before handling the result of the rpc answer. The problem is that
some widgets that use the `VariantMixin` are created in such a way that
`this._rpc()` can not be used on them (for example
`OptionalProductsModal`).
Related to runbot-28700
closesodoo/odoo#149145
X-original-commit: 599e112ba7580617c61226b73355035c89af3395
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit solves an issue where sample data would be erased when the
user switches from a view with no sample data to another that should
contain them. This commit also removes unnecessary usage of nextTick in
assets loading.
Steps to reproduce:
- go to project and open one
- enter a no match filter and save it as favorite
- reload
- switch from kanban to calendar view and switch back to kanban
- after the fix, sample data should no longer be erased from kanban
task-3701143
closesodoo/odoo#152666
X-original-commit: a8ff1465c6c31240d06c98fa5d61e146b3908cf0
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Julien Carion (juca) <juca@odoo.com>
Ever since 14.0, from PR #45414, there has been a _compute_state
function for recalculating the state on holiday_status_id change
The reverted commit becomes unnecessary and causes incorrect action
buttons to be shown before creation
Note:
Reverts commit 015f8ecfa863ae2fcca983b6bb21e38577b220e7 from #82552closesodoo/odoo#152513
X-original-commit: 0c4a174d6a3c2615f4851cf3f39ca5159c40acfb
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Deleting an account or a plan shouldn't raise errors or provoke errors
elsewhere.
Since the `analytic_distribution` doesn't have a proper foreign key, an
account might be deleted while still being referenced. Because of this
the code needs to be defensive everywhere: we can't trust the content of
the JSON field.
Also, add tests to ensure that we can't delete a plan while the field is
still referenced in views.
closesodoo/odoo#152494
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Steps to reproduce:
- Add an "Images Wall" snippet on the website.
- Add a link on the first image.
- Add a new image on the wall.
-> Problem: the first image does not have a link anymore.
When adding an image or reordering the images on a wall, the system
re-renders the snippet (see `nomode()`, `masonry()`, `grid()`) by adding
each images on the wall structure. The problem is that the system only
takes the images into account and not a possible image wrapped into an
anchor. This is now fixed as the system renders the images or the
wrapped anchored images returned by `_getImgHolderEls`.
The process is a bit different when adding an image or reordering the
images of an "Image Gallery" snippet. In this case, the system
re-renders the `website.gallery.slideshow` template. The problem here is
double: First, the template does not take a possible wrapped anchored
image into account. Second, there are only few image attributes that are
rendered by the template.
This leads to a new problem:
- Add an "Image Gallery" snippet on the website.
- Add a "Blur" filter on the first image.
- Click on "move to next" to move the first image at the second
position.
-> Problem: the image option does not show the filter and it is now
impossible to change some image options such as "Filter", "Shape" and
"Quality".
To solve those two problems**, the images rendered by the
`website.gallery.slideshow` template are replaced by the images (or the
wrapped anchored images) returned by `_getImgHolderEls`. By doing so,
the rendered images have the correct attributes (so the options can be
correctly displayed and modified) and they are still correctly anchored.
This commit also adapts the `snippet_images_wall` test. An extra trigger
had to be added on the `Select footer` step to ensure that the last
image of the wall has been inserted before clicking on the footer.
Without it, the tour fails as, if the moved image is in the first
position, the tour only waits for this image to be inserted in the wall
and then clicks on the footer. When the wall is completely built, the
focus is automatically done on the moved image and the step
`selectSignImageStep` fails to execute as its `extra_trigger` condition
(`.o_we_customize_panel:not(:has(.snippet-option-gallery_img))`) is not
met.
**: In this 16.4 forward-port, the second problem is not entirely fixed.
The task-3717041 will handle it.
opw-3535829
opw-3573135
closesodoo/odoo#152365
X-original-commit: e73a1a96dcf8786c01205ae0a97b10e38ab9afeb
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The border color of 'color' filter attribute on /shop page corresponds
to the color od the body which makes it difficult for users to see the
color they selected.
task-3584558
closesodoo/odoo#141461
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
This change hides the price range by default. It can be activated via the website editor if needed.
task-3235068
closesodoo/odoo#140277
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Resolves the conflict where two shortcuts (alt-c for 'new' and
'create invoice') existed, but only 'new' could be triggered.
Updates the shortcut for 'create invoice' to alt-i, ensuring
both shortcuts are functional and accessible.
task-3628572
closesodoo/odoo#146307
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Addresses the pixelation of tag images by adjusting their size
in the backend to 200x200. This change resolves the issue of
images being resized from 50x50 to 60x20 in the frontend, which
caused pixelation, ensuring improved image quality.
task-3607604
closesodoo/odoo#144724
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Steps to reproduce:
Select a document in activity view to get its preview
Click the archive button => traceback
Before this commit:
The 'load' method of Activity Model led to the traceback while attempting
to set the domain of params, when none were received.
(bug introduced by : 7682286)
After this commit:
This issue is resolved by tweaking the code of 'load' method. In case of
default params, it now directly sets a domain, instead of trying to add a
domain to the one obtained in params.
Task ID : 3704340
closesodoo/odoo#152335
X-original-commit: 725ebab1f0c7ffc996414c85fbbd162afc4ecaf5
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Khushi Patel (khpa) <khpa@odoo.com>
The patch method is not thread safe, which is very annoying for SH users
for instance.
One obvious issue is that during one thread patching the method, other
threads will also be impacted and have 100 decimal places for the
discount.
But it is even worse:
* thread A start: original = real_original; new = patchedA
* thread B start: original = patchedA; new = patchedB
* thread A end: reset original to real_original
* thread B end: reset original to patchedA
Now at the end of the transaction, the original method simply doesn't
exist anymore, and we only have one of the patches, which forces a
restart of the server to fix it.
opw-3552839
closesodoo/odoo#152168
X-original-commit: 9239ee3a95b474ce2eea92747b64f17f58c5c4cc
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Steps to reproduce the issue:
1. Open Menu Items
2. Open the form to a menu
3. Select an action type (e.g. ir.actions.report)
4. Select another action type (e.g. ir.actions.act_url)
5. Click on the field next to it
6. Click on "View all"
7. The results displayed match the first action type selected (report), not the second (act_url)
Explanation:
`res_model` is initiated in two functions: `useOpenMany2XRecord()` and `useSelectCreate()` in the `setup()` of the `Many2XAutocomplete` class. The value is never updated for as long as this instance of the field exists.
Suggested fix:
Everytime the key changes, a new instance of the field will replace the current one, calling its own `setup()` with the updated values.
opw-3628017
closesodoo/odoo#151495
X-original-commit: d4078d783717986189f9fbc1b6dd6b264e41e49e
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Signed-off-by: Stroobant Paul (stpa) <stpa@odoo.com>
Before this commit, we tried to access in javascript the cssRules
property of some stylesheets, to parse and display to the user
potential css errors, to help him to detect and fix them. [1]
Since a recent change [2], people get tracebacks on website pages
in odoo.com (without being logged in).
The issue comes from the fact that when assets are served via a
CDN (which is the case in odoo.com for not logged users), reading
the cssRules throws a CORS error. This error is logged in the
browser console.
We only spotted the issue since [2], because it delays the moment
we access the cssRules property (we wait for translations). Thanks
to that, the error service is ready and able to handle errors, and
it does display the error in a dialog, which allowed us to detect
the issue.
To fix the issue, we filter out stylesheets with a different
origin.
[1] 5e920db3ee
[2] 332268c724closesodoo/odoo#152696
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
Before this commit:
While applying font color, when multiple picture snippet is selected the
color was not properly applied to the selection. It was observed that the
font was unintentionally applied around the figure which was preventing the
proper application of selected color.
After this commit:
It has been made sure that whenever the figure element is enountered it
should not be appended inside font tag.
task-3640901
closesodoo/odoo#152660
X-original-commit: 09a9dede95fbcc230a468913d188988cb9ad01e2
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Before this commit:
- Emoji picker opened at an incorrect position.
After this commit:
- The Emoji picker now opens precisely at the cursor location
task-3569967
closesodoo/odoo#152645
X-original-commit: 7fd291355d555af229a33665f472db0811876299
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Before, the tax tag invert is computed based on the entry type if the entry
type is different from "entry" or based on the tax set and the balance of aml
for entries with type "entry".
This is fine in most cases but we can reach a wrong tag invert if we use cash
basis and down-payment.
Here are the steps to reproduce:
- Create a company with cash basis tax (ex: "TVA 20% (Services)" for l10n_fr)
- Make sure no "base tax received account" is set in the cash basis settings
- Create a product with a cash basis default tax and an income account which is
not the default one
- Create an sale order with this product for 100€ + 20% tax
- Create a down payment for 30€ + 20% tax (add the tax to downpayment)
- Create the final invoice with deduction of down payment
- Register a payment on both to create the caba entries
=> Tax report will show 160€ of base instead of 100€
To have the issue, it's important that the income account of the product line
differs from the account used on the down payment line in the final invoice
because the issue involved having a negative base line in the resulting caba
move. If the same account is used for invoice down/product line the caba base
lines will be grouped in one non negative line. For the same reason, the
"base tax received account" must remain empty.
The deduction aml on the cash basis entry of final invoice have an tag invert
at False instead of True. So it's computed as -30€ instead of +30€.
If we reproduce the case with a non cash basis tax, it will work because the
move type will be different from "entry" and tag invert will be computed only
based on the type.
To solve this issue, we now compute the tag invert based on caba origin move
if any to improve the tag invert computation for cash basis entries.
opw-3597141
closesodoo/odoo#152575
X-original-commit: d780a2fc73259244411329027349fad1cb353f34
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Thomas Beckers (tbs) <tbs@odoo.com>
Steps to reproduce
==================
1. Go to the slides website.
2. Open any course.
3. Click on 'add a review' or 'edit review'.
4. Attach any files.
-> Files appear misaligned.
After this commit
=================
They will be perfectly aligned.
Task-3624281
closesodoo/odoo#152443
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Guillaume-gdi