The `date` widget, when used with a datetime value, doesn't offset the
value relative to the session timezone. This can lead to strange issue
like this following one
date1 = 12/03/2023 05:34:12
date2 = 12/03/2023 18:34:12
in the deliveryslip report, the datetime are casted as date, they become
date1 = 12/03/2023
date2 = 13/03/2023
closesodoo/odoo#114983
Opw: 3199862
X-original-commit: b6757daac6272092c37024ac2bdd49747177d2bc
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
*: web_tour, website_blog
Since [1] when the search box autocomplete was introduced, the URL
parameters are implicitly included into the RPC that fetches the
autocompletion results.
Those parameters were not correctly unescaped before being sent to the
RPC call.
Because of this, a timestamp such as "2023-01-01 23:00:00" was sent as
"2023-01-01+23%3A00%3A00" to the server. If that string reached the SQL
layer, the "+" was interpreted as defining a timezone.
This commit unescapes the URL parameters before using them in the RPC.
Note that javascript's `decodeURIComponent` does not handle the '+'
encoding of spaces inside URL parameters.
For testing purpose, the following updates were needed to make it
possible to select the `<option>` within the Archive month `<select>`:
- because the `option`s are in a tree, the tool was adapted to take all
`option`s into consideration instead of only the direct children of the
`select`.
- because the `option` text is dynamically created from the date of the
test execution, the tool was adapted to allow targeting an `option`
based on its index by specifying the tour step's `run` as
`'text index N'`, `N` being the index of the `option`.
Steps to reproduce:
- Enable the sidebar of the `/blog` page.
- Select a month in the sidebar.
- Type something in the search box.
=> Did show an error popup while obtaining the autocompletion records.
[1]: https://github.com/odoo/odoo/commit/7559626c54e34b41e1549e28276a650accec6986
task-3213916
closesodoo/odoo#114913
X-original-commit: 115fc399461c37b57127684cf5c28f05443fbb54
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
During revision 415525cecc
the code comparing the connections without password has been
dropped, for an unknown reason.
Because of the above, and the fact psycopg2 alter the password
with 'xxx' for security reasons, the connections recycling was
no longer working as expected, and was recycling less connections.
closesodoo/odoo#37005
Signed-off-by: Rémy Voet <ryv@odoo.com>
If an invoice is send to the Tax Agency, we should block the fact
that the user can delete it. In that case, we can have issues when
the tax agency sends back notifications.
Task link: https://www.odoo.com/web#id=3192962&model=project.task
Task-3192962
closesodoo/odoo#114872
X-original-commit: c11a512af4e467068c6b228bf55225e5e43d7811
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
This reviews [1] which solved the problem in most cases (hopefully) but
not in all cases. Animated elements which overflow the screen on the
right made an horizontal scrollbar appear on iPhone <= 8 using Safari,
even when they were not animating yet.
This was due to Safari ignoring the `transform: none` rule on inactive
elements, preferring to consider the animation transform. As a fix, we
forced no possible overflow of the page when we saw this safari bug on
the first animated element.
The problem here... is that this Safari bug does not occur in every
situation. For example, if the animated element is inside a column which
is marked as hidden in mobile, Safari actually understands the no
transform rule. So if the first animated element was in such a situation
but another element in the page had the safari bug... the problem was
there again.
As a fix, we now check all animated elements for the Safari bug, instead
of only the first one. That should do the trick.
This commit also reviews the comment: the problem is not confined to
old iPhones. This was reproduced on the latest iPhone with latest iOS
and up-to-date Safari.
opw-3204613
opw-3201937
Related to opw-3165651
[1]: https://github.com/odoo/odoo/commit/c1447835786e04f342342540c09e46d1226d5fc0closesodoo/odoo#114999
X-original-commit: 8fe2d91e05e85ae2e50f1066214d0af5796e5296
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Issue: when use t-if to display text and use mutli line, the white-space
are removed.
```
<div>
<t t-out="nb"/>
<t t-if="nb == 0 or nb == 1">product</t>
<t t-else="">products</t>
</div>
```
is rendered:
```
<div>
3products
</div>
```
closesodoo/odoo#114986
X-original-commit: 3150a3769ff4d762c0e52dab31a70b59292c1bcc
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit fixes the behavior of the FileInput component. Since the html
element of type input doesn't trigger its onChange when a file with the
same name is given twice to the input, we must first clear the input value,
which will cause the input to handle the file even if the input already
contains this file.
Even if that seems unnecessary, this is an easy way to fix issues in the
base_import action were data are not send back to the server when re-uploading
the same file to let the server process the data.
A test has been added to assert that the onUpload is effectively called twice
when uploading a file, even if it's the same exact file.
closesodoo/odoo#114978
X-original-commit: d4a23c521d0e15f893d74e3530bc68ef19641f48
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Signed-off-by: Luca Vitali <luvi@odoo.com>
When using the 'toggleDeviceVisibility' option, we can see that there is
a mismatch between the screen breakpoint at which the elements are
displayed like in mobile view (=> under 992px or `lg`) and the one that
is impacted by the 'Hide/Show' option (=> at 768px or `md`). This is
a problem because between these two breakpoints, the display is like in
mobile view but is not considered as such and so, hiding/showing an
element in the mobile/desktop view (for example, if it does not look
good in one of them) has no effect until the screen reaches 768px.
This commit increases the screen breakpoint at which the 'toggleDevice-
Visibility' option is applied, that is, at 992px instead of 768px, in
order to be consistent with the display.
task-3110770
closesodoo/odoo#114977
X-original-commit: b062b280fdadcde857fff4f7a57876da50542cb3
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Signed-off-by: Bojabza Soukéina (sobo) <sobo@odoo.com>
In order to make the model reactive, it must not be an EventBus. An EventBus cannot be reactive. So we will add a key bus to the model that will always trigger all events that were triggered on the model before.
Part of task 3179751
closesodoo/odoo#114975
Related: odoo/enterprise#38032
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps to reproduce:
- Install stock
- Config > Shipping > enable Signature on delivery orders
- Create delivery order > Validate
- Switch to mobile view
- Action > Sign
Issue:
We get a traceback: `Uncaught Promise > Component is destroyed`.
This happens because the signature widget is destroyed when the Action
dropdown is folded.
Solution:
Use the orm service in `this.env.services` to perform the `write`.
We have to also update the view in order to see the new delivery slip.
opw-3133731
closesodoo/odoo#114954
X-original-commit: ad555010ea668324aeee21f8aabd41fe352eb0f5
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Stefan-Calin Crainiciuc (stcc) <stcc@odoo.com>
Currently the below use-cases are hardly supportable, though quite common:
Retail: Sell product in one shop and return it in another one
Restaurant: Managing payment when having multiple checkout desks,
and multiple waiters (only taking orders)
This because currently:
PoS orders are only known by the cashier desk (pos.config) they were created from
One floor map can only be linked to one cashier desk at a time
More over, with the Self-Service coming along the way
(where kiosk orders must be accessible from a cashier desk),
this need must be supported.
For restaurant, floor plans can be linked to multiple cashier desks,
ongoing orders are shared between trusted PoS config
(through floor plans for restaurant and according to
the setting "Trusted PoS config" for the retails),
and past orders can be accessible from any desks within a same DB.
closesodoo/odoo#109216
Related: odoo/upgrade#4393
Related: odoo/enterprise#37955
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
State `done` means *Locked*, which means that most of the fields should not be
editable.
However, the behavior for the field `warehouse_id` was changed during refactoring in
https://github.com/odoo/odoo/commit/f9f68adb2cdfdfd16bc24c82acae015ddfb9b83a
This commit restores Odoo 15 behavior in Odoo 16+
opw-3204896
closesodoo/odoo#114973
X-original-commit: 9efc8190565db160615f8a3e92f2e7f89edfca8b
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Remove the existing t-if on m2o_avatar_user/m2m_avatar_user widget
on user_id field in"project.project.kanban" view to allow quick-assign.
closesodoo/odoo#114400
Task-id: 3121207
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The goal of this commit is to add the avatar when a user use the
autocomplete m2o/m2m_autocomplete liked to a m2o/m2m_avatar_field.
Task-id: 3121207
Part-of: odoo/odoo#114400
Purpose:
Allow quick assignation of records in the kanban views (and other places
by extension).
Currently, if you want to work in a board-like env (e.g. tasks in
kanban, crm in pipeline, that kind of thing), having the possibility to
quickly assign/unassign records without having to open them fullscreen
can be really useful => it should be possible to "quick edit" these
fields in kanban views easily, without switching to form views.
If you want to keep the field readonly don't forget to add the readonly
attribute.
Task-id: 3121207
Part-of: odoo/odoo#114400
Purpose:
Allow quick assignation of records in the kanban views (and other places
by extension).
Currently, if you want to work in a board-like env (e.g. tasks in
kanban, crm in pipeline, that kind of thing), having the possibility to
quickly assign/unassign records without having to open them fullscreen
can be really useful => it should be possible to "quick edit" these
fields in kanban views easily, without switching to form views.
If you want to keep the field readonly don't forget to add the readonly
attribute.
Task-id: 3121207
Part-of: odoo/odoo#114400
The goal is to take into account the confirmed
and un-invoiced sales orders in the total receivable of a client.
It will be useful in the scope of the credit limit trigger.
This is broken down in 3 steps:
1. Add the Remaining Amount to Invoice (RAI) in the
Invoice creation wizard of the Sales Order and store this data.
2. Add the RAI in the Total Receivable of the client.
3. The Remaining amount to invoice goes to optional="hide"
in the list view of "Orders to invoice" list view.
task-3122390
closesodoo/odoo#112905
Signed-off-by: William André (wan) <wan@odoo.com>
Before this commit, attachment preview could be displayed
in x2m dialogs. Now, the compiler removes the attachment preview
from the arch so it is never displayed in renderer.
closesodoo/odoo#114967
X-original-commit: 4938d27da71da1e30899bad80c9cad3cb96aa417
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
Since [1], some mass_mailing snippet templates now have images with
shapes by default. However, the shapes were not added correctly:
- for the Blockquote snippet, the files specified are not correct (wrong
names and wrong extensions).
- for the Team snippet, the shapes are not present when dropping it.
This commit fixes that by properly adding the shape images as defined in
the commit [2]. It also removes the "circle images" files as they are
not necessary anymore. The basic shapes were also fixed by removing
their width and height, since the dropped snippets looked weird because
their images have a default width smaller than the shapes.
[1]: https://github.com/odoo/odoo/commit/f4995f560003c2180ad3cef50e1b172a151e50c8
[2]: https://github.com/odoo/odoo/commit/eb1262960f54fd81424a86ef4d6693a950e76cb4
opw-3137732
closesodoo/odoo#114966
X-original-commit: b1a3a3b18370ad76280726298602815769dce1c2
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Some Luxembourg public institution do not have a VAT number but have
been assigned an arbitrary number (see:
https://pch.gouvernement.lu/fr/peppol.html).
This requires a new field: `l10n_lu_peppol_identifier`. For Luxembourg,
the flow is then as follows: when exporting an electronic invoice, if
the field exists and is set, we read it. Otherwise, we read the VAT.
opw-3186147
closesodoo/odoo#114960
X-original-commit: 4b1b9b497931ae3c27a6a980a49107abec5650ec
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Julien Van Roy <juvr@odoo.com>
Steps to reproduce:
- Create 2 accounts:
1)
* Code: 1000
* Account Name: Test
2)
* Code 1000A
* Account Name: TestA
- Create a journal item for each account
- Go to Accounting / Accounting / Journal Items (list view)
- Add custom filter: ("Account", "is equal to", "1000 Test")
Journal items from both the created accounts are retrieved.
As a strict equal is requested, it shouldn't find the journal item
linked to account "1000A TestA".
Cause:
When searching on an account, the first part of the search is used
to find a code that begins with that part (ilike operation), regardless
of the actual operator (i.e. "=" in this case).
It has been done that way because we suppose that most of the times
customer is starting his search with the beginning of the code of the
account he is searching, which is not incorrect.
But the case of the "=" operator has not been handled.
opw-3179681
closesodoo/odoo#114927
X-original-commit: dfd9bee8c07b927a97823eb8ede7dc2b2a4c435a
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Anh Thao PHAM <pta@odoo.com>
To reproduce the issue:
1. In settings, scroll to "Contacts"
2. Click on the "?" bubble next to "Send SMS"
3. The page that opens is 404
Error: In the url of the opened page, there is
"saas~16.1+e" instead of "saas-16.1"
Added parsing to the server version in url
OPW-3198672
closesodoo/odoo#114941
X-original-commit: 424ec17af513de0a55fd946e6494a425c9fff39e
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
when plan workorder, cancelled/done workorders are taken in to account
when they block current workorder. In this fix, we ignore then when plan
workorder.
Task-3126569
closesodoo/odoo#114940
X-original-commit: 1b629659cb651c62fdd2c880ae591f9a9bb2e1eb
Related: odoo/enterprise#38020
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Wrong key was used to display the unit of measure in the BoM Overview,
leaving the cells empty.
closesodoo/odoo#114934
X-original-commit: a6eba909a8f2ab07ddb239b4b64e82d51f724e66
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
This issue was caught in Sentry.
The return type of the partner avatar for public users is `odoo.http.Stream`,
but the `route_wrapper` expects it to be `Response streamed`.
sentry-3929988311
closesodoo/odoo#114933
X-original-commit: 62ddfe0badf54375bc458bdb50cbcdbe4da5bbcd
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This commit will rename the font "Muli" to "Mulish" as it has been
renamed in Google Fonts.
closesodoo/odoo#114932
X-original-commit: c24602e882f87c361866a739459a9d6e3f4fc6ef
Related: odoo/design-themes#638
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
When duplicating an analytic account, we want to make more explicit
which account is the duplicate and which one existed before.
task-3202027
closesodoo/odoo#114931
X-original-commit: d499b9da8ba1b46db0671f14658a55095c68921d
Signed-off-by: William André (wan) <wan@odoo.com>
- Create a product with a very long product description
- Add in a PO and print the RFQ
The description overlaps with the table header on the second page.
This is a known issue of wkhtmltopdf (see issues 1770 and 1524 for
example), and there is no known workaround. It can be avoided by
preventing the repetition of the header.
closesodoo/odoo#114916
Opw: 3208347
X-original-commit: cc5be8a907b2c3f33c6a62c5693726d757ffd113
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Amounts in the spredsheet Sales dashboards are displayed without their currency
even though the amounts are all correctly converted to the current
company's currency.
With this commit, amounts are displayed with their currency in the
dashboard, list view and default form view.
The hardcoded number format is removed on the dashboard cells to let
the automatic format do the job
Task 3167343
closesodoo/odoo#111702
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
The last view in the odoo codebase has just been converted to owl,
meaning that we no longer have legacy views. This allows us to
remove a lot of legacy view related code: the abstract elements on
which the legacy views were built, the compatibility layers that
allowed to deal with both owl and legacy views uniformly, legacy
widgets that were only used in those legacy views...
closesodoo/odoo#114893
Related: odoo/upgrade#4420
Related: odoo/enterprise#38005
Signed-off-by: Géry Debongnie <ged@odoo.com>
This commit changes the function isInvisible visibility to private on
the record, this means that outside the record, the modifiers need to be
evaluated.
Part-of task-id 3179751
closesodoo/odoo#114891
Related: odoo/enterprise#38009
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
This commit addresses a bug where the "description" field on the user
screen was not displaying properly. This fixes the formatting issue,
ensuring that the field is now properly displayed with appropriate line
breaks and spacing. Users can now view their description information as
intended.
closesodoo/odoo#114881
X-original-commit: 52858350a78856e7da444617dc2779a2f19688a0
Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
If applied, this commit will solve the KeyError of 'list_ids'.
Before this commit
=======================
When there are no Mailing Lists available and add the snippet 'Newsletter block'
in the website with the template 'Form Subscription' and any user tries to
Subscribe to that form. It will raise an error like KeyError: 'list_ids'.
After this commit
========================
In this commit, checking keyword arguments which have list_ids in this or not if
list_ids not in that returns the error like 'Mailing List(s) not found!'
see - https://tinyurl.com/2n3o7s58
sentry - 3949183926
closesodoo/odoo#114871
X-original-commit: 360579977634c38c1cd6287c03e7c06796b408b1
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Currently, all localizations of UoM fields are visible in all countries.
So in this commit, I have added a new compute field in UoM models, the field
contains comma-separated company's country codes, and I have used this field
for the hide/unhide fields.
closesodoo/odoo#112604
Related: odoo/enterprise#36572
Related: odoo/upgrade#4284
Signed-off-by: Josse Colpaert <jco@odoo.com>
Before the fix, the compute function is set as a string in the `default`
parameter. Meaning that it will always be True because a non empty
string is truthy.
Fix by converting the field to be compute-editable, like the function
was designed to be.
closesodoo/odoo#114904
X-original-commit: 11121120b13fc7500ee720f10964de6b9a0373af
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
The main objective of this commit is to make checkboxes consistent
and fix their spacing issues.
Prior to these changes, the checkboxes on the `product_view` were
too close to their neighboring option labels, making it difficult to
know which checkbox to tick.
The new changes fixes inconsistencies in general such as undesired
hovering effects and the cursor behaviors on disabled inputs.
This commit also removes the margin in the checkbox template since the
padding from the checkbox wrapper compensates for the spacing between
the checkboxes and their respective labels.
Tweaking the selector in `settings_form_view.scss` to ignore boolean
field inputs allows us to get rid of max-width and margin overrides
introduced in commit b90059e936.
Most checkboxes were already falling under their labels on mobile, but
this change impacted those that were not. To address this issue, we
decided to consistently change the position of the checkboxes left to
their labels for small devices in form view.
This required slight adjustments to the `form_group.xml` template.
Still in form_view, for some of the specific checkboxes such as
`o_checkbox_optional_field` the changes in `form_controller.scss` are
made to mimic the new behavior for mobile sized screen.
However, if they are using the form_group template, their behavior
is unchanged at the moment.
Finally, even if these changes makes it better for most of them, some
checkboxes in `settings` still require some minor adjustments and will
be addressed in task-3113372.
task-3094083
closesodoo/odoo#114612
X-original-commit: ddb7574f97f11e69f0304c8bd8d55c2c53ab53fd
Related: odoo/enterprise#37887
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
The `t-cache` used on the `<head>` of website.layout was wrong: it
depended on the use of debug=assets or not (added by [1]) while it
should at least also depend on debug=tests. This commit chooses to fix
the issue by not using the caching system in case any value of debug
is used.
This commit also comments this `t-cache` value.
Steps to reproduce:
- As a visitor, first visit the homepage without debug mode
- Now reach the homepage with ?debug=tests
=> You still don't have the tests assets
Worse (but unlikely in production of course):
- Create a fresh DB and first reach the homepage with debug=tests
=> Now all your visitors are damned to load the tests tours for no
reason (and you likely have lots of errors shown in your console).
[1]: https://github.com/odoo/odoo/commit/3061a484168ff21e3ae7e40ce691d299b63484a4
opw-3203912
closesodoo/odoo#114875
X-original-commit: 5efb637d880f82ea81bb64a0d091ffa7bdf7635b
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Many of our users have a default OS/browser zoom of 150% when using a
1920x1080 (Full HD) screen. One cause is that this is the recommended
zoom when using Windows. Whatever the reason: many users have a
1920x1080 screen combined with a 150% zoom... and in that case, entering
edit mode would display the website as it would be on "mobile" devices.
This is because since [1], the website is actually reduced in size when
entering edit mode since an iframe is used, whose size is reduced by
the size of the right panel. Before [1], the right panel would be
*included* in the website which would appear reduced but using CSS rules
according to the full screen width (which also led to other issues but
this is in the past now).
The sidebar was actually 3px too wide. Reducing it from 291px to 288px
solves the issue (at least if the OS task bar is not anchored to the
left/right). Indeed 288px is 1920px / 150% - 992px, where 992px is the
current minimum width the screen must have for our websites to be in
"desktop" mode (below, columns break over multiple lines).
Notice that 1920px / 150% = 1280px which gives the minimum size of the
screen that will display the website in "desktop" mode in the editor if
no zoom is used, which seems like an acceptable value.
Note: reducing the sidebar width even further to support more devices or
more zoom / OS task bar configuration would be problematic as the
sidebar would become too small. It is currently kinda at both its
maximum and minimum authorized value.
We tried solutions to virtually "de-zoom" the website iframe to display
the website in "desktop" mode no matter what but this did not give great
results. On problematic devices, the user still has the possibility to
de-zoom its browser by himself.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3bclosesodoo/odoo#114873
X-original-commit: e3ab91188173a47bdc827d8f0e45efcf7b246a4a
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: l10n_co_pos, l10n_fr_pos_cert, point_of_sale, pos_loyalty,
pos_mercury, pos_restaurant, pos_sale, pos_sale_product_configurator
This is a step in the direction of making the pos no longer depend on
the legacy environment.
closesodoo/odoo#114668
Related: odoo/enterprise#37906
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Prior to this commit, if the window was big enough to not be in mobile,
it could still be small enough so that the menu items overlap with the
systray item when the website client action was first mounted.
Steps to reproduce:
- Choose a language with long words (such as Slovak) or translate one of
website app menu terms to a word with more than 12 characters
- With the browser's dev tools set screen size to be responsive with a
resolution of 847 x 867
- Start odoo and go in the website app
- The menu items overlap with the systray items
This commit fixes that by not only re-rendering the navbar when the
website content is properly loaded (which was already done before) but
also by adapting it afterwards. However, to do so it copies the code
already present in the "web" navbar.
task-2687506
closesodoo/odoo#114869
X-original-commit: 690f420ceae799ed991f49afa405c917b3c101d2
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Since #91640, the locations on stock picking are editable except in `done` state. This can leads to misunderstanding if some stock move lines
are already created. The locations on stock picking act as default
values for stock move/ stock move lines. Validating a picking will
always use the location set on stock move lines even if those ones
differ from the picking. This commit adds a simple error message in
to address this situation.
Close#113486
opw-3148993
closesodoo/odoo#114868
X-original-commit: 3eeab703f4e36723eae6005cf4b966f20f1e62dd
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Current behaviour:
If you have a confirmed SO, with a `sale.order.line` that has a
`product_packaging_id`, and you write a new `product_packaging_id`,
the "Delivery Order" has 2 lines, 1 move with the old qty and the old
packaging, and another line with the difference of qty and the new packaging.
Same behaviour is present on purchase side.
Expected behaviour:
If you have multiple `stock.move.line` from the same `sale.order.line`,
they should be able to merge, when you changed the `product_packaging_id`.
Ex: If you edit an SOL from 1 pack of 10 to 1 pack of 20, we should have
1 move line with qty 20 in packs of 20, instead of 2 lines, one with qty 10
in packs of 10, and another line with qty 10 in packs of 20.
Same behaviour is expected on purchase side.
Steps to reproduce:
- Install Sales and Inventory
- Activate "Product Packaging" in Settings
- Create a new product with 2 types of packaging
- PackOf10 with quantity of 10
- PackOf20 with quantity of 20
- Create a SO with a new line that product, quantity 10
- Confirm the SO
- Edit the SOL with 1 pack of 20 (`product_uom_qty`=20)
- The "Delivery Order" has 2 lines, instead of 1 with the new packaging
Reason for the problem:
When saving the SO/PO, a new `procurement` is created which will create
a new `stock.move.line` with the new packaging. This will prevent the
lines to merge correctly, because they have different packaging.
Fix:
When writing the `product_packaging_id` on a `sale.order.line`/`purchase.order.line`,
we directly write the package on the `stock.move.line`,
before any `procurements` are created, so the generate move lines
can correctly be merged.
Affected versions:
- 15.0
- saas-15.2
- saas-15.3
- 16.0
- master
opw-3002612
closesodoo/odoo#114866
X-original-commit: 87ed4b2f6c9c36202a1a4f3de143f638cf38d047
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
Before this commit, only the immediate parent of a selected node was
checked for HTML content support in order to determine the toolbar's
visibility. This led to incorrectly displaying the toolbar for fields
like the 'list-price' on an e-commerce product page, whose text content
is wrapped in an extra 'span' element inside the field's span element.
This commit fixes it by checking all of the node's ancestors up to the
editable root for the attributes that determine if a field supports HTML
content.
This commit also prevents a server error if the user somehow styles the
product's price (with ctrl+B for example. It's worth noting that such
style would not be kept in the saved version of the page).
lxml.HtmlElement's `text` property has `None` value if the span element
does not contain any text before its first child element
(see https://lxml.de/apidoc/lxml.html.html).
Therefore an element like `<span><strong>42.00</strong></span>` would result
in `None` when reading its `text` property.
The `text_content` method is more suitable for such task as it returns the
text content of an element and its children.
task-3188550
opw-3171669
closesodoo/odoo#114867
X-original-commit: 524ba7f89286aa03ed6a4da30177c9ce7018c59a
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This commit adds a new service called "timesheet_uom", this service will
help to find the right component to use for the `timesheet_uom` widget
sicne this widget could be float, float_factor, float_toggle or
float_time widget. This service also adds the right formatter to use for
this widget to correctly format the value when the formatter is used
instead of mounting the component.
task-2702636
Part-of: odoo/odoo#108605
Before this commit, the default employee set in the context to create a
timesheet is unused in the create method.
This commit uses the context to set the employee when no user and no
employee are given in the vals parameter.
task-2702636
Part-of: odoo/odoo#108605
Before this commit, the `getRawValue` function was just used in the
kanban_record file and not exported and so it is impossible to use it
in another JS file. This function could be useful if the rawValue is
needed for just a subset of activeFields or just for one field and so
it is a bit overkill to use getFormattedRecord util for that.
This commit exports `getRawValue` function to be able to use it in
another JS file.
task-2702636
Part-of: odoo/odoo#108605
Before this commit, the `bool_or` and `bool_and` aggregations are not
managed in the mockServer.
This commit allows to use the `bool_or` and `bool_and` aggregators for
boolean fields in the read_group mock rpc.
task-2702636
Part-of: odoo/odoo#108605
William Henrotin