- Create Product A with UOM of type Unit
- Create Product B with UOM of type Unit
- Create BOM of type Kit on Product A with Product B as a component
with UOM of type Unit
- After saving BOM, change the UOM of Product B with UOM from another
categories (e.g. kg) and save the product
- Try to access product list
A warning appears and prevent showing the products in any way.
It is caused by the call to `_compute_quantities`.
In this case, it is ok to skip the error. Indeed, it will raise later on
when trying to use the kit. But at least, it gives the possibility to
the user to access the product list.
opw-2393711
closesodoo/odoo#62537
X-original-commit: 6de2537ac82d9dad3cb3f56a7b9b35856681a6ad
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
What are the steps to reproduce your issue ?
1. Install "website_sale_comparison"
2. Create a product with only one variant with one attribut
3. Click on "Go to website" smart button
4. Enable "Customize/List View Variant"
5. Click on "Compare" button
What is currently happening ?
Nothing
What are you expecting to happen ?
Add product to the comparison list
Why is this happening ?
Because the product has just one variant and attribut so odoo don't
display it on the product page. The system cannot find the ids as
they are not on the page
How to fix the bug ?
Specify the product id in this case
opw-2377711
https://www.odoo.com/web#id=2377711&action=4043&model=project.task&view_type=form&cids=1&menu_id=4720closesodoo/odoo#62424
X-original-commit: ea1f23ea75c457c615968f3cb632fd7db7d39d6e
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: Achraf <abz-odoo@users.noreply.github.com>
Megamenu snippet should appear in the snippet editor "block" section ONLY if a megamenu element is selected.
In the current version, trying to filter snippets would make the megamenu snippet block appear.
closesodoo/odoo#62414
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The "active" field is a non-working deprecated alias to "auto_install",
it does not work and was confusing users (see #59850). It has been
removed.
closesodoo/odoo#62086
Task: 2361729
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
A manually created decimal precision won't have any impact on the system
unless used in custom code, and in this case, the record should be
specified directly in the custom code datas.
Furthermore, it can still be created/deleted in superuser mode if really
necessary.
closesodoo/odoo#60744
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The names of the decimal precision shouldn't be modified as this field
is used as reference in the code.
Modifying (e.g. translating) the name of a decimal precision will
disable the precision, always using 2 as precision fallback when the
specified precision is not found.
1) forbid deletion of main uoms & categories
2) warn modifications of main uoms data.
Except for the working Hours uom, which isn't a strict UoM
representation and could change between countries (and/or be deleted).
3) Also move the Dozen UoM to demo datas, it's a confusing UoM and isn't
used by the majority of databases.
4) Restrict deletion of used uoms on main models.
On sale orders and account moves the uoms couldn't be deleted thanks to the
SQL constraint covering the display_type logic, but the generic error message
is more clear for a user when deleting an uom.
Before this commit, Filter `Confirmed` was showing all Sales order irrespective of `website_id` while filter `Unpaid` was showing order having `website_id`.
Now, we have are showing all the sales order on `Unpaid` filter as we already have default filter "From Website" applied on action. So Both filters `Confirmed` and `Unpaid` will have no effect of `website_id` field.
closesodoo/odoo#60662
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Without this commit, when the compare/reset view feature was reading the arch,
it would translate it.
3 issues :
- When reading from file (hard reset), it would translate the file version
- When reading current arch, it would translate it
- When reading compare view arch, it would translate it
closesodoo/odoo#62521
X-original-commit: 1aa4d3cb57844c24d8520b6b974bb36526392ecf
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
There is a situation in pos_restaurant such that when an order
is deleted from the ticket screen, it persists to show when the
table is opened. To reproduce:
1. Create an order in T1 then add items to it.
2. Get out of the table (back to floor).
3. Open ticket screen.
4. Delete the order in T1.
5. Close the ticket screen.
6. Open T1, the order is still there (bug).
This commit fixes this behavior such that in step 6, new order should
show and not the deleted order.
Note that we also made a change in the template in order to allow
checking the number of synced orders during testing. We want to make
sure that the table is clicked when the sync finishes to prevent
concurrency issue during testing.
closesodoo/odoo#62488
X-original-commit: e6e2a7392a5dd518c3f0df1c1ac0f90b0cba78f4
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Signed-off-by: Joseph Caburnay (jcb) <caburj@users.noreply.github.com>
Behavior prior to this commit:
- when the warehouse uses a 3-step manufacturing process, if I create a
Sales Order, the MO generated does not show the SO# as "Source", instead
it shows the MO#
Behavior after this commit:
- the MO source shows the SO# (similar to how it works when using the
2-step or the 1-step manufacturing process)
- the origins are assigned thus:
- Delivery Picking = SO name
- Post-prod Picking = SO name
- MO = SO name
- Pre-prod Picking = MO name
Note:
- there is no implementation change in this commit - we just ported the
test from the original commit in 13.0 (the behavior in 14.0 was already
OK)
opw-2380717
closesodoo/odoo#62512
X-original-commit: 0281dee6da75e68403772ebd368d57c1feb98c37
Signed-off-by: Nicolas Galler <ngaller@users.noreply.github.com>
Consider the following situation:
- have a form view with an x2many field displayed as a list
- the x2many field has a form view that contains an x2many field,
which isn't in the list
- for that x2many field, we can also open a form view to see/edit
the related records.
As the x2many field isn't in the list, when we open a subrecord, we
modify the fieldsInfo to add the information about the x2many field
we didn't know before. Doing so automatically applies raw changes
that we might have stored earlier (from onchanges) for that field,
because we couldn't apply them before knowing the type of that
field.
Before this commit, the function that applies the raw changes was
called recursively on the dataPoint and all its children (thus on
the x2many list datapoint), which produced a crash as this function
is designed to work on dataPoints of type record.
Actually, calling it on sub datapoints is useless, as it properly
works recursively, and applies raw changes on x2many fields itself
when necessary.
This commit ensures that we don't call this function on list
datapoints anymore.
Closes#62334
OPW 2389991
closesodoo/odoo#62511
X-original-commit: 2b7670e6d709cd311c630c99cb9da7d3d6ae90f4
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Only updates outdated requirements which actively cause issues:
* freezegun broken in 3.8 (removal of time.clock)
* xlrd broken in 3.8 (removal of time.clock)
* also monkeypatches xlrd.xlsx for 3.9 (removal of
Element.getiterator, breaks because of defusedxml)
* jinja triggers DeprecationWarning in 3.8
* pillow triggers warning in 3.9
* lxml, greenlet don't compile in 3.9
* reportlab doesn't work in 3.9
New versions try to match those of Debian Bullseye.
Also adds a script to more easily compare dependency versions between
the requirements files and what's in various distributions (currently
supports checking against debian and ubuntu).
Furthermore updates warnings filtering:
* removes xlrd (mischeck was monkeypatched as noted above)
* removes setuptools (was for older versions, one would hope this
isn't an issue anymore)
* adds babel: python-babel/babel#684 fixes the deprecation warning but
is not part of any release yet
* ignores error related to `random.sample` on a set, this is a
diagnostics bug because recordsets implement both Sequence and Set,
and the stdlib checks for Set first (bpo-42470)
See #59980Closes#61103closesodoo/odoo#62510
X-original-commit: 648635deca67df09417ae55c6eb181c98524b74d
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Steps to reproduce:
Create a new local Odoo DB
Create another company on the DB
install the CRM module
Create an opportunity on the CRM app for each company.
Execute This server action (CHANGE THE res_id TO THE IDs OF THE OPPORTUNITY CREATED):
```
for _ in range(0, 300):
for _ in range (0, 75):
env['ir.attachment'].sudo().create({'name': 'test','res_model': 'crm.lead', 'res_id': 31, 'type': 'binary'})
for _ in range (0, 75):
env['ir.attachment'].sudo().create({'name': 'test','res_model': 'crm.lead', 'res_id': 45, 'type': 'binary'})
```
go to the Settings / Technical / Database Structure / Attachments.
Server will look in endless call because the search try to retrieve
`limit` records, but after applying company record rule we have
`limit - e`, so it begin a second search for e records.
Even the second search will look for limit and possibly will find less,
starting a third...
If the sub call is aware of how much records we actually need after
checking permission, we can return the recordset if we have collected
enough
opw-2369722
closesodoo/odoo#62456
X-original-commit: 6a8f28c4d0f9df7cd8451f4caf4f3bf7d64330da
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Create a sale order for a stored product, save and confirm.
Validate delivery
Return and validate.
Return (the return, so delivery again) and validate.
Try return again.
The quantity to return in the widget will be 0.
Attempting to fix manually will worsen the situation creating negative
quantities on further action.
This occur because when creating the return the system tries to identity
other sibling return moves to set the correct quantity
This commit fine tunes 73de0645b730e1f1183b7c770e878b4c4ff1e0f1 aiming
to collect quantities only on actual sibling returns (moves sharing the
same parent)
opw-2379663
closesodoo/odoo#62169
X-original-commit: fe8c6db1323061f3e6a0fd3f8b294ea6ddb86acf
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Prior to this commit:
* The portal timesheet section was only visible in invoices when
invoicing policy was set to delivery.
* The portal timesheet section was not visible on orders.
After this commit:
* The portal timesheet section will be displayed for both delivery and order invoicing
policies.
* The portal timesheet section will be available for orders.
task-2388500
closesodoo/odoo#62516
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
- Install website_slides
- Connect with an user (i.e. Mitchell Admin)
- Go to Website and open a Course quiz for the first time
(i.e. "Test Yourself" from "Basics of Furniture Creation" Course)
- Answer correctly
The number of won karma is the one from the last attempt reward and is not saved
in user's total xp.
When submitting the quiz, quiz_attempts_count is incremented via a SQL query,
but its value is not updated in cache directly.
When the karma gain is computed from the attempts count, the value used is the
old one in cache.
opw-2389969
closesodoo/odoo#62500
X-original-commit: d8254c130d4b04a0f1ff80990fe28e795bf9ad51
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
The mock implementation of `name_get` does not fully reflect
the real server implementation.
The real implementation is described in tests added in
this commit.
Note: in my wildest dreams, the mock server tests would be run
against the real *and* the mock implementation to ensure they
do not diverge.
closesodoo/odoo#62430
X-original-commit: c8f59bfd5c8ddb7c7abf1108111507e667393208
Related: odoo/enterprise#15017
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Steps:
- Install Contacts
- Have Multi-Companies enabled
- Go to a Contact of type "Company"
- Click "Sales & Purchases"
- Assign it the company you're on
- Save and Edit again
- Remove the assigned company
- Go to a contact of type "Individual" linked to this company
- Click "Sales & Purchases"
Bug:
The company has not been deleted on the linked Individual
Explanation:
When we delete the company of a contact, the value of `vals.get('company_id')` is `False`.
This is why it didn't enter the propagation process.
opw:2391464
closesodoo/odoo#62464
X-original-commit: 80902bee453cf485906bb07be6af9072aee2e76f
Signed-off-by: backspac <backspac@users.noreply.github.com>
This makes the act of replacing the dummy text easier.
@Tecnativa
closesodoo/odoo#62453
X-original-commit: 08b79883d44e44791760cfbba498eb9a3f47f945
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Fiscal positions shouldn't be deleted if used by existing account moves
closesodoo/odoo#62443
X-original-commit: 6b2d0faf170f7b5061f5facbaa3818e529a2de4c
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Before this commit if a product template has no image, no image was
displayed in the website shop for the product
After this commit if a product template has no image, the image of the
first variant is displayed in the website shop
https://github.com/odoo/odoo/issues/52463closesodoo/odoo#62440
X-original-commit: 643c8a9dce9455fe614f73ed97a793856e3608e7
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
What are the steps to reproduce your issue ?
1. Install "google_calendar"
2. Log in with "admin"
3. Create an eventX with "admin" and "demo" has attendees
4. Run "Google Calendar Synchronization" from "Scheduled Actions"
What is currently happening ?
eventX is successfully added to Google but without admin
if you sync Odoo to Google one more time, Google will overwrite eventX
and it will remove admin from attendees
What are you expecting to happen ?
Sync Odoo to Google and Google to Odoo without lost attendees
Why is this happening ?
Because there is a filter that prevent addition of current user to the attendees
How to fix the bug ?
Remove the filter
This reverts commit 287ee0f83ae6fd457e5356860c8a8ab5a4e66754.
opw-2382443
closesodoo/odoo#62416
X-original-commit: f6a610d0b1379aa97ad97fb7494a5d269da87775
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
STEPS:
* Create a BoM with two components purchased the same vendor, but with
different "Delivery Lead Time". First component must have lower value
* Create Manufactoring order, Mark as ToDo
* Open created purchase order
BEFORE: Order Date is equal "MO planned day MINUS delivery lead time for the first component"
AFTER: Order Date is equal "MO planned day MINUS maximum amout delivery lead
time for the components"
---
opw-2388031
closesodoo/odoo#62411
X-original-commit: 8f0cc3609ce7a02d0e3f39586a7b0299ab221d48
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>
When some bills are not paid, some with due date, some without, when registering the payment of these bills as a group payment with checks, it is not possible to print the check
To reproduce the error:
(Need account)
1. Go to Invoicing > Vendors > Bills
2. Create a new one
- Add at least one line
- Add the Payment Terms
3. Save & Post
4. Duplicate it, then Save & Post
5. Go back to Bills
6. Select the two bills
7. Click on Action > Register Payment
8. Select Checks, enable Group Payment
9. Click on Create Payment
10. Click on Print Check
11. Click on Print
=> An Odoo Error is raised
The user should be able to print it.
OPW-2389368
closesodoo/odoo#62391
X-original-commit: 4dc4dc3d20114bea54266d97de29565a1a1ac230
Signed-off-by: adwid <adwid@users.noreply.github.com>
Before this commit the dropzone was relative to div.content. This would create
some bad position where the dropzone was covering the form view but not the
chatter.
task-2389929
closesodoo/odoo#62402
X-original-commit: bb650a9a1f4ff8280bd1e3467624991bc87517b9
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Fields `views`, `closed_reason_id`, `closed_uid` and `closed_date` should not be copied while copying post.
closesodoo/odoo#62401
X-original-commit: d35acd37720e8f498f5eef319c50780eaa7cb72e
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Before this commit the close button cross/multiply character was wrongly
translated in some languages (e.g. Spanish)
After this commit the close button cross/multiply character is not a
translatable text anymore
https://github.com/odoo/odoo/pull/60268
task-2365792
closesodoo/odoo#62400
X-original-commit: 517e272da81e4f5ad958d896a75d4f32b44083e5
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Followup on 911ada2d02b24778435fd9174441a6834da2effa
When modifying the company_id of a pricelist, the check to ensure a website
has a pricelist available wasn't triggered.
This commits ensures the Each website has Valid Pricelist with Correct or
Empty company.
Fixes#50707closesodoo/odoo#62359
X-original-commit: f196430baa8c5e2ce403808adc26d90fe84665fa
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
The 'On Hand' button triggers action_open_quants on product model. It
do not explode the kit into its component
closesodoo/odoo#62390
X-original-commit: 49b965eb1ec6a7ec6c07fa643cc6ae35ee8b5d91
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
It is better to use another naming than re-using class names. Somehow it
seems sometimes we have MRO issues.
Task ID-2390314
PR odoo/odoo#62384
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
As default is called numerous times with sometimes all fields, sometimes
only one field we have to ensure we avoid computing and setting unnecessary
or wrong values. We suspect this comes from default_get being called more
often at creation time since Odoo v14.
Default values for some fields in mail composer are dependent on each other.
Especially composition mode and model / res_id(s) are important for some
fields as behavior is not the same in comment or mass mail mode (subject
set / not set, template values rendered / displayed raw, ...).
Especially subject is wrongly computed in mass mail mode. For example use a
mass mail composer action on leads without template. Indeed a default_get
is called on subject alone. As web client adds active_model / active_id
automatically default returns a value for subject while it should not as
other values (model, res_id) are not asked and therefore not correctly
computed. It makes composer compute values in comment mode while it should
stay in mass mode.
In this commit we fix that behavior by
* computing only requested values (better match returned values and asked
fields);
* avoid computing values if context values are not given (model, res_id or
res_ids, composition_mode);
Task ID-2390314
PR odoo/odoo#62061
X-original-commit: 1c8ca358d75c9fe00631731d5061674c0a3a040b
Some tests are currently dependent on bus state when computing number of
notifications sent. For example install Crm then test_mail_full. Some
tests crash as too much notifications are found in the bus.
We therefore clean remaining bus notifications before running tests to
ensure we check notifications during test itself. This make tests more
easy to reproduce.
Task ID-2390314
PR #62061
X-original-commit: 92ff1379b0492765fd0ba9863a9ce13fba7eeb4a
Nicolas Martinelli