Current behavior:
When you create a contact and a delivery adress for this contact. If you
add the delivery adress as a vendor to a product, and purchase this
product from the delivery adress, the contact will be added to the
product vendor list.
Steps to reproduce:
- Create contact C
- Create delivery adress D for C
- Create product P
- Add D as a vendor to P
- Create PO for P from D, and confirm it
- Go to P, and check the vendor list (C is there)
opw-3177309
closesodoo/odoo#117902
X-original-commit: 67031d2b3d7d52297d18a69c76b4f747b17142e3
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
This commit adds a new prop to the Dropdown component: autoOpen.
It is true by default and follows the current behavior of all
current dropdowns (automatically open the dropdown when it is
hovered and a sibling is already opened) when set to true and
disable this feature for the dropdown when set to false.
The commit also applies this new property and set it to false on
all small icon dropdowns that are present by default in the
enterprise navbar to facilitate navigation with these (debug,
messaging and activity)
opw-3259473
closesodoo/odoo#117622
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
This commit removes the manualOnly prop on the Dropdown component
and all its related code because it seems unused.
opw-3259473
Part-of: odoo/odoo#117622
Recent Odoo versions require modern postgres (e.g. use of jsonb), the
`NULLS {FIRST | LAST}` clause was added in 8.3 so should be well
supported.
While Odoo's use of nulls is not always consistent, the NULLS ordering
clauses can be quite useful especially when sorting `DESC`: `NULLS
FIRST` and `NULLS LAST` are literal positions so they put nulls at
that location regardless of sort order whereas the default Postgres
ordering is to consider nulls larger than every other value so they
appear first when sorting DESC, which is often undesirable (putting
nulls first when sorting ASC can also be useful to fill records).
Update `_generate_order_by_inner` to correctly process `NULLS` clauses:
- Use `regex_order` to ensure we parse orderings correctly and
consistently, also update `regex_order` to use named groups to make
the relevant bits clearer (and VERBOSE for readability).
- Given `a_id DESC` and `_fields[a_id].relation._order = 'xxx NULLS
LAST'`, reversing the clause should order by `xxx DESC NULLS FIRST`
to correctly flip the original as `NULLS` clauses are not relative
to the sorting order (they put the `NULL`-valued records at the
specified location regardless). Therefore apply `reverse_direction`
to `NULLS`.
- Manually expand `NULLS` clauses on m2o fields: propagating the
clause through the join would yield unexpected and illogical results
when mixing NULL m2o fields and non-NULL m2o fields with NULL
`_order` fields (as they would get mixed rather than clearly layered
/ separated).
However because SQL booleans are ordered the usual way (`true >
false`) the `NULLS` clause is fundamentally equivalent to sorting on
the field being NULL (if `NULLS LAST`) or not (if `NULLS FIRST`). So
we can prepend the expanded m2o's ordering with such a clause to get
the correct behavior.
Replaces #116464
Supersedes #116664closesodoo/odoo#117439
Signed-off-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Petar Najman <petar.najman@modoolar.com>
Following the refactor done in [1], it is no longer possible to use the
`value` prop. Instead, the field should explicitly use
`props.record.data[props.name]`.
However, while [1] tried to adapt all the existing fields,
`website_publish_button` was forgotten.
This commit adapts website_publish_button.
Steps to reproduce:
- Install website_sale
- Go to the website app
- In the configuration menu select Shipping Methods
- Chose one of the shipping method
- Try to toggle the "Unpublished/Published" button
=> The value does not update properly
[1]: https://github.com/odoo/odoo/commit/688986f888f2fe2371d58b74ded81315ba6bb353
task-3223146
closesodoo/odoo#117833
X-original-commit: ddadbeed4700e537f7758746298fec43de997b21
Signed-off-by: Guillaume-gdi <gdi@odoo.com>
Steps:
- Install Project
- portal view > task
Issue:
- the private task was displayed in the portal view
Cause:
- the domain was not set for the private portal project
Fix:
- displayed task whose project_id is not false
- so private project was not displayed in the portal view
task-3147011
closesodoo/odoo#117783
X-orignal-commit: https://github.com/odoo/odoo/pull/111456/commits/2c00c7d37cf66601e7a25e22d6170973ea78b158
X-original-commit: b4ff1f0cd543fec9ca653fad97a96287e50743d7
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
This commits makes the TagsList component able to display icons as well
as images were previously supported. A test has been added to verify the
presence of the icon set in each tag.
closesodoo/odoo#117751
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
*: project
This commit adds test to this component and removes unused props. Since commit (1),
it is now considered as a core component. Those props have been removed from the
props declaration, to better match the real usage of the component.
Since the className props was not present:
- The o_kanban_tag class given in theory were not set in practice. The rules
corresponding to that class were already adapted to fix the display of tags in the
kanban view. It was possible to get rid of the references to the o_kanban_tag class.
- The o_field_property_tag_readonly class was also missing, and the logic to prevent
the click on tags was duplicated in the onTagClick function. This makes the class
useless. I removed mentions to this classname. Instead, each tag has the pe-none class
using the same condition, but set in the tag declaration.
(1): 129fa3f150
Part-of: odoo/odoo#117751
steps:
project > kanban card > task analysis > list view of report
cause:
trying to open a project from the list view
issue:
looking for __count in read_group
fix:
add no_open to project_id in the list view because we can open a project from
kanban card and configuration
task-3111378
closesodoo/odoo#117773
X-original-commit: aa051ccf9566cb0eb74d6357de7f069165349e48
Related: odoo/enterprise#39360
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
By checking the script checking if all the account supposed to be in the BS are.
The account 1380 of skr03 and the account 9090 of skr04 seems to be miss
configured.
For the first account, we went back to task 31826 when the account was added.
And we think that the account 1380 was indeed misconfigured. For the other,
by comparing with skr03 which has the same account, we can see that the type
of the account is wrong.
Also, the balance sheet works with tags. Some accounts added after the load of
the chart template were missing some tags. By overriding those methods,
we can add tags afterward and be sure that those account are present in the
Balance sheet.
closesodoo/odoo#117881
Task-id: 3041738
X-original-commit: 44e8295b2df5db73efa7a85003332c092fbfca7b
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Maximilien La Barre (malb) <malb@odoo.com>
When generating invoice for PoS orders, if a cash rounding is applied,
a cash rounding line is generated. Thus it is not possible to have
`rounding_applied` and NOT `rounding_line`.
closesodoo/odoo#114122
Signed-off-by: Heinz Robin (rhe) <rhe@odoo.com>
PaymentScreenTotalDueWithOverPayment result to random runbot error because the
test is performing a series of steps that clicks the validate button which will
randomly result to going to the ReceiptScreen which is not the goal of the test.
In this commit, we replace the use of `pay` method with a more granular series
of steps to make sure that the test doesn't click the validate button and will
properly make the succeeding checks on the amounts in the PaymentScreen.
closesodoo/odoo#117844
X-original-commit: d51fa82d1fa9e154b9f9d57a5532e8c5fe48e33d
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
After the migration of Bootstrap to 5.1.3, the `col-*` elements no longer
have a relative positionning. As a result, most elements having an absolute
position and placed relatively to those elements will be incorrectly placed.
In website_event, the badges of the event cards are currently placed on
the upper border of the card because they are now placed relatively to
the whole card instead of the card body container having a `col-*` class.
As a result, the badges isn't where it should be and get cropped by the
container.
Steps to reproduce the issue:
1. Create a new event
2. Set a template
3. Go to the /event page
4. Click on the edit button from the Odoo navbar to edit the page (editor)
5. Go to the "Customize" page
6. Click on the "Templates" toggle button
To fix that issue, we will add a `position-relative` class on the card
body container having the `col-*` class. This ensure that the badge will
be placed as before between the card body and the card image.
task-3251110
closesodoo/odoo#117872
X-original-commit: 08f98194c095c541bf24d8ba55b440b189fd0766
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
Issue:
With the "Extra Step During Checkout" setting,
it is possible to click on the "Configure Form" button
which should redirect us to the form in order to edit it.
However, we will always be redirected to the first website
(even if we have modified it in the settings).
Furthermore, if we don't have a cart in progress,
we will be redirected to the shop.
Solution:
Add a parameter specifying that it is for editing.
In this way, we can modify the form without having to create a cart.
Due to a technical limitation (reloading settings after saving),
we will always be redirected to the first website.
But it is possible to change the website (with the website editor)
and modify the second website if necessary.
opw-3245772
closesodoo/odoo#117870
X-original-commit: a3169ede4f609b56c83da04756d20b1c7a07251f
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
Steps to reproduce:
- Install website_mass_mailing
- Go to the frontend and activate the editor.
- Add a newsletter block, change it to subscription form.
Issue: The name of the newsletter is displaying also the number of
subscribers (e.g. "Newsletter (1)").
Solution: Change the name we are using to display the newsletter name to
use the `name` and not the `display_name`.
opw-3145571
closesodoo/odoo#117846
X-original-commit: 3930df6c06197b70a019caa4d6782453095a7c66
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Current behaviour:
When creating a timesheet, if in the vals passed the AAL doesn't
have a company (possible since it's not required), then the `uom`
of the timesheet is False, which doesn't make sense.
Expected behaviour:
The timesheet `uom` should fallback on the uom of the company
of the project.
Steps to reproduce:
- Install hr_timesheet, Accounting
- Activate the AAL in the settings
- Create a project with an AAL
- Remove the company on the AAL of the project
- In that project create a task and log some timesheet.
- `uom` field should be empty
Reason for the problem:
When setting the `product_uom_id` in the vals when creating/writing
a timesheet, we just take the `project_time_mode_id` on the company
linked to the AAL. The problem is that the company on an AAL is not
a required field, so it can be `False`, leading the setting the val
for `product_uom_id` to `False`.
Fix:
In case the AAL has no company, we get the `uom` from the company
linked to the project.
Affected versions:
- 14.0
- 15.0
- saas-15.2
- 16.0
- saas-16.1
- saas-16.2
- master
opw-3245671
closesodoo/odoo#117834
X-original-commit: 4cce77bd0288eeb3326ba57e91ef11d436f8a0ce
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
This commit fixes the components destructuration for the
AttendeeCalendarYearRenderer extends.
closesodoo/odoo#117845
X-original-commit: 340e9c2416537fc2e46a914e6038e5233dd876b6
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
The analytic distribution json field may contain a deleted analytic account.
This causes 2 issues:
- When retrieving plans - the analytic account ids are used to force additional plans (maybe applied by a model) - causing a record does not exist error
- Opening and closing the popup is required to 'clean' the distribution. this is not ideal as a draft invoice will not display the deleted account, but it is still in the json.
With this fix, the analytic accounts existence is checked, and the distribution json is saved without the deleted account.
closesodoo/odoo#117835
X-original-commit: ce5045d4ba5633790dfce1ef44c10b5770432829
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Before this commit: if there wasn't any mail group, and you add a
"Discussion Group" component to the website it will raise an error. The
problem is that the `'website.prompt` wasn't loaded.
The solution is to add the `website.xml` file path to
`web.assets_backend` in the website manifest.
opw-3184203
closesodoo/odoo#117824
X-original-commit: feed4ba6f0e904911de419a94998e22a2033f9f7
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When only Invoicing app is installed, trying to switch from a CoA with
reconcile model result in the following error:
You are not allowed to delete 'Preset to create journal entries during a invoices and payments matching' (account.reconcile.model) records.
This operation is allowed for the following groups:
- Technical/Show Full Accounting Features
Contact your administrator to request access if necessary.
As we already checked that user doing that operation is an admin., we
do remove the preceding CoA a superuser (like it was done precedingly
in saas~16.1).
To reproduce:
- Install a database without demo data and choose "Germany" as country
- Install "Invoicing" app
* this automatically install SKR 03 chart of account *
- Go to Settings / Invoicing, switch chart template to SKR 04 and Save
* raise the error above *
closesodoo/odoo#117788
X-original-commit: 87af732ba99b0fd79a98aa0c0c09ca1f737f9955
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Xavier Alt (xal) <xal@odoo.com>
The purpose of this commit is to return meaningful responses when
validating steps and leave the caller to decide what to do with them.
We also introduce a public action enabling the validation of a step
from its xmlid and handle the different cases including the missing
step.
Note: these features are currently used in appointment (See Ent PR).
Additionally, returning the newly validated `onboarding_steps` from
`onboarding_step.action_set_just_done` makes more sense than returning
the `onboarding_progress_steps` records.
Tests are updated to make sure of this.
Task-3074112
closesodoo/odoo#114572
Related: odoo/enterprise#37870
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Remove an option used by the phone widget in the res_user view.
task - 3246848
closesodoo/odoo#117805
X-original-commit: a998437ed465f1a2a0aaee3651472ff8c58ba067
Related: odoo/enterprise#39387
Signed-off-by: Kevin Baptiste <kba@odoo.com>
English term changed in source. Dutch and French via Transifex.
task-3193776
closesodoo/odoo#117789
X-original-commit: 8225fcfe0de231788952ec4c9f6d0eabdc387aa5
Related: odoo/enterprise#39372
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
Before this commit, in large database, openning a sale.order can take 3s.
Because in module sale_purchase_stock, _get_purchase_order use a On2many field : stock_move_ids, with inverse field group_id.
Now it takes 200 ms.
closesodoo/odoo#117738
X-original-commit: 5fc448e7f6dcce94fb89b23be29c4d38a525dd97
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
When we use a 12 hour time format (without the `%p`), the time set is
always in the morning regardless of the period used (AM or PM).
Using `preparse` and `postformat` in the locale to change the symbols
used for numbers prevents the user from changing the date in the
datepicker because the date will be unparsable
Steps to reproduce:
1. Install Calendar
2. Go to Settings > Translations > Languages and open 'English (US)'
3. Set the time format to `%I:%M:%S`
4. Open Calendar and create a new meeting in the morning
5. Edit the meeting, set the time period to 'PM' and save
6. The time of the meeting doesn't change
Solution:
Get the time from the event passed when we close the bootstrap
DateTimePicker and convert it to luxon.
The period displayed when we open the datepicker is always 'AM'. This is
a limitation with the bootstrap DateTimePicker that uses the value from
the element[^1] (which is already formatted with the 12 hour format,
without the period info). Hence, the time is always in the morning
Problem:
The value of the element is used to set the date but this value is
already formatted with the 12 hour format (without the period info) so
it's always in the morning
opw-3150033
opw-3233229
[^1]:https://github.com/odoo/odoo/blob/16.0/addons/web/static/lib/tempusdominus/tempusdominus.js#L395closesodoo/odoo#117781
X-original-commit: dc195613ecff17d6aadc6e6ad8ab6da3670eb85a
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
When opening the Time Off App, the JS performs an rpc to call
hr_leave_type.get_days_all_request. Inside this method there are
some __get__ on non-stored computed fields. This triggers
a recomputation of said fields in _compute_leaves. _compute_leaves
uses _get_employees_days_per_allocation.
When there is an hr.leave.type with request_unit = 'hour', you may
get lots of validated allocations by employee. When this is the case,
_get_employees_days_per_allocation gets quite slow, especially the last
part about 'Future available leaves'.
This commit optimizes this part of _get_employees_days_per_allocation.
In this part the allocations are grouped by employees
and Intervals instances are of the form (start, stop, records). This means
that for a given employee_id, all the records of one Intervals will have
the same start and stop values. This allows us to move the call to
_get_work_days_data_batch outside of the
for future_allocation_interval in future_allocation_intervals._items loop.
Because _get_work_days_data_batch is quite expansive, moving it out
grealty speeds up the _get_employees_days_per_allocation method.
Example speedup: in a database with 50 validated allocations for
the same hr.leave.type and employee_id, the timing of
_get_employees_days_per_allocation 7.39s -> 158ms
opw-3123457
closesodoo/odoo#117778
X-original-commit: 5a2efd2e5c3e65502c031f79f85319f3351f66e3
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Steps to reproduce:
- Activate Analytic Account
- Create a Service Product - create project on order
- Create a quotation with the product
- Confirm the quotation
- Go on the project -> analytic account is "order # - partner_name"
- On the quotation - Create Invoice
Issue 1:
- The invoice has "order #" has the analytic account and not the "order # - partner_name"
Issue 2:
- if you create an invoice and wants to select the analytic account
you cannot search it by the partner name, only by the "order #"
Cause:
When confirming the quotation, we create an analytic account. The
default name of the analytic account is the order name:
https://github.com/odoo/odoo/blob/bba5b6a440544151cc610bbc6848adfbadb38bfb/addons/sale/models/sale_order.py#L1416
Why is the analytic account displayed correctly on the project?
Because we use the `get_name` is triggered:
https://github.com/odoo/odoo/blob/bff34e0e8a8b2d211ef90ffea4f43c514e8cad28/addons/analytic/models/analytic_account.py#L115-L123
In the analytic distribution view, we only render the name of the
analytic account as it is defined primarly.
opw-3165655
closesodoo/odoo#117770
X-original-commit: b709a4491074169f6203ba98dec8847036262d6d
Signed-off-by: William André (wan) <wan@odoo.com>
While we run cron `Data Merge: Find Duplicate Records` then it raises a traceback
because `data_merge. model` has no method `_message_compute_subject`
This thread method is called in various steps when trying to post or notify a
message. With this PR we ensure notifying non-thread models is still working
as intended by being defensive when calling this method.
sentry-3947126655
Task-3254379
closesodoo/odoo#117763
Forward-port-of: odoo/odoo#117636
Forward-port-of: odoo/odoo#113460
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When using the composer on a non-thread model a notification is sent instead
of posting a message, as the model does not support the posting process.
However there is currently a crash due to the default subject computation
which is solved in this commit.
Task-3254379
Part-of: odoo/odoo#117763
While we run cron `Data Merge: Find Duplicate Records` an issue raises because
`data_merge.model` has no method `_message_compute_subject`. Indeed it is
possible to notify on non-thread models but that method is a thread-only
method.
In this commit, we only call `_message_compute_subject` when it's available
in model.
sentry-3947126655
Task-3254379
Part-of: odoo/odoo#117763
Current behavior:
In the pos order report the margin is not shown for products with no
cost.
Steps to reproduce:
- Create a product with no cost
- Open a pos session, add the product to the order and validate it
- Go to the pos order report and check the margin for the product
- The margin is not shown
opw-3232131
closesodoo/odoo#117723
X-original-commit: 223400d371615907a7ba7d5616ffeec307892f16
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Steps to reproduce the bug:
- Go to the website edit mode.
- Choose the 'vertical' template header.
- Select 'off-canvas' in the 'mobile menu' option of the navbar.
- Bug: On mobile view, the menu links are not clickable.
This is caused by the addition of the "order-first" class to the navbar
by commit [1], which causes the menu to be placed behind the backdrop in
mobile view when off-canvas is activated. This only happens with
Firefox, and there is likely a difference in how Chrome and Firefox
handle the "order" property based on the positioning of elements.
[1]: https://github.com/odoo/odoo/commit/2a000e33c5a44ddf0a777b43d8266cc413d8e4e2
opw-3009202
closesodoo/odoo#117683
X-original-commit: 7baa2d3e4949cf3c6e1b1130f03cc2b051dbff0f
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this PR, the field tax_ids had no tooltip.
Since v16 we now allow the use of all taxes in the expenses module now. But, there is not much mention that price-excluded taxes will be used as price-included taxes.
In the release notes it just mentions that all taxes are usable, but there is no mention of anything else. This seems a bit confusing. Adding the tooltip will help users.
Also adding fresh exported .pot
closesodoo/odoo#117351
Task-id: 3252757
X-original-commit: df28d24699a6bfb4ea142fc07b10c1835d9d4323
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Signed-off-by: Maximilien La Barre (malb) <malb@odoo.com>
*: account, crm, hr_recruitement, im_livechat, point_of_sale,
project, sale_management, website_sale
Purpose
=======
Now, the KPI are computed based on their `company_id` and not based
on the current company. If no company is set on the digest, we compute
it based on the current company.
The KPIs are computed based on their company. Most of the time, they
will all belong to the same company so we can improve the performance
by computing them in batch.
Task-2827996
See odoo/enterprise/pull/27658
Part-of: odoo/odoo#91945
An error appears when we try to change the product in transfer line via
product/search
steps to reproduce the error :
1- create 2 products : Test 1 (UoM is Cm) and Test 2 (Uom is g)
2- create a delivery order and add Test 1
3- UoM error due to the UoM not being updated at the time of change
The error was happening because when updating the product directly in
the line section , the stock_move item already has a UoM and the if
statement makes it impossible to change it , so the error appears.
opw-3231298
closesodoo/odoo#117504
X-original-commit: ece3dea8c1ab43a854a57513cc317e8618010542
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>
before this commit, in the list view of
fleet (fleet.vehicle),
services (fleet.vehicle.log.services) and
odometer(fleet.vehicle.odometer) the vehicle_id
and model_id field with many2one_avatar is
not showing the image of vehicle and model.
* open fleet -> fleet -> fleet
* switch to list view
* model field will be with empty image
* similarly in services and odometer menus
after this commit, the widget will be removed
from the field as the avatar field doesn't
exists in the model level.
closesodoo/odoo#117752
X-original-commit: e57b6f898775a0e432ae1a21266a0f4bf82c0242
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Incorporate Andy Quijada (ajqn9094) as Vauxoo's contributor.
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#117729
X-original-commit: 53fc292afe73eb67cdbf9dcb0fbb8dcff5caadd9
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Steps to reproduce the bug:
- Create a Storable product “C1” tracked by Lot:
- Update the Qty to 10
- Create a Storable product “P1”:
- Add a BoM:
- add 1 unit of “C1” as component
- Enable 3 steps for the manufacturing operation in warehouse settings
- Create a Mo to produce 1 unit of “P1”:
- Confirm the MO
- Click on related transfer:
- Select the “Pick component”
- check that the qty is reserved correctly
- Try to validate it without setting Qty done
- The immediate transfer is triggered, validate it
Problem:
The backorder's wizard triggers when it shouldn't
To know if we should create a backorder, we check if the qty reserved
is equal to the qty done, and as the qty done was not set correctly
during the validation of the immediate transfer, the two quantities
are not identical, therefore the widget is trigger:
https://github.com/odoo/odoo/blob/15.0/addons/stock/models/stock_picking.py#L1128-L1132
opw-3240264
closesodoo/odoo#117706
X-original-commit: dd44e1f69dfd217fafa9c2ec5da8b211b2ff3513
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Adding the if condition to handle starred argument passed to
cr.execute
Adding two test to test that case
closesodoo/odoo#117688
X-original-commit: 4ab64dcd21ecd99c081975beee5ac13d2aa70a6b
Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>
The loading of products and partners in background is too slow for the moment.
For configurations with a lot of products or partners, the loading is slowing
the whole behaviour of the PoS while it is not really necessary to load
20K products. This commit sets the default behaviour of the PoS to "not load
products and partners in the background", it also adds a button
on the ProductScreen for user to load more products when
a search term is put in the search bar and the same on the PartnerListScreen
for loading partners. This load will load 30 items at a time.
closesodoo/odoo#117667
X-original-commit: 389c85af5983f2f25c7c24f21d3c3716077d7119
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Heinz Robin (rhe) <rhe@odoo.com>
duration_percent field is a stored integer.
In postgresql, integer are 4 Bytes long, which create a range of -2147483648 to +2147483647.
With a small duration_expected, and a big duration, we can easily break these limits.
OPW-3253333
closesodoo/odoo#117744
X-original-commit: 97892d04341a2cbbe07e4db6442a451b0cf0b164
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: David <dafr@odoo.com>
Steps to reproduce the bug:
- Go to the warehouse settings:
- enable “3 steps for manufacturing”
- Create a storable product “P1” with 2 BoM
- Create an orderpoint:
- Preferred route: Manufacturing
- Product: “P1”
- BoM: select the second BoM
- To order: 1
- Click on the “Order once” button
Problem:
The manufacturing order is created with the first BoM instead of the
second.
As we are in 3 steps, the “run_pull” function is triggered first, with
values prepared from the orderpoint so the bom is well set:
https://github.com/odoo/odoo/blob/16.0/addons/stock/models/stock_orderpoint.py#L515-L523
Then the “run_manufacture” function is triggered but with vals prepared
from the move, not from the orderpoint, so we lose the BoM information
that the user has selected:
https://github.com/odoo/odoo/blob/16.0/addons/stock/models/stock_move.py#L1334-L1340
opw-3217945
closesodoo/odoo#117732
X-original-commit: 2371cd29e1c0cfa54b682b2100b9db7f5633a7b4
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
Before this commit, having an accrual plan with no
level before a certain amount of time would result
in a crash because no relevant level is found.
This commit avoid that error.
closesodoo/odoo#117722
X-original-commit: 7cc075604c2fffe3710e3b76a004e730650d62b1
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Current behaviour:
Cannot add a Work Order to a Manufacturing Order
if the analytic account linked to the MO doesn't
have an associated company.
Expected behaviour:
Should be able to add a WO to a MO even
if the linked analytic account doesn't have
an associated company.
Steps to reproduce:
1. Activate analytic accounts
2. Activate work orders
3. Create an analytic account without company associated
4. Create a Manufacturing Order
5. In miscellaneous, link the analytic account
6. Try to add a WO line
7. Error log
Reason for the problem:
When trying to add a WO line, if the MO has been linked
to an analytic account, it checks for the currency in
the company in the analytic account, which was not
existent, since the company didn't exist.
Fix:
When trying to access currency, if the company in the analytic
account doesn't exist, it defaults to the company in the WO.
opw-3210708
closesodoo/odoo#117708
X-original-commit: f0d8f5e82e62e0bcfc05e25dac2504f8f07537f4
Signed-off-by: Demany Antoine (ande) <ande@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
roen-odoo