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
Purpose is to have some low level tests for composer itself allowing to
ensure its behavior. We add tests notably about default values computation
in mass mailing mode as well as template_id change and values synchronization
in composer model.
In a near future composer will probably be improved (use computed fields,
rewrite part of its logic to improve performances). Having tests done before
those tasks ensure we notice every change that might happen.
Task ID-2390314
PR odoo/odoo#62061
X-original-commit: def98d2375a8a906092293f0aa1ce03bf948d2d3
During a return the purchase_order_line field is propagate, order_line.move_ids include returned move, that why use returned_move_ids is not mandatory.
closesodoo/odoo#35878
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
For this case, if the invoice currency is different from the invoice company currency, the tax calculation is considered the value in a different currency, and the subtotal is the sum of the amount untaxed + the taxes (wrongly in company currency) result in an incorrect value. This is verified when printing the invoice report
closesodoo/odoo#62388
X-original-commit: 91f152f479923a1d28dadcb3ded7c0296cc585fc
Signed-off-by: Josse Colpaert <jco@openerp.com>
Before this commit the navigation toolbar was accessible after selecting
a theme before the editor was opened, which on slow connections made it
possible for users to leave the screen and miss the tour
After this commit the loader animation of the theme installation is
blocking the access to the screen until the editor is opened thus
preventing user to navigate elsewhere before seeing the tour
task-2387608
closesodoo/odoo#62029
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
This commit makes it so the quantity of a SN in a location is now
restricted between -1 < quantity < 1 (previously it was only quantity <
1). This change provides stronger protection against a duplicated SN
(e.g. a quantity of -2 means that the SN was somehow moved from that
location twice). This restriction was also relaxed to not include
location.usage='inventory' because this could prevent the user from
fixing a duplicated SN (since they were prevented from creating a
quantity of 2+ in an Inventory Loss location).
closesodoo/odoo#59834
Task: 2336455
Related: odoo/upgrade#1839
Related: odoo/enterprise#14667
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Add a new feature to automatically create/update/delete an inventory by
company for products with conflicting serial numbers. The goal
of this is to help track inventory discrepencies and prevent duplicate
serial numbers across different locations.
This follows the same logic as the negative qty count auto-inventory
feature where a dupe SN inventory will be auto-generated / auto-updated
/ auto-deleted when the "Inventory Adjustment" button is pushed and when
the scheduler is run. Note that -1 quantity of an already in use SN
counts as a duplication of a SN.
Note: a new many2many field `lot_ids` was added to inventory to more
easily track which conflicting SNs to do the inventory on.
Task: 2336455
ENT PR: odoo/enterprise#14667
Upgrade PR: odoo/upgrade#1839
Add a new feature to automatically create/update an inventory per
warehouse specific to products with negative qty in any of its
locations. The goal of this is to help track inventory discrepencies
and prevent appearance of being out of stock when there is still stock
left. This is done by having the inventories update/create whenever
the "Inventory Adjustments" menuitem is clicked. Since we don't know
when a product's stock becomes non-negative, we always re-write all the
neg products to existing draft neg inventories and remove any
pre-existing draft inventories that haven't been updated since they no
longer have any neg qty products anymore.
Scheduler will also trigger this recalculation in hopes that it will
reduce having a large number of inventories to create when the inventory
menuitem isn't opened very often.
Note: a flag `is_conflict_inventory` was added to avoid conflicts with
manually generated inventories.
Task: 2336455
ENT PR: odoo/enterprise#14667
Upgrade PR: odoo/upgrade#1839
Add a new feature to allow automated (as part of scheduler) generation
of inventory adjustments based on user set value for how often they should
be done for 'internal' and 'transit' locations.
- When is the inventory created?
When cyclic frequency is set to a non-zero value, the next date an
inventory should be automatically generated for a location is based on
whether or not a previous inventory for that location was completed.
If an inventory is overdue based on the previous inventory date, one
will be scheduled for tomorrow. If no previous inventory date exists,
schedule the next one based on today's date. A new inventory will be
created by the scheduler if there is not an existing in progress
inventory for the location (to avoid a conflict).
- What about descendant locations?
Descendent locations will not have an inventory created if their
ancestor is supposed to have a cyclic inventory done at the same time.
Note this includes when that ancestory already has an in progress
inventory and isn't having a new one created.
- What about cleaning out of date cyclic inventories?
This automation will also delete existing draft inventories that include
this location (created before the day the scheduler is run) or any of
its descendants (i.e. inventories with only that descendant location
selected to avoid deleting obviously manually created inventories).
Task: 2336455
Upgrade PR: odoo/upgrade#1839
Victor Feyens