Steps to follow:
- Set your timezone to New York
In linux for example with: `timedatectl set-timezone America/New_York`
- Verify that the user timezone is also set to NY
- Create a reccurent event the 6 july 2022 (a wednesday)
- In options, check the recurrent box
- Set repeat to once every week
- Thursday is the only day checked
-> It should be Wednesday
Cause of the issue:
When `_compute_recurrence` is called, `event.recurrence_id` has not
yet been set
-> `event.recurrence_id.event_tz` is False
=> Copy the defaults before computing the start date and check the
timezone of the event itself
opw-2886253
closesodoo/odoo#96049
X-original-commit: 7186dbad38ef1f05919c398f3c0c5f5d8f8b2219
Signed-off-by: Arnaud Joset <arj@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
The code handling user presence and the one handling bus notifications
are mixed up. In order to ease the PR introducing the websocket in Odoo
and to clear this mess, the presence service has been introduced.
task-2053917
closesodoo/odoo#95981
Related: odoo/enterprise#29524
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit, when clicking on a link with the standard header as
anchor (e.g. Enable "scroll to top button" option to the footer in edit
mode). The scroll animation stopped before reaching the top.
This happened because we stop the scroll animation when the scrollTop no
longer changes. This is the case during the standard header transition
animation. It is only at the end of the transition that we can know that
there has been a change of scrollTop. So this commit makes sure to wait
for the end of the transition to check the scrollTop position.
This commit also adds a "z-index" on the footer "scroll-to-top" button
to place it on top of the elements around it. Before that, the entire
button area was not clickable because it was partly covered by the
elements around it.
task-2773973
closesodoo/odoo#96067
X-original-commit: 201298c66d86c27c1ee05489ccf5c70da88b7e14
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit improves the smoothness of the scroll animation to an
affixed header.
As in this case, we stop and continue the animation several times in the
"scrollTo" function, we need to force the easing of the animation to
"linear" when the scroll animation is restarted in the "progress" of
"animate".
task-2773973
X-original-commit: 1770f61ebd9ebd0991ee13a93f0e771c9c0ad698
Part-of: odoo/odoo#96067
When generating the PDF for the SnailMail report, a script is executed to
adapt the size of the address to match Pingen requirements (as per [1]).
Step to reproduce the issue:
1) Have a contact created that has VAT configure
2) Create an invoice and 'Send and Print'
3) Select the POST button to send via POST
4) In dev mode, go to Techincal > Snailmail Letters
5) Download the PDF of the newly created invoice
You should see that the font becomes extremely tiny.
Solution: There are different elements that needs to be corrected to solve the
issue.
1) The CSS used to specify the `height` requirement of the address was not
properly loaded (the path was incorrect)
2) The JS selector used into the resize script is incorrect
3) The CSS selector into the CSS file was invalid
All these issues are due to incomplete migrations.
[1]: https://github.com/odoo/odoo/commit/c50f5da4160c63dcc79900dc882cd36c9ad96b2e
opw-2819823
closesodoo/odoo#96055
X-original-commit: 7bbdbdcde2315155d17fb30d5496c3daf9a5c4cf
Signed-off-by: Florian Daloze (fda) <fda@odoo.com>
Signed-off-by: Desausoi Laurent (lade) <lade@odoo.com>
Since frontend to backend commit [1], links having `enable_editor=1` to
enable edit mode were not working anymore in certain cases.
Case 1 [OK]*:
From frontend, click on `enable_editor=1` link without `/@/` in it.
Case 2 [OK]:
From frontend, click on `enable_editor=1` link with `/@/` in it.
Case 3 [KO]*:
From backend, click on `enable_editor=1` link without `/@/` in it.
Case 4 [KO]:
From backend, click on `enable_editor=1` link with `/@/` in it.
This commit fixes case 4 and adds a test for all cases, while leaving
case 3 commented as it will be fixed later with a larger fix related to
URL change listener.
* Note that we will probably change the behavior for case 1 and 3: if
the version with /@/ + enable_editor=1 enters edit mode properly in
both frontend and backend contexts (case 2 and 4), it's probably not
worth having code to support case 1 and 3.
The issue for case 4 was that it was trying to load the whole Odoo app
inside of website preview iframe instead of making the parent window
load that URL.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3bclosesodoo/odoo#96054
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When creating a new manufacturing order with `move_finished_ids`
passed in the values, but `byproduct_id` is not amongst the move values,
the creation of the manufacturing crashed.
```
File "/home/odoo/src/odoo/master/addons/mrp/models/mrp_production.py", line 811, in create
vals['move_finished_ids'] = list(filter(lambda move: move[2]['byproduct_id'] is False, vals['move_finished_ids']))
File "/home/odoo/src/odoo/master/addons/mrp/models/mrp_production.py", line 811, in <lambda>
vals['move_finished_ids'] = list(filter(lambda move: move[2]['byproduct_id'] is False, vals['move_finished_ids']))
KeyError: 'byproduct_id'
```
By reading the implementation of the byproduct moves field:
```py
@api.depends('move_finished_ids')
def _compute_move_byproduct_ids(self):
for order in self:
order.move_byproduct_ids = order.move_finished_ids.filtered(lambda m: m.product_id != order.product_id)
```
it seems a better implementation to filter the move on the fact their
product is different than the manufacturing order to determine whether
they are byproduct or finished product moves.
Take the opportunity to write a unit test testing the tricky behavior
of the create override when both `move_finished_ids` and `move_byproduct_ids`
are passed in the create values.
This is related to revision
odoo/odoo@6c087f2043closesodoo/odoo#96044
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Due to a race condition, the chair product was sometimes added before
the js of the product configurator applied the changed attribute.
Changing the rhythm of the tour and making it clearer solves the problem
for the runbot. As the race condition itself will be solved soon with
the owl migration and isn't a problem customers can trigger themselves,
it was decided that it stays as is for now.
task-2909387
closesodoo/odoo#96041
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
This commit makes some adaptation in the scss of the website visitors
kanban view with respect to the introduction of the owl kanban view.
closesodoo/odoo#96003
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Since [1] when the media dialog was re-written in owl, the problem is
solved, this forward-port only keeps the added test scenarios.
See the description of the initial problem below:
Similarly to the comment introduced in [2], classes identifying a video
are only available before media.js begins to save.
This led to wronly inserting the pictogram in an incorrect location when
replacing a video by a pictogram.
This commit keeps track of the fact that a media node was a video before
being replaced instead of trying to find out after the classes have been
removed.
Steps to reproduce:
- Drop a "Text - Image" snippet.
- Replace the image by a video.
- Replace the video by a pictogram.
=> Was adding the pictogram in the first column's button instead.
[1]: https://github.com/odoo/odoo/commit/7fd0698cf765a79959566b51e33cb76bff83d344
[2]: https://github.com/odoo/odoo/commit/d4d25c8b497e465753cef030292faa4824145cb1
task-2729177
closesodoo/odoo#95963
X-original-commit: b50a8015da7bba3b156fa8941b6c2b17533159c7
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: test_website
Since [1] when the media dialog was re-written in owl, the problem is
solved, this forward-port only keeps the added test scenarios and some
of the code cleanup & comments.
See the description of the initial problem below:
Since [2] replacing an image by an icon then selecting the icon opens an
error popup.
After this commit there is no error when selecting the icon that
replaces an image because the editor of the replaced media is destroyed.
Steps to reproduce:
- drop a Text-Image snippet
- select the image
- replace the image by a pictogram
- click on a different snippet
- click on the pictogram
=> an error popup is displayed
[1]: https://github.com/odoo/odoo/commit/7fd0698cf765a79959566b51e33cb76bff83d344
[2]: https://github.com/odoo/odoo/commit/d934b81aaae8d68b5579d1489b1fbe8ea347b4ed
task-2729177
X-original-commit: e1c4b62601e5a76a36406d790c9ad2da91c54951
Part-of: odoo/odoo#95963
Co-authored-by: qsm-odoo <qsm@odoo.com>
Since [1] the file size is displayed only for images that support
processing (filter effect, crop, resize...) but when switching to an
image that does not support it, the old size remains displayed.
After this commit when an image for which the file size is not computed
is selected, the previous file size is hidden.
Steps to reproduce:
- drop a Text-Image snippet
- select the image => the size is displayed in the options block title
- replace the image with an animated gif
=> previous size did remain displayed (now size is not shown anymore)
[1]: https://github.com/odoo/odoo/commit/089ae3d28b5d2d7bdbaad133174ae54240113181
task-2729177
X-original-commit: 378f67749a51d8c0b9fb65767faceaa0844916e5
Part-of: odoo/odoo#95963
* test_discuss_full
channel invitation to rtc calls are now using the `ChannelMember` and
`mail.channel.partner` models instead of the `partner` and `guest`
models.
part of task-2692836
closesodoo/odoo#95898
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
`options` were not properly forwarded all the way to `_insertOtherRecord` which
lead to issues when a compute would try to insert an inverse that already
existed but for which the inverse of the inverse was not yet defined because it
also depended on a compute.
Part-of: odoo/odoo#95898
When creating a bill from a bill mail alias, we can end up with a tax or a product from another company
inside the bill. This can cause access issues afterward.
Here is a use case:
- Setup with 2 companies -> A and B
- Both companies have a 21% tax for purchase but the tax from company A has a lower sequence number
- Create an invoice in company A with a 21% tax and print the PDF
- Send the PDF by mail to company B
- The bill generated from facturx will have the purchase tax from company A
=> access error when it's opened
We use 'with_company' function with 'self.env.company' to imply a company to search into but this lead to
two issues when the generation comes from a mail alias.
1. 'self.env.company' may not be the company of the invoice
2. 'self.env.su' is set to True -> company constraints from the environment are not applied
This commit aims to change those two problems.
opw-2752673
closesodoo/odoo#96026
X-original-commit: b706eb6333913fb6c39cfa941f00c4bf499dfa3d
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Beckers Thomas (tbs) <tbs@odoo.com>
The field `company_currency` is indirectly used by portal users, and
does not seem to be a security concern in that context. But as portal
users cannot read companies, the field should be computed in superuser
mode. This apparently used to work by accident in the past...
closesodoo/odoo#95325
Signed-off-by: Raphael Collet <rco@odoo.com>
Merging both the memory of field values and suspended updates has
several advantages:
- avoid inconsistencies between cache and towrite
- cache updates can be made safer w.r.t. dirty flag
However, the dirty flag in cache does not go well with context-dependent
fields. When a context-dependent field is dirty in cache, the value to
store in the database is accessible through some context values. But
when the model is flushed, the context values on the current environment
may be different. When this happens, the method flush() fails to
retrieve the data to flush.
The proposed solution is to store the "dirty" value in cache under
conventional context values, and to retrieve them under the same
conventional context values to flush them. For instance, when storing
the value of a binary field, it will be stored once under the context
value `context.get('bin_size')`, and a second time under the context
value `None`. The flush implementation will then retrieve the value
using the context value `None`.
Translated fields are also problematic when a value is put in cache with
an environment where lang=False, and the value is retrieved with another
environment where lang=None. This issue is addressed by normalizing the
context key 'lang' to None when the context value is False.
Part-of: odoo/odoo#95325
Co-authored-by: Vincent Schippefilt <vsc@odoo.com>
The two modules both implemented the cart update warnings box
incorrectly, and differently (though in part because of later
changes):
- `aria-hidden` has meant `display: none` for a while, so the dismiss
button would never show up
- the class is alert-dismiss*i*ble, not alert-dismiss*a*ble
- unnecessarily complicated dom manipulation on updating the warning
- wishlist would go and update the cart badge by hand, unnecessarily
Extracted the warnings stuff to its own helper, with a fixed DOM, and
a slightly modified structure so it's possible to update the message
without having to rewrite the entire box content.
Also modified wishlist to update the cart badge via the existing
helper, this way both modules just call
updateCartNavBar(data);
showWarning(data.warning);
the same way in the same order, and everything is clear.
Also updated `updateCartNavBar`:
- removed the iteration as jQuery should be able to work on the set
- added the warning message and an icon if the quantity is 0 (could
not add to cart) as the separate warning may not be available on all
pages e.g. "recently viewed" product widget can appear anywhere,
previously was only set through wishlist
- keep reveal of cart quantity ancestor as on some pages it's not
visible by default (see previous item for user-case)
closesodoo/odoo#96047
X-original-commit: 2ff55c5fd684ab701cf143d3b0d46979759a8e9f
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
When creating an invoice from a repair order, the account mapping of the
fiscal position doesn't apply even though the tax one does
Steps to reproduce:
1. Install Repair and Accounting
2. Go to Accounting > Configuration > Invoicing > Fiscal Positions and
create a new fiscal position with:
- Name: 'FP test'
- Tax Mapping from 'Tax 15.00%' to a new tax 'Tax 10.00%'
- Account Mapping from '400000 Product Sales' to '450000 Other
Income'
3. Go to Sales > Products and create a new product 'Product A' with:
- Product Type: 'Consumable'
- Customer Taxes: 'Tax 15.00%'
- Income Account: '400000 Product Sales'
4. Create another product 'Product B' with same values except type which
is 'Service'
5. Go to Repairs and create a new repair order with:
- Any Product to Repair
- Any Customer (once set, edit the customer's fiscal position to 'FP
test')
- Invoice Method: 'Before Repair'
- Parts: add a line of type 'Add' with product 'Product A'
- Operations: add a line with product 'Product A'
6. Confirm the order, create an invoice and open it: the account mapping
of the fiscal position didn't apply (it should be '450000 Other
Income')
Solution:
Apply the fiscal position mapping on the income account of the product
opw-2902056
closesodoo/odoo#96038
X-original-commit: 02975a8a7b1803167a5ba8365cfbf29f80f84b2e
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
There was an issue with the computed `read_group` `__range` when grouping on
the same date/datetime field on multiple granularities (i.e. month, week).
Since the range was stored with the field_name as a key, the last evaluated
range would override the previous ones.
Impacted Versions:
- master
(- exists since 15.0 but it does not impact the user directly so it has been
decided to fix this only in master, since the API is modified)
Steps to reproduce:
1. Open a list view and group by a date field with at least 2 granularities
2. Open the chrome debugger (network) and check a web_read_group rpc preview
3. Find the web_read_group for groups related to one of the largest
granularities and check the `__range`
Current behavior:
- `__range = {field_name: false}`
Expected behavior:
- `__range = {field_name: {from: range_start, to: range_end}`
Explanation
Since the smaller granularities are evaluated last, and the condition to update
`__range` is related to the field_name and not the granularity, the range is
always overriden by the smaller granularities (even if their value is False)
when grouping on the same field with multiple granularities.
Furthermore, there is a conceptual problem with the current solution: it does
not allow to store multiple ranges when the read_group is not lazy and when
grouping on the same field with multiple granularities.
Therefore, the proposed solution is to use the full groupby keys in the
`__range` to allow storing multiple ranges depending on granularity. The keys
in `__range` would thus match the group value keys and allow more flexibility
if a domain must be forged from the group(s) range(s).
Task-2894519
closesodoo/odoo#95193
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Task 2888204
- Name is automatically split into code and name
- account_type is computed based on the closest parent of the code prefix (and can be changed)
- _onchange_name is needed to split name into code and name when creating from a related model's form
closesodoo/odoo#94171
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
*: calendar, iap_mail.
Now that the bus service is a wowl service, we don't need to wait for
the webclient to be ready before using it. Indeed, the services now
have the bus service as a dependency which means it will always be ready
in time. This also showed that the rpc service was missing as a bus service
dependency. It has been added.
Some part of the code were also checking if the bus service was in
`env.services`. Those calls have been removed as well since we now
have the guarantee that it is.
closesodoo/odoo#96002
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Some legacy services are still relying on the bus_service as a dependency.
However, this service is now a wowl service which means those services
won't start.
closesodoo/odoo#96001
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Issue:
sale order mobile view cannot show product_forecast_report.
Cause:
move_ids field is missing in the view.
Solution:
Add move_ids back to the view.
closesodoo/odoo#96000
X-original-commit: 9c19460ce7fb1a16cfeed607e474e273f5ce690b
Signed-off-by: Steve Van Essche <svs@odoo.com>
When dragging an article with an open nest, the `jquery.mjs.nestedSortable`
library does not refresh the positions of the following articles. This forces
the user to drag the nest far below the target position to move the placeholder.
This commit is a small fix to the library, to refresh said positions before
checking for element intersection.
Task-2883290
closesodoo/odoo#95749
Related: odoo/enterprise#29315
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Prevent a flickering effect when dragging item down in a nested tree using the
`jquery.mjs.nestedSortable` library.
Situation:
1.) start dragging, moving down and slightly to the left
.dragged item
.nest0
.nest00
.nest000
2.) intersect nest0
.nest0:hover:.dragged item
.nest00
.nest000
.drop destination
3.1.LIBRARY) intersect nest00 first trigger
.nest0
.nest00:hover:.dragged item
.nest000
.drop destination (frame 1)
3.2.LIBRARY) intersect nest00 second trigger (slightly below and to the left)
.nest0
.nest00:hover:.dragged item
.nest000
.drop destination (frame 2)
frame 1 and frame 2 are rendered almost simultaneously, and in a cycle (after
3.2. comes 3.1. again), resulting in a flickering effect.
3.1.FIXED) intersect nest00
.nest0
.nest00:hover:.dragged item
.nest000
.drop destination
drop destination is not allowed to go UP in the dom since the mouse is lower
than before. No flickering in this case.
To go up in the tree, the user can simply move the cursor to the right and/or
up.
The `jquery.mjs.nestedSortable` library will be rewritten internally in the
future to remove the jQuery dependency, but this fix allows a smooth utilisation
in the meantime.
Task-2883290
Part-of: odoo/odoo#95749
Step to reproduce:
- Go to 'My Preference' or User profile as admin
- Click on the world icon to add a language
Old Behaviour:
- Open the technical view of languages
New Behaviour:
- Open a wizard to add a a language
taskid-2774319
closesodoo/odoo#92855
Signed-off-by: Arnaud Joset <arj@odoo.com>
Due to the recent bootstrap changes one attribute on the carousel
indicators was badly migrated which caused bootstrap's carousel code to
throw an error.
This commit fixes that issue.
TaskId-2833507
closesodoo/odoo#92447
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
This commit adds a new display type for a product page, namely the grid
mode.
The web designer will now be able to choose between carousel (previous
mode) and grid.
The web designer may also choose how much space the images take on the
page between 0%, 50% 66% and 100%.
TaskId-2833507
Part-of: odoo/odoo#92447
Before this commit, orders were not confirmed when there was more than
one transaction linked to them, regardless of their state.
As of now, we check if there is only one confirmed transaction (meaning
that the state of the transaction is either 'authorized' or 'done').
Fix 4d2b04a843
task-2906040
closesodoo/odoo#95443
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The expense dashboard was displayed on the Expenses Analysis whilst it
shouldn't have.
closesodoo/odoo#95987
Signed-off-by: Kevin Baptiste <kba@odoo.com>
For zero percent taxes, when the repartition lines are defined as 0% of
the 0% tax, the DatiReipilogo elements are not generated.
This is because of the recent addition of a filter to the calling of the
_prepare_edi_tax_details inside of the function that generates the
values for the template. The filter specifies that the tax data
retrieved relates to repartition lines with a percentage > 0. This
excludes taxes that are 0% of a 0% tax (which would be the same as a
repartition line of 100% of a 0% tax).
The solution is to change the > to >= so that these 0% tax repartition
lines are included.
A test is created with an invoice with two 0% taxes. One tax has a 100%
tax repartition line, and one has a 0% tax repartition line. With the
fix, there should be DatiReipilogo for both taxes in the xml.
The reverse_charge_invoice tests are also fixed in order to ignore the
invoice name (which will change depending on how many invoices are
posted in the previous tests).
closesodoo/odoo#95966
Ticket-id: 2909394
X-original-commit: 089f59ef79c554d7517d8621bfaee03875ad6062
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Daniel Kosky (dako) <dako@odoo.com>
Steps to reproduce the bug:
- Create a storable product “P1”
- Tracking: by serial number
- BOM:
- Component: C1
- Create a storable product “P2”
- BOM:
- Component: P1
- Create a MO to produce one unit of P1:
- serial number: SN1
- Confirm and mark as done
- Unbuild the manufactured product
- Manufacture the same product using the same serial number again
- Create a new MO to produce one unit of “P2”:
- Component P1 → select SN1
- Try to confirm and validate the MO
Problem:
Get User Error: The serial number “SN1” used for component “P1”
has already been consumed
We do a search in the `stock.move.line` to find if the SN has already
been used in a previous MO, but there is no specific condition to get
only those used in an MO so the unbuild order is in the same condition
and therefore the SN is considered as it has already been used
opw-2883450
closesodoo/odoo#95935
X-original-commit: 5ac7f4d6fa5551ba7c6da49a52edf0a7df2d0745
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
*: bus, calendar, iap_mail, im_livechat, project, web.
In order to ease the PR introducing the websockets in Odoo, the bus service
has to be updated to be a wowl service. This PR takes care of it.
task-2053917
closesodoo/odoo#95824
Related: odoo/enterprise#29361
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Stpes to reproduce the bug:
- Create a storable product “P1”:
- tracking: Serial number
- BOM: 1 unit of C1
- Create the MO 1:
- produce 1 unit of P1:
- Create the SN1
- Create the MO 2:
- produce 1 unit of P1:
- Create the SN2
- Create an Unbuild order:
- Select the MO1
Problem:
You have the possibility to select any Serial number linked
to the product “P1”, whereas only SNs created in this MO can be selected
opw-2834529
closesodoo/odoo#95956
X-original-commit: 167b1668450c5af44bc1d36d1c7d59921bc2b811
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Adding a @depend decorator on product_id in the stock_move_line model can trigger a search on stock.move.line.product_id
When the number of StockMoveLine reach a million, a simple `SELECT id FROM stock_move_line WHERE product_id = XXX` can take 200ms.
When a transfer contains a few hundred StockMoveLine (ex: when dealing with serial numbers), the process of validating it will take a few minutes.
Indexing product_id will change the process time back to a few seconds.
OPW-2893131
closesodoo/odoo#95511closesodoo/odoo#95915
X-original-commit: b8156cf9a2d01448244c306c24c3c55687fd0d23
Signed-off-by: DavidFesquet <dafr@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Rémy Voet <ryv@odoo.com>
Since Bootstrap 5 migration, when we use the OWL `dropdown` component
it must have the class `o-dropdown-menu` and not `dropdown-menu`.
This commit replaces this class and also clean some CSS.
closesodoo/odoo#95899
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
This commit allows multiple salespersons to collaborate on a lead without
erasing each other's data.
closesodoo/odoo#95042
Taskid: 2900372
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Since 4f984568e1, the css theme is not
correctly applied to the website theme selector.
The order in which the css rules were applied without the
'.o_legacy_kanban_view' selector removed a margin from the
kanban_record element.
closesodoo/odoo#95936
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Before the change added in odoo/odoo#87990 the badges on the result
view were aligned on the right. However, this broke the mobile design.
This was changed to a bootstrap column view but the alignment was lost
in the process.
It is brought back using a text-right alignment, making sure the center
remains clean and the view open and clear enough. However, for very
small screens they are displayed aligned on the left. The column display
is kept.
Also harmonizes the spacing of the badge of matrix_subtype.
Task-2908045
closesodoo/odoo#95545
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
In a multistep configuration, decreasing the quantity on a line of a
confirmed sale order may create some inconsistencies.
To reproduce the issue:
1. In Settings, enable "Multi-Step Routes"
2. Edit the existing warehouse:
- Outgoing Shipments: 3 steps
3. Create a storable product P
4. Set the on-hand qty to 5
5. Create and confirm a sale order SO with 5 x P
6. Process the PICK/PACK pickings
7. Edit the SO:
- Decrease the qty: 3 x P
8. In the SO's deliveries, open the return of the pack step (Output ->
Packing)
- Error: Nothing changes, there isn't any reserved quantity.
However, there are currently 5 x P at the Output location, so the
reservation should work
9. Inventory > Report > Stock Moves, list all SM related to P
- Error: The origin/destination moves of the pack's return (Output
-> Packing) are incorrect too: the origins contain the pick's return
(Packing -> Stock) while it should not contain anything and the
destination moves contain the ship move (Output -> Customer) while it
should contain the pick's return (Packing -> Stock)
`SM_ship`: SM used to deliver from Output to Customers
`SM_ret_ship`: SM used to return P from Customers to Output
`SM_ret_pack`: SM used to return P from Output to Packing
`SM_ret_pick`: SM used to return P from Packing to Stock
When confirming a move, we transform the move if its demand is negative:
https://github.com/odoo/odoo/blob/53b424d9e43b07fe7aa84ff00035fb7772ef6291/addons/stock/models/stock_move.py#L1239-L1247
We reverse the source/destination locations but we don't do the same
with the origin/destination moves. That is an issue: before reversing,
we have:
| SM | Qty | From | To | Origin | Destination |
|-------------|-----|---------|-----------|-------------|-------------|
| SM_ret_pick | -2 | Stock | Packing | / | SM_ret_pack |
| SM_ret_pack | -2 | Packing | Output | SM_ret_pick | SM_ret_ship |
| SM_ret_ship | -2 | Output | Customers | SM_ret_pack | / |
Therefore, reversing the source/destination locations without updating
the origin/destination moves does not make sense: we should reverse them
too depending on their direction (positive/negative) and their
source/destination location.
Also, before trying to transform the moves, we try to merge them:
https://github.com/odoo/odoo/blob/53b424d9e43b07fe7aa84ff00035fb7772ef6291/addons/stock/models/stock_move.py#L1236-L1237
This is relevant for `SM_ret_ship`: we find an existing SM (`SM_ship`,
qty=5) that can absorb the negative demand of `SM_ret_ship` (qty=-2). In
such case, we add the origin/destination moves of the negative SM to the
positive one. However, in the above case, it will create an
inconsistency: after the fix, at that point, `SM_ret_pick` and
`SM_ret_pack` have been correctly reversed, so we have:
| SM | Qty | From | To | Origin | Destination |
|-------------|-----|---------|-----------|-------------|-------------|
| SM_ret_pick | 2 | Packing | Stock | SM_ret_pack | / |
| SM_ret_pack | 2 | Output | Packing | SM_ret_pack | SM_ret_pick |
| SM_ret_ship | -2 | Output | Customers | / | SM_ret_pack |
| SM_ship | 5 | Output | Customers | (SM_pack) | / |
Therefore, adding `SM_ret_pack` to the destination moves of `SM_ship` is
incorrect. (Note that, without the fix, `SM_ret_pack` would be added to
the origins of `SM_ship`, which would be incorrect too)
Finally, the reservation (step 8) does't work because of two reasons:
- If there are some `move_orig_ids`, we use the done value of these SM
to assign the current SM. However, as explained above, there is an issue
with this field
- If there isn't any `move_orig_ids`, there is an issue with the procure
method. Its value is `make_to_order`: we skip the reservation for such a
value:
https://github.com/odoo/odoo/blob/53b424d9e43b07fe7aa84ff00035fb7772ef6291/addons/stock/models/stock_move.py#L1499-L1501
OPW-2889679
closesodoo/odoo#95263closesodoo/odoo#95926
X-original-commit: fb94c140a91aca26a56c5162d61b00b4a4b0d85b
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
After the change in account_type field in account.account the old selection widget didn't work.
Fixing the selection widget and adding it back on acocunt_type field.
As account types cannot be custom anymore, the account types within the hierarchy can be hardcoded.
closesodoo/odoo#95821
Signed-off-by: Cedric Snauwaert <csn@odoo.com>
When an invoice line has a display_type, account addon is expecting
account_id=False in vals. Replacing the normal dict access with a
`get` will fix the error when invoicing with note/section lines
without explicitly specifying the `account_id` to be false.
closesodoo/odoo#95894
Signed-off-by: Masereel Pierre <pim@odoo.com>
Before this commit, it happened that the domain selector
couldn't find the operator linked to the field.
This commit adds a fallback on the existing operators
to find an operator that matches.
for example the domain `[["name", "like", "M"]]` gave
`Name ? "M"`, now it correctly gives `Name like "M"`.
closesodoo/odoo#95891
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Hubert Van de Walle (huvw)