In `_check_backorder`, changes the condition so it checks if the qty
done is enough compared to the actual reserved quantity (instead of the
demand).
Also, removes an unused bloack of code and makes minor visual changes.
task-3076044
Part-of: odoo/odoo#109511
In the inventory menu, the "Operations" menu has now three sub items:
- Transfers
- Adjustments
- Procurement
All the existing `menuitem` go now under one of these sections.
Also, for the old transfers menu itme, this commit replaces it by three
other menu items: "Receipts", "Deliveries" and "Internal Transfers".
Each of them will display only the transfers with the matching picking's
type (depending of the picking type's code).
When a picking is created from there, its picking type will be set by
default according to it and the field will be filtered by its code.
When `mrp` is installed, adds a menu item for the manufacturing
operations in "Transfers" submenu too.
task-3076044
Part-of: odoo/odoo#109511
- The `picking_type_id` field in the pickings form view is not openable;
- Display the `description` field (optional) in the SVL list view;
- Add the `expiration_date` field (optional) in the quant list views;
- Add a description text for the landed cost;
- Renames field `requisition_id`: "Purchase Agreement" > "Blanket Order"
- In Inventory Adjustment, hides the "Apply All" button is at least one
record is selected;
- In `product_expiry`, renames two views to stick to the XML's coding
guidelines: https://www.odoo.com/documentation/16.0/contributing/development/coding_guidelines.html#xml-ids-and-naming
- For the replenishment:
- Places the field `product_id` as the first option when the user
writes something in the searchbar;
- Renames `route_id`: "Preferred Route" > "Route";
- Renames the button "Automate Orders" into "Automate";
- Set the `route_id` field as "optional=hide" until `mrp_purchase` is
installed (in this case, it will be set as "optional=show") because
in this case, there is at least two routes (Buy and Manufacturing).
task-3076044
Part-of: odoo/odoo#109511
- Places the buttons added in `stock` before the "Print Labels" button,
that way, the "Update Quantity" button is always the first button;
- Adds some depends on compute's methods, so that way it displays the
"On Hand" and the "Forecasted" stat buttons, and the weight and volume
UOM even if the product is new and the record wasn't saved yet;
- Adds the "Update Quantity" button in the product's forecasted report
and removes useless attributes of the "Replenishment" button;
task-3076044
Part-of: odoo/odoo#109511
Taxes field is not defined in the pos.order model, so, if you call
the onchange you get the next error:
```
File "/home/odoo/instance/odoo/addons/point_of_sale/models/pos_order.py", line 1159, in _onchange_amount_line_all
line.update(res)
File "/home/odoo/instance/odoo/odoo/models.py", line 5520, in update
self[name] = value
File "/home/odoo/instance/odoo/odoo/models.py", line 5860, in __setitem__
return self._fields[key].__set__(self, value)
KeyError: 'taxes'
```
closesodoo/odoo#112524
X-original-commit: af35c97866fdb271881b7d2b007a3d79f41a910a
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
The function `_sync_dynamic_line`, which is called everytime we edit a
`account.move` or a `account.move.line` is tracking the values before
and after something changed.
Some part of that process was computed in `O(n^2)` where `n` is the
number of `account.move.line` related to the records; this commit is
making it `O(n)`, like the function is supposed to be.
Even though, these are light operations (no database queries, all in
memory), they obviously start to matter at a certain point.
The time to populate `account.move` (using the `populate` command) goes
from 224ms to 170ms per record (1000 moves with ~10 lines per move)
closesodoo/odoo#112522
X-original-commit: 99d2b818238b848125ec6696185ff1fca53d24cf
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Before this commit: In some cases where some events won't sync to
Odoo properly you got the "Unable to use a closed cursor." error. The
problem is that `_from_google_ids` function returns a recordset, and the
underlying cursor may be closed.
Steps to reproduce the issue:
1. Create user_A and user_B in Odoo
2. Sync user_A and user_B with Google calendar
3. Create an event with user_B on the Google calendar
4. Run the "Google Calendar: synchronization" cron
5. Change the created event's owner to user_A on the Google calendar
6. Run the "Google Calendar: synchronization" cron
=> You will get this error on the log, and the event won't sync:
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/odoo/api.py", line 886, in get
return field_cache[record._ids[0]]
KeyError: 99
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/odoo/src/odoo/odoo/fields.py", line 1061, in __get__
value = env.cache.get(record, self)
File "/home/odoo/src/odoo/odoo/api.py", line 889, in get
raise CacheMiss(record, field)
odoo.exceptions.CacheMiss: 'calendar.event(99,).google_id'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/odoo/src/odoo/addons/google_calendar/models/res_users.py", line 91, in _sync_all_google_calendar
user.with_user(user).sudo()._sync_google_calendar(google)
File "/home/odoo/src/odoo/addons/google_calendar/models/res_users.py", line 70, in _sync_google_calendar
synced_events = self.env['calendar.event']._sync_google2odoo(events - recurrences, default_reminders=default_reminders)
File "/home/odoo/src/odoo/addons/google_calendar/models/google_sync.py", line 147, in _sync_google2odoo
existing = google_events.exists(self.env)
File "/home/odoo/src/odoo/addons/google_calendar/utils/google_event.py", line 180, in exists
events.odoo_ids(env)
File "/home/odoo/src/odoo/addons/google_calendar/utils/google_event.py", line 88, in odoo_ids
found = self._load_odoo_ids_from_db(env, model)
File "/home/odoo/src/odoo/addons/google_calendar/utils/google_event.py", line 111, in _load_odoo_ids_from_db
mapping = {e.google_id: e.id for e in odoo_events} # {google_id: odoo_id}
File "/home/odoo/src/odoo/addons/google_calendar/utils/google_event.py", line 111, in <dictcomp>
mapping = {e.google_id: e.id for e in odoo_events} # {google_id: odoo_id}
File "/home/odoo/src/odoo/odoo/fields.py", line 1087, in __get__
recs._fetch_field(self)
File "/home/odoo/src/odoo/odoo/models.py", line 3276, in _fetch_field
self._read(fnames)
File "/home/odoo/src/odoo/addons/calendar/models/calendar_event.py", line 436, in _read
super()._read(fields)
File "/home/odoo/src/odoo/odoo/models.py", line 3343, in _read
cr.execute(query_str, params + [sub_ids])
File "<decorator-gen-20>", line 2, in execute
File "/home/odoo/src/odoo/odoo/sql_db.py", line 89, in check
raise psycopg2.OperationalError('Unable to use a closed cursor.')
```
The solution is to use ormcache on a function that returns the ids of the
events.
opw-3098799
closesodoo/odoo#112517
X-original-commit: 831e2e916541a95a1b932d9f58b3592ecee0c685
Signed-off-by: Arnaud Joset <arj@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
Bug
===
When an error occurs, the error received is wrongly stringified.
closesodoo/odoo#112504
X-original-commit: b0641c5e85bf9d2e2c64ba548f7243e0a4196602
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
Bug
===
When we remove some mail messages, we invalidate the cache of the
related documents. But in the same loop we call _invalidate_documents
which invalidate the cache, and so at the next iteration we will need
to make a new SQL query to know if the message is a "thread message".
So because of the prefetch ids, and because we invalidate in the loop,
if we unlink 1000 message, we will make 1000 SQL queries to fetch the
fields values of the 1000 messages.
Note that the unlink method will invalidate the entire cache anyway,
so unlike the write / create methods, we shouldn't need to invalidate
manually the related documents.
Task-3171093
closesodoo/odoo#112494
X-original-commit: f8958e9bbd4c7c37f614b20f7ed4d4825d438362
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
The `member_values` argument of `action_add_member` is no
longer used in any call of `action_add_member`. We can therefore
remove it in standard, as it's completely unused.
Besides, after grepping the code for all calls to `action_add_member`
to check `member_values` was indeed unused, I saw this method
wasn't used by any views or Javascript code, but only
through Python routes, and therefore it can be converted
to a private method by prefixing it with `_`,
as our guidelines states to make private methods which are not used
by the web client.
closesodoo/odoo#111908
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Currently, it is possible to assign the same "Cash" payment method to multiple PoS.
At the moment, when creating a new PoS, Odoo tends to assign it by default. Although this is highly not recommended as it can only lead to incorrect cash control (two PoS devices rarely share the same till and therefore needs their own cash payment method).
This commit makes sure payment methods of type Cash aren't set by default when creating new PoS.
it also blocks the user from setting the same Cash payment method to multiple PoS configs.
closesodoo/odoo#92664
Task-id: 2857417
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
The previous code had a lot of repetition and made use of deprecated
features such as useListener. This commit refactors the resize logic by
creating a simple ResizeHandle component that encapsulates the drag
handle logic, it then communicates delta in x and y to the EditableTable
which applies it to the correct side and adds constraints on the
coordinates.
It also slightly improves the UX for round tables by also giving them
"corner" drag handles, which let you resize two dimensions at once
instead of just one, this also makes the code more uniform between the
table types, the only difference being where we position the drag
handles so that they're visible.
closesodoo/odoo#112430
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Steps to reproduce the bug:
- Enable “Storage location” option
- Create a storable product “P1”
- Create a putaway rule:
- When in: WH/Stock
- Store to: WH/Stock/shelf1
- product: P1
- Go to operation types -> “Receipts orders”
- Enable “Show Detailed operations” and
“Pre-fill detailed operations”
- Create a purchase order:
- Add 2unit of “P1”
- Confirm the PO
- Go to the receipt:
- the destination location is correctly set “WH/stock/shelf1”
- set the qty done to 1
- validate the delivery and create a back order
Problem:
The destination location is “WH/Stock” instead of “WH/stock/shelf1”
because the ```_apply_putaway_strategy``` function is not called on
the ```stock.move.line``` when there is no package
opw-3162934
closesodoo/odoo#112400
X-original-commit: b4c83ab2b202702e096c775ae73f4646ba93eae4
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
The filter can be assigned in the history directly with its
"id". No need to copy the object
closesodoo/odoo#112309
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
Remove custom open introduced by bpo-26789 as we do not need it.
closesodoo/odoo#112453
X-original-commit: 8eaac9744b93e7132827edb2a59c28bb43732ec1
Related: odoo/enterprise#36978
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Co-authored-by: Martin Trigaux <mat@odoo.com>
__Description of the issue:__
When something goes wrong while downloading a report file, a 500 error
is sent as JSON. However the frontend interprets this response as HTML
and then try to parse the text content as JSON.
Most of the time this works, but if the response contains any HTML tags,
like `<lambda>` from a Python stacktrace, the JSON response will get
misinterpreted as HTML instead of regular text, causing the subsequent
JSON interpretation to fail.
The end result for the user is that empty tracebacks will be displayed
instead of User Errors or actual tracebacks.
__Desired behavior:__
The JSON response is HTML escaped before being sent and will therefore
be correctly parsed and displayed to the user.
This basically restore what was done prior of #104594.
Enterprise: odoo/enterprise#36523
X-original-commit: 5999a7d336553053c5638f69344cdfbc84a8c681
Part-of: odoo/odoo#112453
To reproduce
============
- create a vendor Bill
- add the PDF (from ticket attached files) in chatter
- go back to list view and select the bill -> print Original Bills
a traceback is raised
Problem
=======
for some excptional PDF files (like the one attached in the ticket),
the library PyPDF2 that we use to manage PDF files crashes.
Solution
========
a [fix](https://github.com/odoo/odoo/commit/e55196375aa124558b87ebd50012d5664295ca07) was backported from 16 and updated
so that we don't block the flow, we let a message on chatter that there was an error and we ignore adding the banner.
opw-3141143
closesodoo/odoo#112467
X-original-commit: d73a6261b9c7de41a1de6a2cd888c131ecee023b
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: abla001 <abla@odoo.com>
Since website was moved from frontend to backend in 16.0 with [1], there
was an issue with the page list view which would not show the homepage
record when multi website group was not enabled.
Indeed, we have our own `recordFilter` method which is based on the
`website_id` field.
But the framework ignore this field (it doesn't read the property at all
and so don't have access to its value) if it's hidden by a `groups`
property. In such cases, the field should be duplicated and hidden with
`invisible`, as those fields will have their value retrieved depsite
being hidden.
Step to reproduce:
- Install website with no demo data (to have only one website)
Or go to runbot / install website with demo data and disable the multi
website group
- Go to Website > Site > Pages
- You don't see the homepage in the list, because there is 2 homepage
(one specific and one generic) but since the website_id is not fetch,
both are considered generic (which is not supposed to be possible)
and the filter is then considering those to be shadowed by the other,
ultimately filtering out both.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3bclosesodoo/odoo#112461
X-original-commit: 5ff5daee518d23c3b6958133eb1f99bc5fc1063f
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
An exchange journal entry must not be reset to draft manually. It's done by odoo itself automatically when breaking an existing reconciliation.
closesodoo/odoo#112472
X-original-commit: ad9d53c8976ed78f3f6fdd65795c582d533de436
Related: odoo/enterprise#36999
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Benchmark:
A batch of 1000 payments and a move of 1000 lines to reconcile each payment separately.
Current observed time: +-288s
Improvement:
Adds some context keys when creating the account.full.reconcile to avoid the recomputation of dynamic lines (invoices), synchronization of payments/statement lines and check if the move is well balanced.
=> +-288s => +-34s
X-original-commit: 17c039788365065830dd9d7d2559fcb11f77606c
Part-of: odoo/odoo#112472
This commit fixes the case where portal_customer is not added in the
recipients group by the portal mixin.
Steps to reproduce:
- Go on a purchase
- Log a note and tag a user who handles notification by email
- Traceback:
```
File "/home/odoo/src/odoo/addons/purchase/models/purchase.py",
line 346, in _notify_get_recipients_groups
customer_portal_group = next(group for group in groups if group[0] == 'portal_customer')
StopIteration
```
Current Behavior:
- Traceback StopIteration
Expected Behavior:
- Log a note with the tagged (boomer) user.
See odoo/odoo@f879cf2867closesodoo/odoo#112465
X-original-commit: 7b9dd53a5573141275d41436189c782bccb96c3d
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, if hr_expense module was installed it was
impossible to configure alias_domain in the settings, the change
wasn't taken into account. This was due to the presence of the
field at two separate place and one of them having the readonly
parameter set.
This commit fix this issue that was introduced by :
5eca7b7378
Task-3127163
closesodoo/odoo#112443
X-original-commit: fc1c20cb5ce471b65120ec3eff7abd18ffd3a9fb
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, late close events were not handled properly. This
could have led to non-reconnecting websockets. The problematic scheme
is the following:
- Close the socket (eg. upon the reception of an `offline` event), let's assume that
the other end will not perform the closing handshake, the connection will be
closed once the browser presumes it is dead.
- Create a new socket (eg. upon the reception of an `online` event)
- The browser assumes the connection is dead and dispatches a `close` event,
the worker switches to the `reconnecting` state and expects an `open` event to
update its state to connected. Since there is already a running socket, the worker
won't open a new one and will never receive the `open` event.
- Server closes the connection (eg. `KEEP_ALIVE_TIMEOUT`)
- The close handler is called but since it is in the `reconnecting` state, it assumes
it shouldn't do anything thus, no reconnect attempt is made.
This PR fixed this issue by ignoring events linked to outdated sockets.
closesodoo/odoo#112456
X-original-commit: a2454739156d8742f7606f090126f32735fb15df
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
The goal of this commit is to convert the last legacy client actions from
/hr_attendance to owl.
Client actions:
hr_attendance_greeting_message
hr_attendance_kiosk_confirm
hr_attendance_kiosk_mode
hr_attendance_my_attendances
closesodoo/odoo#110095
Taskid: 3138068
Related: odoo/enterprise#35884
Related: odoo/upgrade#4296
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Tansifex is deprecating it's client and switches to a go-based
solution in its API v3
The new client is still backward compatible with the old format but
the v2 API is going to be phased out.
See https://github.com/transifex/cli to install the deplyments using
the tx client
This PR is the result of the "tx migrate" command
closesodoo/odoo#112402
Transifex: adapt to new URL format
X-original-commit: 7ca55aec4f1faa8bc2ad80d730a7f0771df3998e
Related: odoo/documentation#3534
Related: odoo/enterprise#36950
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
1/ The mexican DIOT report is now a tax report.
This in order to enjoy more Reportalypse' features (less menuitems,
tax_tags engine). The export functinality will remain in enterprise
version.
2/ Add missing tax "RET IVA RESICO 1.25%" tax.
3/ Add migration script for taxes.
As a new tax (RET 1.25%) has been added and the DIOT refactoring updated
many invoice_repartition_line_ids and refund_repartition_line_ids with
tags, the migration script will be run on module update.
task-id: 2925736
[community](https://github.com/odoo/odoo/pull/109300)
[enterprise](https://github.com/odoo/enterprise/pull/35515)
closesodoo/odoo#109300
Related: odoo/upgrade#4224
Related: odoo/enterprise#35515
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
after #111448, the structure of text field is changed. The Translate Button css
hack for ir.ui.view's form view doesn't work.
1. enable the multiple languages
2. go to the form view of a ir.ui.view record
3. the EN button for the view disappears
This commit fixes the bug by adapting the css to the new structure
closesodoo/odoo#112420
X-original-commit: 4dc94998f295b32567472d87bcf7e44af621e4c2
Signed-off-by: Luca Vitali <luvi@odoo.com>
Signed-off-by: Wang Chong (cwg) <cwg@odoo.com>
Steps to reproduce:
- Create a parent analytic plan with no analytic account
- Create a subplan for this analytic plan with no analytic account.
- Create a subplan for the above subplan and create an analytic account for this subplan.
- create an invoice and try to put the created analytic account
Issue:
The analytic account is not availble (nor the subplan, nor the root
plan are displayed)
Cause:
We only fetch root plans (plans without parent_id) that have an
analytic account set. In this cas, the root plan is not retrieved
since the account_id is defined on the sub-sub-sub plan and not on the subplan nor the direct child of the root plan.
Solution:
Fetch all plans that have account_ids set and append the root plan to the relevant plans
opw-3107652
closesodoo/odoo#112419
X-original-commit: d725c74336feb27bd02e0f05491b24cb51627374
Signed-off-by: William André (wan) <wan@odoo.com>
This commit changes the event snippet tag option which was
misconfigured. Using the option fakem2m is indeed the way
to go to filter the events based on the given tags.
This commit also changes the way the domain works with tags:
tags from the same category will apply an OR condition
between them and tags from a different category will apply
an AND condition.
Task-3105126
closesodoo/odoo#109538
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
In werkzeug 2.2.2, the following characters "$!'()*+,;" are now
considered as safe by url_quote. This makes the filename_secure test
fail with the hard coded expected string containing a single quote as
'%27'.
This commit adapt the filename_secure test in order to work with all
versions of werkzeug.
closesodoo/odoo#112298
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
The path matching logic got reimplemented in werkzeug 2.2[^1] and the
new router is no more compatible with regexp groups[^2]. Our custom
converter for slugged-records in urls (`'/partner/agrolait-5'` => `5`)
has been adapted to match the route using non-capturing groups. It still
extracts the slug/id pair using the groups-capturing regexp.
[^1]: https://github.com/pallets/werkzeug/pull/2433
[^2]: https://github.com/pallets/werkzeug/pull/2519
Part-of: odoo/odoo#112298
Since Werkzeug 2.1.0, the Response.autocorrect_location_header is
disabled by default.
As it's RFC compliant and supported by browsers, the base_url is simply
removed from the assertions.
Part-of: odoo/odoo#112298
Archiving an allocation creates bad behaviour
in the use of the time off application.
For example, an employee who has several allocations some of which are archived
in the same period will create a problem in the counting of remaining days off.
Steps to reproduce:
- for an employee;
- create a 5 days type A allocation with a validity from 01/01/2023 to 31/01/2023;
- create a 5 days type A allocation with validity from 01/01/2023;
- archive the first allowance;
- set time off for this employee in this period.
Issue:
The employee's days off are not deducted until he has taken at least 5 days off.
Cause:
The process of deciding which allocation to use first will depend
on whether it has an end date or not.
It will therefore use the allocation with an end date first
(in our case the archived one).
Solution:
Archived allocations cannot be ignored by removing them
from the calculation process, as they have a use.
The solution that respects the business flow is to prevent archiving
for allocations that are not in a draft or refuse state.
opw-2991368
closesodoo/odoo#112401
X-original-commit: 199bd4acebfc905595ddf0525b4f69e38c336853
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
Following up on the gst increment from 1 January 2023, some more changes:
- Change the default taxes on to Sales Tax 8% SR for sales and Purchase Tax 8% TX8 for Purchase
- Changing tax grid for Purchase Tax 8% TXCA
2963811
closesodoo/odoo#110611
X-original-commit: e6bab21dcf2e467fe8a79d1ef82e2cab87d4790c
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
After this commit, the user will be able to clone a question
inside a survey, the cloned question will have the same sequence
as the original and thus will be displayed just below it.
This commit also remove the is_conditional icon on the overall
questions tree view and the misplaced warning which was
previously introduced in commit [1].
[1] : b1d1856245
Task-3088848
closesodoo/odoo#112385
X-original-commit: bdcc2e6c4bec23c200a3fa2a2b4dd1bb06943f39
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
If the business is incorporated, both these fields must be present.
We don't have a field to know whether the business is incorporated,
but in any case the fields must be both present or not present.
opw-3127832
closesodoo/odoo#112366
X-original-commit: b3de98d4dd248f56461f735a6cae143296a96a0a
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
Clicking on the kanban state / attachments / avatar on the kanban card
of a hired applicant would just open the record instead of doing the
intended action as the click was intercepted by the ribbon.
closesodoo/odoo#112349
X-original-commit: 6af260c9a14e639aa9e082dbc117899fe5833c96
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Adds basic support to filter possible m2x values based on another
record. This is necessary for the website_appointment snippet
introduced within this bundle (see related ENT PR).
An important need implemented here is to not store a list of valid IDs
in the DOM but fetch them based on data stored by a different widget.
Use case covered:
Model A has a Many2Many relationship with Model B via a `model_b_ids`
field.
A first widget (Wa) on a snippet's options allows to select a record of
Model A. A second widget (Wb) allows to select records of Model B.
```xml
<!--Widget A-->
<we-many2many data-model="model.a" data-m2o-field="name"
data-fakem2m="true".../>
<!--Widget B-->
<we-many2many data-model="model.a" data-m2o-field="model_b_ids"
data-filter-in="true" .../>
```
Before this commit, the second widget would only be able to show
all records of Model B linked to any Model A record and matching a
static domain provided as attribute, which is still supported.
This commit allows, after having selected `record_a` in the first
widget, to only populate the second widget with the records of
Model B that are in `record_a.model_b_ids`.
Implementing this is done by
* Adding `data-filter-in` to Wb's xml attributes (as above)
* Calling `Wb.setFilterInDomainIds()` when another record is selected
in Wa.
Task-2574175
odoo/odoo#90748
See odoo/enterprise#23750
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When having long questions or sections to display, prevent the questions table from overflowing
the form box.
Fixed globally with a css rule on the x2many list fields.
Task-3151054
closesodoo/odoo#112372
Forward-port-of: odoo/odoo#112168
Related: odoo/enterprise#36926
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Remove an unnecessary css rule, it was made
global for all x2many list fields.
Task-3151054
X-original-commit: 81cf885a9d102c86782f6742bbc98bccb1ee8344
Part-of: odoo/odoo#112372
Purpose
=======
Prevent the x2many list tables in notebook
pages to overflow when having long chars in
the cells or sections.
Specifications
==============
Because of the display inline-block css rule
applied to the x2many field widgets, the table
of the x2many list (in the notebook pages) are
overflowing from the box when having long char
in the cells or sections.
Setting width 100% to the x2many field fixes
the overflow behavior. Long chars are hidden
with ellipsis or wrapped and displayed to a
new line depending on the display.
Task-3151054
X-original-commit: 2cd0106e63785dd34553c2b4747d72b93b9a7afd
Part-of: odoo/odoo#112372
Before this commit, the bottom row of control panel in
list view could change height when reducing window size
and give an ugly layout.
This commit gives more flex to this row to keep a correct
layout when reducing window size.
task 3095775
closesodoo/odoo#110277
Related: odoo/enterprise#36895
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
currently on confirming a blanket order will generate a reference for the record using the sequence and once the record is moved to cancel state and clicking the reset to draft button is clearing the already assigned reference number.
and on clicking confirm again will generate a new reference number for the same record.
this pr will stop clearing the sequence number on reset to draft button.
closesodoo/odoo#108574
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
It's rarely possible to have a statement that its `balance_start` is
empty. So it's safe to use 0.0 when it's None.
opw-3162432
closesodoo/odoo#112374
X-original-commit: 957517c45822771ee2a6e6b6b921b1e53381fb1b
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
svs-odoo