*: point_of sale, web
Previously, the error handling code was refactored and centralized, in
doing so, we broke the ability to select a table while offline: when
selecting a table we ask the server about the orders for the table. When
offline, this creates an error that was previously caught, and showed an
offline error popup, but continued the rest of the flow normally. The
refactoring centralized the display of offline errors to an error
handler, but removed the catching, causing the error to interrupt the
flow.
This commit fixes that by catching the error again, and when it's a
ConnectionLostError, it dispatched the error in a separate async call
stack (using Promise.reject) so that the display of offline errors is
still centralized, the the flow can continue normally.
closesodoo/odoo#114077
X-original-commit: f45f5e644b4b219b968fa19737d75cc710c823f3
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Before this commit, when moving inner content inside a carousel slide
(with the 'move' button), the carousel was jumping to the first slide.
Steps to reproduce the bug:
- In website edit mode, drag and drop a Carousel snippet onto the page.
- Move to the second slide.
- Click on the column to activate its overlay.
- Click and hold the "drag and drop" button of the column to start
dragging it.
- Release the mouse button.
- Bug: the carousel jumps to the first slide.
task-3006831
closesodoo/odoo#114067
X-original-commit: a09031d5f68de5d23bd9cab1910c6f9c50ad7cfd
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
The test returns an error if today is within 365 days before the next 29th February: datetime.date(2024, 3, 1) != datetime.date(2024, 2, 29)
closesodoo/odoo#114053
X-original-commit: 880c0a76ac6333cbc9a8e89c865eb6caf309e0e3
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Diez Stéphane (snd) <snd@odoo.com>
In this commit, the horizontal sizing options are disabled from the
snippets overlay on mobile view as they were ineffective and
unnecessary.
task-2978500
closesodoo/odoo#113945
X-original-commit: b7359e47ce3888433a31592a365017c1183242a7
Signed-off-by: loco-odoo <loco@odoo.com>
To reproduce
============
- with Invoicing installed, give a user the group Billing Administrator without giving any Administration group
- connect to this user and try to add a bank account
an access right is raised
Problem
=======
the `groups_id` on the action `action_new_bank_setting` is not specified
so when runing the action we check if it has `groups_id`, if not, we check
if the user has the right to write on the target model which is `res.company`
here, which is not for this user because he doesn't have any Administration group.
Solution
========
specify `groups_id` to `account.group_account_manager`
opw-3199435
closesodoo/odoo#114108
X-original-commit: 68090907d1a4f26d66ece6827e0dd502e1d26844
Signed-off-by: William André (wan) <wan@odoo.com>
This reviews [1] (in particular changing my mind about [2] upon further
review). Indeed this was marking potential non editable tab panes as
editable by searching the whole DOM instead of editable savable zones.
In the end, what is searched for is also reviewed. Instead of searching
for a very specific structure, we now mark all oe_structure which are
direct children of tab-pane as editable (if in an editable zone) and
their parent (the tab-pane who have a direct oe_structure child) as
readonly.
[1]: https://github.com/odoo/odoo/commit/5fd99855654d220bafb8887cd0ae267042836d4b
[2]: https://github.com/odoo/odoo/pull/109430#discussion_r1115792052closesodoo/odoo#114069
X-original-commit: d5d646281f1de672cff0e03903b88059ac17be18
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since [1] when only website is installed, dropping a dynamic snippet
produces an error because no dynamic filter is defined and it tries to
specify one selected by default.
This commit avoids setting a default filter when there is none.
It did work in 15.0 because the log was inside
`_renderDynamicFiltersSelector` which contained an
`if (dynamicFilters.length > 0)` that avoided the problem.
In [2], when most of that logic was moved from the render method to the
fetch method, that condition was lost.
Steps to reproduce:
- Install website only
- Go to debug mode
- Drop a "Dynamic Snippet" or a "Dynamic Carousel"
=> Traceback appears because there cannot be a default filter when there
is no filter.
[1]: https://github.com/odoo/odoo/commit/3355dc16235355fe51e894f14e275210464608c6
[2]: https://github.com/odoo/odoo/commit/9e0b398fe608e716835260c5f9923f933d723f8e
opw-3166634
closesodoo/odoo#114068
X-original-commit: 8e23f08b1470ec5fe47a4459c4d3a8ad314c43b0
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, we-matrix could create a horizontal scroll bar in
the editor. This was because the inputs had a minimum width size.
Steps to reproduce the bug:
- Drop a chart block on a page
- Add some series
=> The matrix overflows from the editor.
There is no perfect solution to this problem... We have the choice
between:
1) Leave the existing overflow on the editor.
2) Put a horizontal scroll on the we-matrix.
3) Distribute the available space between the columns.
As we don't want a horizontal scrollbar, the best solution is to
distribute the available space between the columns. This solution has a
drawback which is that the cells can become really small if there are a
lot of columns but this solution seems to be the least bad from a UX
point of view.
task-3094162
closesodoo/odoo#114062
X-original-commit: 356e0a1fe5243078ba5f162b383279ae7e6a8136
Signed-off-by: Bojabza Soukéina (sobo) <sobo@odoo.com>
In odoo/odoo#112610 the draggable/resizable behaviour of the floor
screen was refactored, and in doing so the FloorScreen was converted to
a Component from a LegacyComponent. Doing so makes `this.el` unavailable
in the component but it was still using that for the pinch, causing a
crash.
This commit fixes that issue by using a ref instead of using
querySelector on this.el.
closesodoo/odoo#114058
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
In some cases, Odoo's move state is unaligned to that on the
IAP Proxy Server, because the ACK message from Odoo to IAP
deletes all attachments from the EDI transactions on the IAP
without regard if they are with type "Send" or "Receive".
We fix both cases by making Odoo just look at the state and not
to the attachment when it's not needed, and it's only needed when
there is a rejection of the document being sent.
We reserve for the future a change to the ACK to only delete the
attachments by transmission type (Send/Receive) so that they don't
interfere.
Error case 1:
- Odoo client sends an invoice to the IAP Proxy
- The IAP proxy will send it to the SdI
- If everything goes well, the SdI will send a notification back
- The IAP proxy sees the notification and saves it
- The Odoo of the client downloads the notification and sends an ack
- The IAP proxy sees the ack and deletes the attachment
- (ERR!) The client resets to draft, modifies and re-confirms
- The state of his invoice is set again To Send
- Odoo tries to re-send the invoice with the same Id Transaction
- The notification for that Id Transaction is already on the IAP proxy
- Odoo client asks for changes, but just sees the old notification
- (-->) The old notif. has no attachment, so Odoo thinks there's no news
- The move in Odoo stays in the To Send state forever
Error case 2:
- Odoo client sends a Tax Integration for a Vendor Bill (reverse charge)
- The IAP proxy will send it to the SdI
- If everything goes well, the SdI will send the same Vendor Bill back
as the client's CodiceDestinatario is actually the recipient in the XML
- The IAP proxy sees the file, the Id Transaction is the same
for both the received and the sent documents
- The SdI sends a notification because the tax integration is OK
- The IAP proxy saves the notification, there are now two EDI
transactions with the same Id Transaction.
- Odoo checks for new documents
- IAP proxy sends the document to Odoo
- Odoo sends an ACK for that
- (ERR!) the IAP proxy sees the ACK and clears the attachment
from BOTH the records for sent and received document
- Odoo checks for documents updates and gets the record without
the attachment
- (-->) The notification has no attachment, so Odoo thinks there's no news
- The move in Odoo stays in the To Send state forever
Ticket link: https://www.odoo.com/web#id=3194378&model=project.task
opw-3194378
closesodoo/odoo#114051
X-original-commit: f85744ee4533ea8593b81a88ef200ec4dc1b1b94
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
Steps to reproduce:
1. Make a cash rounding method, make it specific to cash
2. Add a product line with non-rounded price
3. Enable invoice, and add a customer
4. Make a payment with a combination of cash and bank
5. Validate, an error appears that "the move is not balanced".
The issue is there is a rounding line added, that should be removed.
However, here `unlink` and `write` methods, trigger a dynamic sync
operation that re-generates the rounding line, making the move
unbalanced.
To fix the issue, we can prevent the sync operation, so that no extra
rounding lines are added.
opw-3180708
closesodoo/odoo#114020
X-original-commit: 3bd28525d9486e2f33b8d338c39675125fa22d7a
Signed-off-by: Heinz Robin (rhe) <rhe@odoo.com>
Signed-off-by: Khanalizadeh Ahmad (khah) <khah@odoo.com>
In the time off dashboard, only the number of available days of the
first closest allocation to expire was shown, which is not correct.
If you have many allocations expiring on the same day, their sum should
be shown.
task-3203519
closesodoo/odoo#114010
X-original-commit: ff35654ae8c44014aab99ec07493f035e9a2d80d
Signed-off-by: Kevin Baptiste <kba@odoo.com>
In odoo/odoo#112219 the closePos method was moved to the pos store, but
one call site was improperly adapted and tried to call the closePos
method on the Chrome component instead of on the pos store, this commit
fixes that.
closesodoo/odoo#114009
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
To reproduce the issue:
1. Add French as a language to your profile
2. Install [CRM], [Resellers] on Apps
3. On [Settings]>[Website]
- set the language to French then SAVE
4. Go to [CRM]
- click [Configuration]>[Partner Level]
- click Gold
- click [Go to Website] at the top right corner
- adjective and subject order is not natural for French speakers
Desired behavior: Remove the word 'Partner' (show level only)
Impacted versions: 14.0 up to master
opw-3160102
closesodoo/odoo#113999
X-original-commit: dd5446c66aba2a86ef331e7e832d44f0f22d7142
Signed-off-by: Lee, Hansun (hale) <hale@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
To reproduce the issue:
- Go to website > In a website page with content menu (Event,...).
- Edit mode > Click on a menu item > Click on the "Edit Menu" on the
displayed link popover.
- A dialog to edit the menu appears, but this time it targets the main
website menu instead of the currently edited one.
Starting from [1], an OWL component `EditMenuDialog` is used to edit
website menus. It gets the targeted menu as a `rootID` prop value and
fallbacks to the current website main menu if this value is not
provided.
The goal of this commit is to target the right content menu by providing
the corresponding `rootID` value.
Remark: before [1], a different code was used to open the "Edit Menu"
dialogs and it was based on sending a `beforeReloadCallback` to the
`edit_menu` action (to save page updates once the menu edition is saved,
before finally reloading the page). Now, this callback is sent as a
`save` prop value to `EditMenuDialog`, which means the old callback is a
dead code => removed in this commit too.
[1]: https://github.com/odoo/odoo/commit/2c77b90eee4945d25e9d7f0ffe24484cf91b650a
task-3172234
closesodoo/odoo#113995
X-original-commit: 15deee2424434e9f520a8651b771627704a784a5
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
This commit moves the currency_id field on the
employee model from hr_hourly_cost to hr in order
for it to be used in payroll localisations.
task-3029348
closesodoo/odoo#113992
X-original-commit: 60599b735568c1873fdfde85e667b05347432382
Related: odoo/enterprise#37661
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
An error is raised when trying to render date picker with the Mongolian
locale
Steps to reproduce:
1. Install Sales
2. Install and switch to Mongolian language
3. Open Sales and create a new quotation
4. An error is raised: `locale() locale mn-MN is not loaded from moment
locales!`
Solution:
Add the Mongolian locale. It is not present in the version of Moment.js
we use (2.19.3) so we get it from a newer version (2.29.2)
Problem:
The Mongolian locale was unintentionally removed in this PR
https://github.com/odoo/odoo/pull/111986 so we add it back
opw-3188184
closesodoo/odoo#113983
X-original-commit: 055c13af01c445c5e105d63ea3cd98e3ad2915a8
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
To reproduce the issue:
1. In Settings:
- Days to Purchase: 10
2. Create two products P01, P02:
- Storable
- With the same seller
- Delivery Lead Time: 1.0
3. On replenishment page, create a new line:
- Product: P01
- Min Qty: 1.0
4. Order once
- a RfQ is created and the order deadline is in ten days
5. Time travel to the next day
6. Repeat steps 3-4 with P02
Error: a second RfQ has been generated. However, as the first one is
still in draft state, the POL of P02 should be added to that first RfQ
When processing the orderpoint of P02, at some point, we try to find
an existing RfQ with its order deadline equal to `today + 10 days`.
Since we are the next day (step 5), the order deadline of the first
RfQ is `today + 9 days`, so we don't find it.
OPW-3047931
closesodoo/odoo#113982
X-original-commit: 8bf7f9038915be520488b2602c20929ca115a033
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Bug
===
Remove the constraint on the from_filter for the Gmail outgoing mail
server, because it can be used for custom domain name, and we can allow
an email address to send as an other one.
E.G. if the user has an email address "admin@mycompany.com" and he
activated "all addresses from the domain", he would be able to set
- email: admin@mycompany.com
- from_filter: mycompany.com
to use the mail servers for all email addresses in the same domain.
Task-3169015
Ticket-3141747
closesodoo/odoo#113959
X-original-commit: e9426c8b7bd4eb3d5c2c1c89fcf6ee3bdef95b3b
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce:
- go to any invoice
- click on Preview
- the lines after the invoice number are in separate rows
Bug:
here is bootstrap 4 implementation of `.col-3`
```
.col-3 {
-ms-flex: 0 0 25%;
flex: 0 0 25%;
max-width: 25%;
}
```
and here is bootstrap 5 implementation:
```
.col-3 {
flex: 0 0 auto;
width: 25%;
}
```
we can notice that bootstrap 5 changed the way that the width is
applied to the flex object.
now in https://github.com/odoo/odoo/pull/51715
the width property is overridden for the class `.col-auto` which is
not useful in bootstrap 5 anymore anyway. This creates a problem with
elements that are both `col-auto` and `col-3` as the override from
`col-auto` misses with the new `col-3` implementation
Fix:
remove the override of `width`
OPW-3171131
closesodoo/odoo#113938
X-original-commit: b9d19643cbdfb58531f5bd7020f26c905df9c5b8
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Signed-off-by: Mohamed Megahed Abbas Megahed SALLAM (mome) <mome@odoo.com>
Steps to reproduce:
1. Install Dashboard & Inventory (enable multi-locations)
2. Make inventory adjustments to have a location with negative stock
3. Go to the dashboard app & click on “Inventory On Hands”.
4. An error shows up: TypeError: chart.dataSource.getData() is null
Issue:
If one of the locations have negative stock, the pie chart will not be
displayed and it will throw many errors, It has the same behavior If
every location have negative stock.
Solution:
Discussed with the PO, when we have positive and negative values, we
want to ignore the negative values and display the pie chart with the
positive values only. For this case, we modified `_prepareData` and
`_isValidData` methods so they check and filter the positive values in
case we have any. For the other case when we don't have any data, that
can be displayed in the pie chart, we added a way to don't get any error
and only display a blank pie chart.
opw-3103967
closesodoo/odoo#113794
X-original-commit: 3fdfc357097fc77cb998e8a6794efe1f9ffa53bb
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Fixed the problem where the address of the delivery was not correct on
- emails
- order pdf
- order confirmation page
The solution is to create a new partner of type delivery linked to the existing partner.
We first check if the partner exists based on the address to avoid creating an infinite number of res.partner
Fixed the problem where the non-logged user could not check the pick up locations
Remove the possibility to pay if no carriers are selected
closesodoo/odoo#105848
Related: odoo/upgrade#4124
Related: odoo/enterprise#33986
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
The main goal of this commit is to add the possibility to use delivery/pick up points with the carrier Sendcloud.
The user can check the "Use Sendcloud Location" on the shipping method and choose the radius and radius unit to limit the distance between the address of the recipient and the pick up point.
As Fedex already had a similar feature and to prepare the pick up points implementation for future carriers, we factorized the existing Fedex code into the website_sale_delivery module.
The issue where it is impossible to select a pick up location when there is only carrier has also been fixed.
The factorization applies to :
- /controllers/main:
- set_access_point sets the address of the access point directly in the order
- get_access_point retrieves the data set in set_access_point
- get_close_locations calls the API of the carrier and returns the pick up locations obtained
- /website_sale_delivery.js:
- getCurrentLocation retrieves the location already set in the order and displays it
- _onClickShowLocations displays a dropdown with all the pick up points available in the area
- _displayCarrierDropper displays the button showing the dropdown
- _onClickLocation sets the location in the order
Part-of: odoo/odoo#105848
The `target` attribute for a link specifies where that link should open
(for example, in a new tab). Previously, copy-pasting links in the
website editor (within text blocks for example) would remove the
`target` attribute. This implied loss of functionality.
This commit whitelists the `target` attribute to fix that behavior.
task-3184150
closesodoo/odoo#113908
X-original-commit: 1464752aca36198e5fed5dc8f5b5041244e6e4a9
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The `isHtmlContentSupported` function incorrectly returned `false` for elements
inside `data-oe-type="html"` nodes even though those in fact do support html.
task-3184150
X-original-commit: 7d9a040fdefa527ace3150e39a03b833024b7973
Part-of: odoo/odoo#113908
Commit [1] added buttons with a `data-dependency` equal to "fake",
thinking it would hide those buttons automatically as the "fake" widget
would not exist. Somehow this got merged despite the fact that was not
working (testing probably focused on the more important things [1] was
fixing). At some point, using a fake dependency was hiding an element
but this changed one year earlier with [2].
This commit explicitly hides widgets with `data-dependency="fake"`.
[1]: https://github.com/odoo/odoo/commit/f59affcdfe9529645a02680214f3d7d96ebacf6e
[2]: https://github.com/odoo/odoo/commit/e927d1e89bc124002bb5e0b69dee711ea0d8147c
task-3208632
closesodoo/odoo#113936
X-original-commit: 7a46759a529b2d781585e0dbcb99bf7084c88007
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit: if "Automatic Receipt Printing" is enabled in a PoS
restaurant, and a printer is configured, an error will raise if the user clicks
on "New Order" before the end of the printing process.
To reproduce the issue, I added a sleep at the beginning of the
`_printReceipt` of `AbstractReceiptScreen`, and clicked on "New Order"
immediately after validating the order.
The solution is to keep the `currentOrder` in a variable before printing.
opw-3096677
closesodoo/odoo#113820
X-original-commit: 37a5d8197ba13d91f40c0495e0e14fb2825c21d6
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
Issue:
Since PR #80434, for versions 15.2 onward stock.move.line changed the
product_qty field to reserved_qty. When doing this change, the compute and
inverse function definitions were changed, but the inverse method on the field
was never corrected. This means that if something tries to write to reserved_qty
a traceback will occur:
AttributeError: 'stock.move.line' object has no attribute '_set_product_qty'
To recreate this error, make a write call on stock.move.line to reserved_qty
and you will get the traceback instead of the UserError.
Solution:
Change the field's definition to the correct function name (_set_reserved_qty)
leads to the proper UserError instead of a traceback.
opw-3204213
closesodoo/odoo#113812
X-original-commit: 5ac0568af2909864a2231309fa3e72397a581957
Signed-off-by: Tiffany Chang <tic@odoo.com>
In consumption warning, we add a new button that can correct all
qty_done according to should_consumed_qty.
closesodoo/odoo#113538
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Currently, if the user change qty_done on any raw moves without
changing qty_producing on the MO, it's not possible to validate the
order. In this commit, we make it possible to validate the order as an
immediate production.
When qty_producing is 0 and validate the MO:
1. manual consumption moves: current consumed qty will be kept when
process the MO.
2. non-manual consumption moves: For tracked components, if
use_auto_consume_compoents_lots checked, and there is enough products
reserved, the qty_done will be filled, otherwise, an error will be
raise to ask user to fill in lot/sn. For non-tracked components,
qty_done will be filled.
Task-3116125
Part-of: odoo/odoo#113538
When use_auto_consume_components_lots is on, it's always no manual
consumption on a MO even when the product is no tracked. Fix it
Part-of: odoo/odoo#113538
On the BOM, we add "Consumed in Operation" to a line, manual consumption
will be ticked automatically. In this commit, we make it that when
remove "Consumed in Operation" on a line, manual consumption will be
automatically unticked.
Task-3116125
Part-of: odoo/odoo#113538
Previously we set a component on MO to be manual consumption by comparing
the To Consume and Consumed, if they are not the same, we consider it a
manual consumption. Now if any input activity in the Consumed cell, we
will consider it a manual consumption.
Note that in the code, we make the css class change happended in the
list renderer instead of the field widget. We do that because we want to
change the background color of the whole cell not just the text of the
field.
Task-3116125
Part-of: odoo/odoo#113538
In 49bc9aac201136e684cac9d84df97f80d217afa4, when we need operation_id
when we check if manual_consumption is readonly or not, so
groups="mrp.group_mrp_routings" was added for manual_consumption.
As a result, we can't see manual_consumption on BOM when workorder is
not enabled.
To fix, we add a computed field as a workaround.
Task-3116125
Part-of: odoo/odoo#113538
**Before this commit**
- The optional "class" attribute set on the root node of a view arch
is ignored, except for the kanban view which has a custom
way of using it.
- The optional "js_class" attribute set on the root node of a view arch
does not have any impact on the class names passed to its controller.
**After this commit**
The content of the optional attribute "class" set on the root node of an
arch like in
<list class="o_custom_class">
...
</list>
as well as an additionnal class derived [1] from the value of the
"js_class" attribute set on the root node of an arch like in
<list js_class="extended_list">
...
</list>
will both be found in the prop "className" of any view controller.
[1] a js_class value of "xyz" yields to the class "o_xyz_view"
**Note on this commit**
The kanban view was already appending the root node class attribute
to its renderer element. This is no longer the case and some styling
rules has been adapted.
closesodoo/odoo#113014
Related: odoo/enterprise#37265
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
This commit changes some of the way that users will
work with subtasks in the project app.
Initially, it changes subtasks from a many2many to
a one2many field.
We also add the ability for subtasks to be viewed
straight from the kanban view by drawing a list of
them inside of the kanban box of the parent task.
task-3085016
closesodoo/odoo#112279
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
hr.holidays.summary.dept model is no longer existing in odoo and it seems the time off summary report action is also redundant and one is not used.
closesodoo/odoo#108001
Signed-off-by: Kevin Baptiste <kba@odoo.com>
This commit adds a company field to accruals.
Also removes the unused 'parent_id' field in hr_leave_accrual_level.
TaskID 2817577
closesodoo/odoo#88275
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Since commit [1], an `align-items-start` class is added when going from
grid mode to normal mode in order to always have one of the four choices
of the Vertical Alignment option selected. Indeed, without this class,
none of them are chosen. However, only a few snippets have this option
and it is therefore not possible to modify this class easily in the
snippets that do not have it (except removing it from the DOM manually).
The real issue in fact comes from the computation of this option widget
state, which should select the last button (so the `align-items-stretch`
one) if no class is present, since the behaviors are equivalent in these
two situations.
This commit removes the addition of this `align-items-start` class and
fixes the `_computeWidgetState` of the Vertical Alignment option.
[1]: https://github.com/odoo/odoo/commit/cc406afcea7bf5846233a9f97a4a8ac5f618f3ec
task-3142615
closesodoo/odoo#113949
X-original-commit: 75ef0d5d7ed000cf55b47bebb00cc2d0bb34b581
Signed-off-by: Vray Benjamin (bvr) <bvr@odoo.com>
Steps to reproduce the bug (in 16.0 and above only):
- Go in the backend
- Focus the searchbar
- Type something and use the arrow to navigate the search dropdown
=> You cannot see what you are highlighting anymore
This occurs since [1] (its forward-ported version) which removed rules
that were targeting the frontend dropdowns by mistake while they were
indicated as wanting to target OWL dropdowns only. It appears that those
rules were actually used by chance in 16.0: to style the searchbar which
is not using OWL dropdowns and whose specific 15.0 styles were removed,
fallbacking on those erroneous rules. On top of that, the wanted style
here concerns a rule about the `focus` class... which is actually not
part of Bootstrap 5 anymore but that our old searchbar still uses.
There is a high chance that the problem is only confined to the 16.0
searchbar and not anything else. But as a precaution this commit fixes
the issue by restoring all the rules that were removed (well, rather
moved to be more specific to OWL dropdowns) but inside a backend file
only. The legacy/dropdown.scss file seemed very suitable for this
purpose. Obviously, those rules should be removed as soon as possible
once it will be judged ok in master after a searchbar adaptation.
[1]: https://github.com/odoo/odoo/commit/e24bff699190bc511b357c200f4494a177be5b77closesodoo/odoo#113944
X-original-commit: 77537678d6b6f3533eb0c9d9d37d8fe679ef9580
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Steps to reproduce:
1. Login to Odoo 16.
2. Install Accounting app, apply Generic CoA, enable Analytic Accounting.
3. Create Analytic Plan with list of accounts. Departments for instance.
4. Create Invoice with any product, set financial account to 400000 Product Sales, and specify analytic account.
5. Post the Invoice.
6. Go to Accounitng -> Analytic Items. It should contian Analytic Item with financial account 400000 Product Sales.
7. Go to accounting -> Journal Items, find Journal Item related to our invoice where product and analytics were defined.
8. Mark journal item with checkbox to enable multi edit feature. Change financial account to 450000 Other Income.
Current behavior:
Analytic Item still has financial account 400000 Product Sales.
Expected behavior:
Analytic Item should be updated with financial account 450000 Other Income.
closesodoo/odoo#113940
X-original-commit: d0fdc38385f5f259da259d21e9137494e6d7c17d
Signed-off-by: William André (wan) <wan@odoo.com>
The call to check if the pos.order or the pos.order.line margin is zero
was considering the rounding precision as the number of decimal places.
opw-3179013
closesodoo/odoo#113931
X-original-commit: e3faa0659a0c6206740895e68face14c27af14a4
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: thco-odoo <thco@odoo.com>
The date format set on the Norwegian language is not kept when we click
on date fields
Steps to reproduce:
1. Install Sales
2. Install and switch to Norwegian language
3. Open Sales and create a new quotation
4. Click on the 'Quotation Date' field
5. The date format is changed from '%d. %b %Y' to '%Y/%m/%d'
Solution:
Change the default Norwegian date format to a valid static format
The format used comes from babbel[^babbel], double checked with the
Norwegian locale[^nb.js]
[^nb.js]: https://github.com/odoo/odoo/blob/16.0/addons/web/static/lib/moment/locale/nb.js#L25
[^babbel]: https://www.babbel.com/en/magazine/how-to-write-the-date-in-norwegian
Problem:
The old date format didn't pass the `isValidStaticFormat` test of the
date picker, so the default format 'yyyy/MM/dd' was used instead
opw-3191605
closesodoo/odoo#113926
X-original-commit: c27226e13392207811b61aceb3c77d1e9fcc180d
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
To reproduce the issue:
1. Install [Employees] app
2. Add some employee records if not there by default
3. Click on Print icon and [Print Badge]
4. pdf version will show borders
Issue: with the introduction of bootstrap5, setting the class became a necessity
Desired behavior: Make the borders invisible
Impacted versions: 16.0 up to master
opw-3126185
closesodoo/odoo#113925
X-original-commit: 0b78509b1bcba8547e0fe95ff4a14c7199adba92
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: Lee, Hansun (hale) <hale@odoo.com>
This commit addresses a bug in jQuery Draggable where the 'stop' event
did not trigger a 'mouseup' event outside of the dragged element window
if it was inside an iframe. This issue only occurred in Chrome (Firefox
was not affected).
In mass_mailing, this issue occurred in the email editor when the mouse
was released in the area above the editor. This error also affected the
Sign module, where elements can be dropped into a PDF, and where the
'stop' event of the dragging did not trigger outside of the iframe.
Steps to reproduce the bug in mass_mailing:
- Open the Email Marketing app.
- Create a new mailing.
- Choose the second available email template.
- Click and hold the "drag and drop" button of the first snippet (Your
logo) to start dragging it.
- While dragging the snippet, move the mouse outside of the email editor
iframe.
- Release the mouse button.
- Bug: the drop zones are still present in the DOM, and it is possible
to save the template with them.
opw-3164969
closesodoo/odoo#113893
X-original-commit: f083e664bfe5b6b6abeec7aeee242771a21d8710
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Samuel Degueldre