Add an external code field on the hr_work_entry model to have
a custom code when exporting the work entries to another system.
task-2929493
closesodoo/odoo#104326
Related: odoo/upgrade#3998
Related: odoo/enterprise#33337
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Finland is comprised in the EAS list but is not currently supported in
Odoo. This commit makes UBL Bis 3 available for Finnish companies.
opw-3178684
closesodoo/odoo#113509
X-original-commit: 6ade738c2fc63c824adee570886376019459ab73
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Signed-off-by: Julien Van Roy <juvr@odoo.com>
Steps to reproduce:
- Create a new journal Bank
- In Sequence, find the 'New Bank Check" and edit it so the sequence can be 10 number digits long
- Create a Vendor Payments with the the New Banck and Check as a method
- Click on Print a check
- Set any number > 2147483647 and validate
Issue:
Traceback
Cause:
The query SQL make a check to verifiy that the number is correct ('025'::integer == '25'::integer but '025'!='25)
But using INTEGER limits the number up to 2147483647 (https://www.postgresql.org/docs/current/datatype-numeric.html)
Solution:
Use BIGINT whose limit is 9223372036854775807
opw-3140973
closesodoo/odoo#113499
X-original-commit: 49dd9dffd7b96fd90860123f8b3f0e623979b246
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Currently, when editing a report line, it's possible to create
a new expression with a label already used on the same report line.
This is problematic as the columns are using the expression label
to select the right expression. Indeed, one expression is going
to be selected but there isn't any obvious way to guess which one.
The solution is to add an SQL constraint on the report line expression.
task-3199014
closesodoo/odoo#113222
Signed-off-by: John Laterre (jol) <jol@odoo.com>
This commit aims to simplify the extractProps api by removing "field".
The Field will need to go into
this.props.record.fields[this.props.fieldname] to access the information
previously stored in the "field" parameter.
Part of Task: 3179751
closesodoo/odoo#113214
Related: odoo/enterprise#37469
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Allows model to provide default values for auto creation of related res_partner
such as name, title, ... It avoids the user to enter the information twice.
Use the newly introduced mechanism for crm.lead to prepopulate auto created
res_partner:
- when selecting a suggested recipient, by prefilling the simplified form (job
position, phone, ...) along with non modifiable data that will also be used to
populate the res.partner like the address, website, ...
- when selecting a template for a message on a lead without a partner, the
partner is automatically created with values from the lead: email, phone,
address, ...
Task-3024050
closesodoo/odoo#105111
Related: odoo/enterprise#33687
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This fixes the problem of the full res_partner form being displayed instead of
the simplified one in some cases (and vice-versa).
The problem can be reproduced by the following steps:
- launch odoo without xml dev_mode enabled (otherwise the cache is disabled)
- in helpdesk, go to an existing ticket and click on an existing customer (this
will load the full form for the customer into cache)
- create a new ticket by first completing name and customer name, save it
- complete the email address, save it
- go to "Send message" and click on the email checkbox
- the full form is loaded instead of the simplified one
(base.view_partner_simple_form)
It is also possible to get the simple form instead of the full form by
reversing the order of the visited forms.
Technical note: The problem has been fixed by adding the context key
"force_email" as cache key using _get_view_cache_key override. Indeed,
_get_view_cache uses _get_view which result depends on that context variable in
its redefinition in res_partner.
Task-3024050
Part-of: odoo/odoo#105111
When the contact name was not yet set, the email was displayed twice in the
composer: first as the contact name and then as the email in parentheses. Now
when the contact is the same as the email, nothing is displayed in parentheses.
Technical note: the regexp in the mail util parseEmail method has been slightly
modified because it was returning in some cases the name surrounded by quotes
(ex.: "newlead3@ex.com" <newlead3@ex.com> --> name: "newlead3@ex.com"). This is
no longer the case with this change. That change was needed for comparing the
name and the email to avoid to display the same thing twice (when the email and
the name are the same). Note that the method is only used once, where we have
done the change.
Task-3024050
Part-of: odoo/odoo#105111
Selecting a recipient for which there exists no partner trigger a partner form
dialog creation. For some model (ex.: crm.lead), some default values can be
prefilled from the current record. This is what we do here by calling a generic
mechanism that allows each model to define default value for related partner.
Note that we don't provide a more detailed form to the user because some will
otherwise feel obligated to fill it out entirely.
Technical note: As there is no need for a custom form per model from which the
data are extracted to populate the related partner, the simplified partner form
(view_partner_simple_form) is just augmented with additional invisible field by
modules that add fields to partner and need to populate them automatically from
values of another model.
Technical note: In TestCRMLead.test_message_recipient_partner_auto_creation, we
test that the _message_get_suggested_recipients returns the correct default
values to copy some fields from the lead to the partner to avoid the user to
reenter them. But we don't test specifically that it also work when using mail
composer and template (which generate the partner) because it has already been
tested when introducing the mechanism. Although, we verify that it should
behave the same because we verify that the default values returned by
_get_customer_information, that is used in mail template when using the
composer, are the same as the ones returned by _message_get_suggested_recipients
which is tested here.
Task-3024050
Part-of: odoo/odoo#105111
Define information taken from the lead when a partner is automatically
created from it. It avoids the user to enter the information twice and
automated partner creation now correctly takes information when possible.
Task-3024050
Part-of: odoo/odoo#105111
Allow model to provide default values for auto creation of related res_partner
such as name, title, company_id, ...
It is used when claling 'Partner._find_or_create_from_emails()' that now
accepts custom data when creating partners based on a given email_normalized.
This allows notably to flatten a loop due to multi-company when creating
partners from emails in template management. It is now done using this email
based dict allowing to create all partners at once.
Task-3024050
Part-of: odoo/odoo#105111
Allows to rate any record extending mail_thread. This change was needed because
the rating template could be sent on any record (with some minor changes like
removing reference to specific record) and if the record was not extending the
rating mixin, it was crashing when the controllers using rating mixin features
were used.
This commit moves the code from the mixin rating.mixin to mail.thread and
adapts the test for testing rating submission with and without the mixin.
Technical notes
- rating_ids field has been added in mail.thread instead of using a simple
query because it improves performance while getting rating token in mass.
- the rating mixin now inherits from mail.thread to add features on top
of basic rating support in mail.thread.
Task-2674649
closesodoo/odoo#103966
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This task integrate the rating feature in mail.thread which adds one query in
the unlink method (for deleting the related rating) on model that were not
inheriting from rating.mixin.
Task-2674649
Part-of: odoo/odoo#103966
Small correction to make the code more robust.
Technical note: we encountered a case where the group 'portal_customer' (to
classify recipient for mail_thread) where not present although it is added by
portal.mixin inherited by sale.order. That problem has been fixed since. So it
doesn't fix an actual problem but a potential one (condition of the "if" cannot
be false because the generator will generate an exception before).
Task-2674649
Part-of: odoo/odoo#103966
Various: im_livechat, rating, test_mail_full, website_{sale|slides}
Allows to rate any record extending mail_thread. This change was needed because
rating template could be created for any models, even those not inheriting from
rating.mixin. If sent on a record of such model, it was crashing when the
controllers using rating mixin features were used. This is no longer the case.
This commit moves the code from the mixin rating.mixin to mail.thread and
adapts the test for testing rating submission with and without the mixin.
Base behavior accepts rating and provides an access to ratings through the
'rating_ids' field. Rating.mixin inherits now from mail.thread to ease
computation, and adds statistics and some advanced capabilities.
Inheritance of some model have been reordered now that rating is build on
top of mail.thread.
Task-2674649
Part-of: odoo/odoo#103966
In an edge case the content of the field has already been
prefetched as sudo during the read of another field as sudo,
therefore it doesn't try to read the field as the normal user
closesodoo/odoo#88134
Signed-off-by: Julien Castiaux <juc@odoo.com>
To reproduce the issue:
1. Install [Accounting]
2. [Settings]: Toggle on [Batch Payments]
3. Enter [Invoices]
4. Click on several invoices and [REGISTER PAYMENT]
5. Hover over [Group Payments] to see the guide message
Impacted versions: 16.0 up to master
opw-3178431
closesodoo/odoo#113493
X-original-commit: 0866ee676084ae52e6a0b13360a24dacbccd5237
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Lee, Hansun (hale) <hale@odoo.com>
Report line `l10n_kz_tr_line_300_00_017` has two expressions with a duplicate expression label, which shouldn't happen. This commit merges them, with taxes being allocated into the same expression.
closesodoo/odoo#113437
X-original-commit: e758e616929e8050ebbf152207b1f45f74b8919e
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Steps to reproduce the bug:
- On the website application, add an image gallery snippet.
- Change the "Speed" parameter.
- Save.
-> Nothing happens: The displayed image is always the first one and
there is no cycle between the images of the snippet.
Since Bootstrap 5, the amount of time to delay between automatically
cycling to the next item is defined by `data-bs-interval`. The bug
comes from the fact that some parts of the code still used the old
parameter name (`data-interval`).
opw-3165570
closesodoo/odoo#113423
X-original-commit: 8368fa1f5e45a14ed8938017b2da90a810dbf0c8
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Step to reproduce issue:
- Go to sales settings, activate "Unit of Measure"
- Set user define default of field "uom_id" of model "product.template"
- install "loyalty" module.
While loading file "addons/loyalty/data/loyalty_data.xml" file it will create product and gives traceback.
Or
- It will also give error while upgrade database from 14.0 to 15.0 or more
Note : This error occurs while there is user-define value for uom_id is set and any module tries to
create product from data file.
Current behavior:
- When product creates, uom_id and uom_po_id gets default uom value from
"_get_default_uom_id" method which return "Unit" uom as default.
But when user have default value for uom_id(let's suppose Days), it sets that default
value and for uom_po_id we got uom value as "Unit".
- So now as uom category of Days and Unit are not same it violates "_check_uom" constraint.
Traceback: https://pad.odoo.com/p/utpr-set_default_uom
Soultion:
- When product creates, if there is default value for field uom_id in "ir.default" then
"_get_default_uom_id" method sets same value for uom_po_id.
closesodoo/odoo#113300
X-original-commit: 33a20cf799a6cbca6a55cb82f90c4451df60fa1c
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
- l10n_it_edi: EDI receiving cron error handling fix
If we cannot receive invoices or bills from the IAP proxy we also can't
iterate over them
- l10n_it_edi: Check edi_format before trying to remove signature
The edi_format must be checked before trying to remove the eventual
PKCS#7 signature from the file, otherwise we're uselessly going to try
and remove the signature for every edi_format check (facturX etc.)
- l10n_it_edi: .p7m files can wrongly be missing the signature
In the case that the .p7m extension is put by mistake, try to use the
content of the file as it is before discarding it.
Task link: https://www.odoo.com/web#id=3189457&model=project.task
Task-3189457
closesodoo/odoo#113451
X-original-commit: 942e3c7f2b549fed86f9eb76f98f30b7e5db1ae9
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
With this revision, the label of the field of the first row groupby is
inserted as the row title.
Task-id 2901960
closesodoo/odoo#107220
Related: odoo/enterprise#37395
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
If a user decrease the SOL qty of a kit once the return is done, an
unexpcted picking will be created
To reproduce the issue:
1. Create a kit K:
- With one component
- There is one component in the stock
2. Create and confirm a SO with 1 x K
3. Process the delivery
4. Return the delivery
5. Set the SOL qty to 0
Error: a useless and unexpected picking is created to return the kit
When setting a new SOL qty, we check if we should create and run a
new procurement to adapt the qty on delivery-side. To do so, we get
the qty being delivered, and we compute the difference with the new
SOL qty. Here is the issue, when getting the qty being delivered, it
returns the old SOL qty (1.0):
https://github.com/odoo/odoo/blob/797f67bcb222142b79a9eee3e4a882ff679af9db/addons/sale_mrp/models/sale.py#L164-L167
This is not true. Since the kit has been returned, the qty being
delivered is zero. As a result, a procurement is created to
compensate that incorrect qty.
The incorrect return value (1.0) comes from [1]. However, that fix
is not correct. Here was the initial issue: To get the qty being
delivered, we use the moves of the components, include the BoM lines
qties and try to compote the kit quantity. To do so, we call
`_compute_kit_quantities` with the components' moves and the kit qty.
However, there is an error: the moves are based on the old kit
quantity, and we give the new kit quantity to the method. This is why
the result was incorrect in the use case of [1].
[1] bafad58353c562a9b79735640c23d3cca004e0b0
OPW-3077209
closesodoo/odoo#113438
X-original-commit: 0b8af1d63d496489ac1608141c9b2dbccc8b7966
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
It may happen that the response of a json rpc isn't json parsable,
for instance when the connection pool is full (PoolError). In this
case, the response is an internal server error (500) in html.
Trying to json parse it throws an error. Commit [1], backported in
15.0 by [2] aimed at throwing a more readable and meaningful error
when this happened.
However, this error occurs frequently on the saas for the moment
(see task 3193565), and users constantly report those HTTPError
tracebacks introduced by [1].
In 14.0, we were using jQuery ajax, and the legacy rpc and error
system, where those internal server errors were handled as
connection lost errors (error code -32098). So basically, a
notification was briefly displayed instead of an error dialog.
This commit restores the previous behavior in the new rpc service.
[1] https://github.com/odoo/odoo/commit/5c4a54022b320
[2] https://github.com/odoo/odoo/commit/a01122543a79cclosesodoo/odoo#113434
X-original-commit: 278686d8540a194f0af51e1a0b68b26b13eaf544
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Bug
===
The number property should be formatted like a normal integer / float field,
in the form view (show 2 decimal for the float, thousands separators, etc,
even when editing).
Task-3162402
closesodoo/odoo#113449
X-original-commit: 99c251820dcf4791625fabd3fcd61db84280d408
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
product._get_rules_from_location, orderpoint._compute_lead_days
and orderpoint._compute_rules can all be performances
bottleneck. This is mostly because the rules are retrieve
one by one, i.e lots of 'SELECT ... LIMIT 1' queries
are executed.
Refactoring this in stable is difficult because
there are lots of methods involved and the rules have
some type of hierarchy based on the location_src_id field.
So there are recursive calls that are hard to refactor.
Instead of doing that, the idea of this commit is to speed up
these individual 'SELECt ... LIMIT 1' queries by adding
b-tree indexes on some of the stock.rule fields that are
used as conditions of these select queries.
opw-2773988
closesodoo/odoo#113444
X-original-commit: a76c4944d09be9cacfe8d3bac805841d84fb3f41
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Van Delft Aurélien (avd) <avd@odoo.com>
l10n_gcc_invoice implements invoice template with mixed english arabic labels.
This commit makes some clean up on text/columns direction and alignment with a
focus on RTL readers.
1.
Lines with Invoice Date, Due Date, Delivery Date, etc. are aligned to right
Before
*Invoice Date: 9/11/2001 :etaD eciovnI)* ____________________________
After
____________________________ *Invoice Date: 9/11/2001 :etaD eciovnI)*
2.
Columns of order lines are reversed
Before
*Description - QTY - ... - Total Price*
After
*Total Price - ... - QTY - Description*
3.
English/Arabic titles in the headers are inversed (Arabic is on the top now, English is on the bottom)
4.
Small table with subtotal/taxes/total has reversed columns too, so values are
just below of Total column in the main table
Before:
*Title/eltiT - Value*
After
*Value - Title/eltiT*
5.
This commit also improves Payment Reference section to comply with other
sections, i.e. print single value and two labels.
Before
Payment Reference: INV/2020/00019 INV/2020/00019 :ecnerefeR tnemyaP
After
Payment Reference: INV/2020/00019 :ecnerefeR tnemyaP
STEPS:
* install l10n_sa
* create an invoice with customer that has Arabic language
* use "Send & Print" button to get pdf file
opw-3115673
closesodoo/odoo#113443
X-original-commit: 9f6ed327fe34738740d8cb3584313972c8a0f782
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
This commit removes the default `stage_id` group in the
'All Tasks' list view, as it is causing performance issues
closesodoo/odoo#113435
X-original-commit: 759d7b1a30841535de57c19954eff3507dd61eff
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Larcin Vincent (vila) <vila@odoo.com>
The delay of tooltips opened with the tooltip service can be given
in xml, with attribute data-tooltip-delay. If not specified, there
is a fallback in the service to 400ms. Before this commit, the
fallback wasn't correctly applied, because we parsed the xml delay
into an integer, which was NaN when the delay wasn't specified,
and as NaN isn't undefined, the fallback wasn't applied. As a
consequence, we opened the tooltip in a setTimeout with NaN as
delay, and it thus opened directly.
closesodoo/odoo#113425
X-original-commit: 553b2775a4b31c75d1d246816b749e4521e25726
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Let's say there is one account with code 431 and another with code 4310,
`ODOO.BALANCE("431,4310", 2022)` counts 4310 twice.
The reason is queries are done one code at a time, one by one.
The account 4310 is counted first when using 431 as a prefix (431%) and once
more with 4310 (4310%).
Now, the query uses all codes all at once.
The original idea was to cache queries as much as we could. If you later add the
formula `ODOO.BALANCE("431", 2022)`, the result would have been cached
because queries were done code by code.
Given the issue it brings, we thing this opmitisation is not worth it and is
therefore removed. It also makes the code client-side simpler.
opw-3144473
closesodoo/odoo#113418
X-original-commit: 07bd67f3a389bde4f33e08d97967dbb70ad5a19f
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Since [1] the highlight of the focused element in the search
auto-complete has disappeared. This makes the keyboard navigation barely
usable.
This commit restrains the owl styling of dropdowns to the Owl Dropdown
components. This restores the highlight of the focused element on all
website dropdowns (e.g. also the logged-in user one and the "+" to
display more menu entries).
[1] did move the bootstrap's dropdown specific style customizations to
`webclient.scss`.
Steps to reproduce:
- Drop a "Search" snippet.
- Save.
- Type "a" in the search box.
- Navigate the suggestions with the keyboard up and down arrows.
=> Currently focused element looked the same as the other ones.
[1]: https://github.com/odoo/odoo/commit/84715436d87bb05b421bc9ccaacda67d07571690
task-3148871
closesodoo/odoo#113409
X-original-commit: e21ab2cb4904da9efeb7710a8bf8f6efec67821b
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
1. Install [Manufacturing], [Sales], [Purchase] on Apps (ordered)
2. [Settings]>[Manufacturing]>[Subcontracting]: set
3. [Sales]
- [CREATE] product type [Service]
- On the tab 'Purchase' add a vendor, select [Subcontract Service]
- On the same tab add `Purchase description` then save
- [Orders]>[Quotations]
- CREATE, add the subcontract service product and set customer
- CONFIRM
4. [Purchase] - [Requests for Quotation]
- should show on the top of the list if vendor was new. click
- [Description] column does not show `Purchase description`
Desired: show relevant data
Impacted versions: 15 - master
opw-3152072
closesodoo/odoo#113407
X-original-commit: fa33657e5e134a9f412a17da4082467ec847e395
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Lee, Hansun (hale) <hale@odoo.com>
Steps to reproduce:
- In debug mode
- Go to a cancelled invoice in Accounting
- Click to the "Reset to draft" button in a fast timing (before the
`PopoverContainer` is mounted).
When hovering an element, a tooltip appears. If the target element
disappears before the `onMounted` of the `PopoverContainer`, then the
popover causes a crash because the target element does not exists
anymore.
This fix makes the `tooltip_service` verify that the target still exists
before adding the popover.
closesodoo/odoo#113406
X-original-commit: 589acab37a4c1b68876386b752a91c3412dc4569
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Dardenne Florent (dafl) <dafl@odoo.com>
The delivery should provide the same feature before and after
validation of the picking (however lot/package need a validation)
So the HS code should be available direclty since it's a static value
closesodoo/odoo#113390
X-original-commit: 350015088d3822cde84b5dcf83d053350beafa66
Signed-off-by: Steve Van Essche <svs@odoo.com>
When drag and dropping a grid item and then undoing the operation, it
is not undone correctly, causing the grid items to be broken. This
happens because since `observerUnactive` is called at the start of the
drag, the style (like the `grid-area`) and the grid classes changes are
not recorded and therefore, undoing does not restore them.
This issue was previously fixed in [1] by removing the call to
`observerUnactive` but it should not have been done and this call was
restored in [2].
This commit solves this issue by activating the observer for the
changes that have to be recorded when drag and dropping in grid mode,
in order to undo them properly afterwards.
[1]: https://github.com/odoo/odoo/commit/cc406afcea7bf5846233a9f97a4a8ac5f618f3ec
[2]: https://github.com/odoo/odoo/pull/106029
task-3074139
closesodoo/odoo#113384
X-original-commit: 1dfb127f70832aa9e9022ac337af343b7dc17729
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
1. Install [Manufacturing]
2. Go to [Manufacturing]
- [Configuration] > [Settings], toggle on [Work Orders]
- [Operation] > [Work Orders]
- click on Kanban view
- remove all filters, then click on [Group By] - choose any
Issue: overflowing state tag beyond each kanban card
Resolve by: ordering line by line the information to display
Impacted versions: 16.0 up to master
opw-3162947
closesodoo/odoo#113386
X-original-commit: a72dbedcb00cef76e9a85f59cc875461cf38eafe
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: Lee, Hansun (hale) <hale@odoo.com>
In the website editor, a traceback error occurs when clicking on the
main element since the commit [1]. This is caused by the function
'_handleSelectionInTable' calling 'selection.getRangeAt(0)' without
checking if there is at least one range in the selection.
Steps to reproduce the bug:
- Open the website editor and drop a text snippet onto the page.
- Click on the snippet to activate it.
- Click on the empty area below the snippet, which corresponds to
the <main> element.
- A traceback error will appear (if it does not appear, repeat the
first three steps multiple times).
[1]: https://github.com/odoo/odoo/commit/d977bd64fe88c059c915f9eb0f8029cde65b216a
task-3196722
closesodoo/odoo#113383
X-original-commit: 6e79728c7e812458709d3a60ba37dc4c578905b2
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this PR, messages received on channels with unknown channel
types weren't displayed on discuss. This was due to the fact that
the sidebar computed its items based on the channel type.
Steps to reproduce this issue:
- Open one browser as mitchell admin (on the Discuss app).
- Open one browser as marc demo (on the Discuss app).
- Send a message from admin to demo.
- Unpin the channel on the admin browser.
- Refresh admin browser.
- Send a message from demo to admin.
- The message is not received on the admin browser.
This PR fixes the issue by fetching channel data if the channel type
is missing when receiving a new message.
closesodoo/odoo#113377
X-original-commit: 3398aa8b10a1d9ad75552871e532f57ffcdd4a7f
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Stockbauer Matthieu (tsm) <tsm@odoo.com>
This commit, is part of a series of commits that aim to simplifie
the concrete fields API.
In this commit we will remove type prop from concrete fields. Now each
field could directly use this.props.record.fields[this.props.name].type
if they need to know the type of field.
task-id 3179751
closesodoo/odoo#112792
Related: odoo/enterprise#37118
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit, is part of a series of commits that aim to simplifie
the concrete fields API.
In this commit we will remove update prop from concrete fields. Now each
field will directly use this.props.record.update to make changes, and
handle the save in fields that need to (e.g. priority). As a consequence
of this, the record props need to be mandatory.
task-id 3179751
Part-of: odoo/odoo#112792
The ofxparse module explicitly uses an html parser instead of xml but
since bs4 4.11.0, this triggers a warning.
closesodoo/odoo#113354
X-original-commit: e81ed97c9c54c69c68c54c69b4d3d80ed0515ae8
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Philippe Wauthy