Before this commit, the arrows in the daterange picker to switch months
wasn't correctly displayed in light mode.
This visual bug was introduced due to styling changes made for
the dark-mode.
This commit fixes this.
closesodoo/odoo#104151
X-original-commit: caa5604fbf99f6cba763109e7c26fed6e2042642
Signed-off-by: Samuel Degueldre <sad@odoo.com>
As of now, if a user clicks on the "Save & New" button while the form is
not valid, it will disable all buttons without any options to make them
enabled again. The only solution then is to close the form and re-open
it.
Steps to reproduce:
Inventory -> Configuration -> Route -> Select any route -> Add a line to
the rules.
As soon as you click on the "Save & New" button and the form isn't
valid, you can't use any buttons anymore.
Part of task-2985735
closesodoo/odoo#102315
X-original-commit: 6d63d1035b28f2004774a99a7be84b92a1cb1883
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
Remove quick create from the places that is either not needed or not possible
Task #2850996closesodoo/odoo#104640
X-original-commit: ae0a11a8ce3c35542ba5ae8f6366018b88ec40d5
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Pouya Malekinejad (poma) <poma@odoo.com>
Steps to reproduce:
- Install `l10n_ar_website_sale` module
- Go to shop (Argentinian website) and add a product to cart
- Open cart and click on checkout
- Click on Customize and disable `Show b2b fields` feature
Issue:
Fields are no more displayed.
Cause:
Since the b2b fields template (`address_b2b`) is customizable (meaning
it can be enabled/disabled), it is possible for all countries to
display/hide the b2b fields, but for some countries (for example
Argentina) it should not; the b2b fields should always be displayed.
Solution:
Add a method (`_display_partner_b2b_fields`) on website model to know
if b2b fields should be displayed: return True if `address_b2b` view
is active on current website or if the company (based on the country)
must display them.
Move content (b2b fields; vat and company name fields) of view
`address_b2b` in `address` main view and let the `address_b2b` only be
used as switch to display or hide the b2b fields.
Add a condition in `address` view to display b2b fields only if the
method `_display_partner_b2b_fields` returns `True`
opw-2941199
closesodoo/odoo#104505
X-original-commit: 1b5c85722db00a44ed8c6cb0c2bdba8905dc5292
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
Steps to reproduce:
There is no possibility to reproduce it in test mode
But the flow would be:
- create a company with a NIF not registered
- Set up the EDI invoice
- Create an invoice
Issue:
When the NIF is not registered, is is possible to use it. It will only create an error `approbado con errores` which is apparently fine
Solution:
Whenever the server sent us an '1117' error code, we call again the post_invoice with a new context so we are able to send the request with the right information; that is, the correct ID Type whenever a NIF is not registered.
Indeed, whenever the error code is related to the NIF, is is possible to send again a request without having the invoice defined as "duplicated". It will only go through the process "AceptadoConErrores".
opw-2952108
closesodoo/odoo#104375
X-original-commit: 415d095cd418fd38d5749200724b6ce775ffa7f8
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
Issue:
When visualizing the calendar event update mail template there is few
or no default data. Unlike the other calendar mail template there is
no signature.
opw-2968890
closesodoo/odoo#99386
Signed-off-by: Arnaud Joset <arj@odoo.com>
When a record was deleted, the related messages were removed in discuss
front-end but the message counter was not updated. This solves this issue.
Task-2960281
closesodoo/odoo#99371
Related: odoo/upgrade#3841
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
When a record was deleted, the related messages were remaining in discuss
front-end causing an error when the user was clicking on them. This solves the
problem by removing messages in the front-end as soon as they are deleted.
Task-2960281
Part-of: odoo/odoo#99371
Notify the user when added as follower by the mean chosen in his/her
preference (inbox/email) and not exclusively by email as before.
Task-2960281
Part-of: odoo/odoo#99371
New phones go up to 48MP (Samsung Galaxy A22).
Also the error message was saying 4.5 instead of 45.
opw-3020614, opw-3020502
Close#104424closesodoo/odoo#104546
X-original-commit: 8b19107c69c648dbfba2a9304c04f0f55aac4b46
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Commit ef1cadce3c58d702b9e63e2102b72172e45c486f introduced the
inventory_quantity_auto_apply field used in inventory report.
The stock.quant create method can return an existing record.
In inventory report, updating an existing record do the job.
But adding an already existing record to the list creates an inventory
adjustment with no visual clue that the adjustment has to be applied.
closesodoo/odoo#101894
Task: 2961768
X-original-commit: 1e07d8e2bfe3d4f5e07fed8e96226ab1fdbf390b
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Jean-François Aubert <ajf@odoo.com>
Before this PR, the mail bot would have answered to every incoming
messages including system notifications. Answering to system
notifications makes no sense and leads to the answer being formatted
as a notification since the mail bot copies the message type of the
message being answered.
This PR fixes the issue by preventing the mail bot from answering
anything else than comments.
task-3044856
closesodoo/odoo#104636
X-original-commit: bb76e083d5adcc955967680c46b9cf2e39402783
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
The domain of the datasources was not recomputed on the deletion of a
filter that impacted it. Furthermore, the issue was also present when a
client would UNDO/REDO some revisions.
Task 3002004
closesodoo/odoo#104630
X-original-commit: 3b63d8d592482b655a4273bf9d5d98de3992d26a
Related: odoo/enterprise#33468
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Previously, when copying a report with top-level aggregation lines that reference other top-level lines, the codes in the aggregation formula where not correctly replaced.
This commit solves the issue, so reports can be correctly copied.
closesodoo/odoo#104632
X-original-commit: 94a524a1be42e2128b291a2357a637ddef4cce6b
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
*: website_sale
Since [1], it was not possible to edit a company team snippet image
anymore as soon as the page was saved once. Indeed that commit added
o_not_editable/contenteditable="false" on the parent column to make sure
no text can be added in that column and contenteditable="true" on the
images so that they are still editable (even though HTML-specs-wise
adding contenteditable="true" on images probably does not mean much as
images are self-closing tags, our editor understand that as the ability
to edit the image anyway). That contenteditable="true" part is however
removed when leaving edit mode... and was not restored upon entering
edit mode again.
This fixes the problems with a specific JS patch, we'll review to see if
better can be done in master.
Funny enough, that bug was actually gone in 15.0... by mistake. A recent
bug fix actually reintroduced that isolated bug at [2] (by reintroducing
the fact that images in a non-editable environment are not possible to
edit). The 3 opened tickets this commit mentions were actually reported
for 15.0 immediately after that, while the 14.0 being broken about this
since the beginning apparently did not bother anyone.
Note: as a forward-ported fix, this also takes the opportunity to clean
a bit what was done at [3]. (calling `_super`, no duplicated code,
adding comments, ...).
[1]: https://github.com/odoo/odoo/commit/656cac1bf21c7c5a56aa569008aac58436c747fb
[2]: https://github.com/odoo/odoo/commit/e113bae04a64a8bd341a80736086ab7c25079dd3
[3]: https://github.com/odoo/odoo/commit/e2f7b8fad76dc816b2f6864340d3740446117cdb
opw-3031217
opw-3032482
opw-3035289
closesodoo/odoo#104521
X-original-commit: 1636ba5ed2f8a284bef0930313a85cc3dc7cf072
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this PR when you select a pos.payment in custom, it raise.
It doesn't make sens to use api.model here
closesodoo/odoo#104615
X-original-commit: 2abeb8cc5b015263ce49d765315712f92ec25c25
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
The breadcrumb uses the "name" field by default which is lacking for
cron triggers. Use the cron name instead so that it shows
> Scheduled Actions Triggers Base: Auto-vacuum internal data
instead of
> Scheduled Actions Triggers Base: ir.cron.trigger,1
See also #69096closesodoo/odoo#104599
Signed-off-by: Rémy Voet <ryv@odoo.com>
When a report was set to only accept tax exigible items (typically for the generic tax report), its children did not inherit this behavior by default. Because of that, the localized tax reports and OSS reports didn't filter the items properly.
closesodoo/odoo#104611
X-original-commit: 547c00c221606af8b385fab347a34edb15f773cb
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Instead of making the language badge a list item, we bundle together
the email and the language badge and put them in a flex container
that wraps when the email is too long. The .ms-auto in the language
badge element makes it "float" to the right (or end).
Furthermore, we removed the t-if conditions because:
- Email (login) field is required anyway so it will always be there.
- Language badge will not render an element if it's empty.
closesodoo/odoo#104262
Task-id: 2758990
Signed-off-by: Julien Castiaux <juc@odoo.com>
The tour snippet_cache_across_websites is at some point switching
between websites. The selector would be taking the second option in the
website list, which may not be correct if a module is adding a website
in its demo data.
This change aim to always switch from website 1 to website 2, without
caring about any other potentially existing website.
closesodoo/odoo#104596
X-original-commit: 7f756cfd5abc740e1a93a3225481c36279f094ed
Related: odoo/enterprise#33444
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Purpose
=======
Notify HR when an employee changes their own info and check that everything is logged on the chatter
closesodoo/odoo#102069
Taskid: 3029662
Related: odoo/enterprise#32253
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
In some reports, the aggregation engine could face a problem if the number of elements of an addition (for instance) were too numerous.
If they were separated by spaces or \n, the addition would not occur and the error message would not be clear.
Trimed the spaces before dealing with said formula.
closesodoo/odoo#104568
X-original-commit: 738f2ff00a687e2df92b3eacd23c3cf5e83400a7
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
When reconciling an invoice using cash basis taxes with multiple payments, it is possible that some base or tax amount falls victim of rounding errors (for example, a tax amount of 9.99 would become 4,49 when paying the invoice with two payments of half its amount, hence loosing one cent).
In this case, when the invoice gets fully paid, we fix that by using adjustment lines in an exchange difference entry (even in monocurrency).
The bug we fix here is that the lines added into this exchange difference entry were never considered as tax exigible, and hence never appeared in the tax report, even though they should. This was due to the fact tax exigibility is recomputed automatically when creating the entry, so the value needs to be set afterwards.
OPW 2888592
closesodoo/odoo#104564
X-original-commit: cc924d5c91ccbb05f0f076faf5da8fbd739660b2
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Before this fix, when reconciling an invoice with a refund (both using cash basis taxes) in a multicurrency setup, the two cash basis entries that got created were made so that the invoice's used the refund's rate, and the refund's used the invoice's one.
This caused confustion, and forced Odoo to always add cash basis adjustment journal items in the exchange difference move, in order to balance the accounts properly.
By not swapping the rates anymore, we avoid the creation of these journal items.
OPW 2888592
X-original-commit: dc27baac2b39abcd77cfe20290393b246f7b2a9c
Part-of: odoo/odoo#104564
Consider the following situation:
1) Create a company in USD
2) Have an exchange rate of 1 EUR = 2 USD
3) Create a 1/3 tax
4) Make an invoice of one line of 100 EUR on which the tax is applied
=> In 15.0, this created:
- a base line of 200 USD = 100 EUR
- a tax line of 66.66 USD = 33.33 EUR
=> In 16.0, this creates:
- a base line of 200 USD = 100 EUR
- a tax line of 66.67 USD = 33.33 EUR
This is due to the fact 16.0 computes the tax amounts twice: once in domestic currency, and once in foreign currency (while 15.0 computed everything in domestic, rounded, then converted).
So, it does 100/3 = 33.33333333, rounding it to 33.33 and 200/3 = 66.6666666, rounded to 66.67.
The problem with the way v16 does it is that the ratio amount_currency/balance becomes inaccurate to recompute the exchange rate, due to the increase of the rounding difference (indeed 33.33/66.67=0,499925004 , wich is pretty far from the original 0.5). Because of that, when using a cash basis taxe of 1/3 on the exact same setup as in our example, instead of getting a base of 200, a base of 200.01 is computed on the cash basis entry (and hence used by the reports), even though the rate hasn't changed a bit.
To fix that, we now compute the tax amount directly in foreign currency, round it accordingly, and only then, convert it to domestic currency. Doing that, our test scenario gives the following:
200/3 = 66.66666 => rounded to 66.67 => 66.67/2 = 33.335 => rounded to 33.34
The lines become:
- a base line of 200 USD = 100 EUR
- a tax line of 66.67 USD = 33.34 EUR
With this, the tax amount on the invoice is now consistent with the currency rate: 66.67/2 = 33.335, which gets rounded to 33.34. The currency rate computed by the cash basis thus becomes 33.34/66.67 = 0.5001; way closer to the original rate, and not causing a significative enough rounding error to impact the base amount anymore.
X-original-commit: 68fe20f612b8da003415a061b18bb0464329dba9
Part-of: odoo/odoo#104564
Before this commit, the messaging rpc method ignored some parameters
when passed as `kwargs`.
This PR allow the following arguments to be passed either in `args` or
`kwargs`:
- `create`: `vals_list`.
- `write`: `vals`.
- `read`: `fields`.
- `readGroup`: `fields/groupBy/domain`.
- `search`: `domain`.
- `search_read`: `domain/fields`
closesodoo/odoo#104562
X-original-commit: 7cde0af7e370c830f9b18132139b4339d966cee6
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Stockbauer Matthieu (tsm) <tsm@odoo.com>
# Description
The absence of those fields can generate a log note spam & performance issue when updating an order line value.
# HOW TO REPRODUCE
- Create PO with 40+ order lines (50 recommend) (* SA to reproduce would be nice)
- Confirm PO (state needs to be "purchase")
- Update the Ordered Quantity of the first line.
- Save
=> PO Lines from page 2 and beyond have each created the following log message:
"The ordered quantity has been updated."
# Explanation
The purchase.order.line onchange will not save any update on 'price_total' because it is not on the onchangeSpec.
Then a purchase.order onchange is done, and this one does have 'order_line.price_total' on the onchangeSpec, forcing the onchange method to return the field 'order_line' (aka ALL the order lines) as updated.
When saving the changes, the JS framework, who does not have the data for the order_lines on the 2nd page, will not correctly filter the fields with real changes, and add the 'product_qty' field (and more) to the "write" call for every order_line not in the 1st page.
Then the write method, without checking if there is any real change on the product_qty, for each lines that has product_qty in the Write's values, will write in the log note and call a performance intensive method: _create_or_update_picking()
OPW-2982004
closesodoo/odoo#104549
X-original-commit: e99cdd6430bf85bcae8ec3b8febcf8e3719169a5
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: David <dafr@odoo.com>
Before this commit if a Table of Content entry was a too long word
without spaces, it span beyond the width of the menu part of the Table
of Content block.
Note that in Chrome, during Edit mode the words are already split
across several lines because the `contenteditable="true"` of the
`#wrap` node applies some built-in extra styles (not from user agent
stylesheet) among which `overflow-wrap: break-word;`.
After this commit long words are split across several lines.
task-2965279
closesodoo/odoo#104559
X-original-commit: ef7174e16663036d3598122d4abdcd5eab0189a0
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Purpose
=======
Onchange methods are executed in "edit-mode", so you need to save to get the definitive
values saved on the DB, but if you do a write on it, that changes are immediately saved
to the DB, so if you discard the changes on UI, you will have inconsistent data. That's
why you have to do update instead, that only modifies the temporary dataset.
Courtesy of https://github.com/OCA/pylint-odoo/issues/356closesodoo/odoo#104539
Taskid: 3046426
X-original-commit: 5f18f068e62ba6cf6296c5f818b2cdfabed1fdfb
Related: odoo/enterprise#33409
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
This fix allows generating the sitemap (via `website.search_pages`) via
RPC. The changes are necessary as since #99667 the `request` object is
no more available to RPC-executed functions.
See also: the `test_search` test case of `website.tests.test_page`.
closesodoo/odoo#104567
X-original-commit: 8f4e214417cfb1aed7e595b8d6ab71f33a347b29
Signed-off-by: Julien Castiaux <juc@odoo.com>
Install website then render a qweb template via xmlrpc, attribute error:
`request` has no `is_frontend` attribute.
Inside the qweb's `_prepare_environment` override of the http_routing
module (a dependency of website) is the following code snippet:
if (not irQweb.env.context.get('minimal_qcontext') and
request and request.is_frontend):
return irQweb._prepare_frontend_environment(values)
The conditionnal is about injecting extra informations in the qweb's
context in case we are serving a frontend request. By default, there is
no `is_frontend` attribute on the request object. That attribute is set
by the ir.http's `_match` override of the http_routing module (a website
dependency): it is set True when we don't match any endpoint or that we
match an endpoint that is `website=True`, it is set False otherwise.
The ir.http's `_match` method is called whenever we are serving a http
request whoose session is bound to a specific database. i.e. when there
is a valid database saved in the request's session. When there is not
database in the request's session (or that it is invalid) the matched
endpoint is directly called without going throught ir.http. Most
endpoints are only accessible via ir.http.
The two `/xmlrpc` and `/jsonrpc` endpoints are examples of endpoint that
do not require an established database connection to work. They perform
the request authentication and database connection themselves. It is
possible to call those two endpoints with no database saved in the
session, thus it is possible to call those two endpoints without going
throught ir.http. This is expected.
The two endpoints's duty is to execute public model methods and return
the xml/json serialized result. To do so, a registry is loaded on the
database with all the installed modules, including http_routing.
We fall in a situation where (1) there is a request, (2) we are using a
registry where http_routing is loaded, (3) there is no `is_frontend`
attribute on `request` as we didn't serve the endpoint via ir.http. This
situation is illegale.
To solve the problem, instead of working on the `if request.is_frontend`
bit of the above conditional, we decided to work on the `if request`
bit. ISO-model wise, RPC is an extra 8th layer built on top of HTTP.
HTTP is merely a transparent transport between a RPC client and a RPC
server, any other request-response capable procotol could fit. The
method executed via RPC must be independant from the usage of HTTP as
mean of transportation thus it should not be capable of using the
current request.
The proposed change is to temporary un-expose the current request from
the local-stack during the execution of the RPC method. This fixes the
problem as the code now run like it was executed from the shell or from
a cron. The other benefit is that the pattern used inside the condition:
`if request and request.is_frontend` doesn't need to change.
X-original-commit: f28863bfdaac3f644fcb274c856e0770783ed75c
Part-of: odoo/odoo#104567
Steps to reproduce:
- set time effeciency of a workcenter to less than 100
- on a product page with a BoM using that workcenter
- for the cost click on compute price from BoM
Bug:
workcenter effeciency is not taken into consideration
Fix:
included time_effeciency in computing the expected duration
addepted tests to take it into consideration aswell
opw-3033672
closesodoo/odoo#104566
X-original-commit: 1dcd9dbef0a5e6d9bd2c5e52a42cff9aec98f1d0
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
`Payment acquirer` model was renamed `Payment Provider` in f7b8f07.
closesodoo/odoo#104565
X-original-commit: 4f49b6f4f2c3537f4da581761bb34f8e7b4155e7
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Before this commit, in the list view, clicking on the "export all"
button created an xslx file that did not reproduce the order of the
columns in the view.
Why is this?
The order used was based on the data fetched by a
rpc("/web/export/get_fields".
Solution:
Do not do a rpc("/web/export/get_fields") and use the order of the
columns in archInfo.
How to reproduce:
- Go to a list view
- Click on the "export all" button
Before this commit:
The order of the columns in the created file may be different from the
order in the list view.
After this commit:
The order of the columns in the created file is the same as in the
list view.
closesodoo/odoo#104541
X-original-commit: 734eee368d548fddc6c516ff559d09e853d1ab74
Signed-off-by: Luca Vitali <luvi@odoo.com>
Before this commit, if a translation dialog was open, and the view where
the button is unmounted, the dialog stays open.
Now, the dialog closes, when the view is unmounted.
closesodoo/odoo#104543
X-original-commit: 40596ed1eccdf0f37b4fa3a8a337e7a7cc3461ce
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
The res.config.settings form view is handled with a custom widget
expecting a very specific structure.
a `<t>` node in the middle of
`<div class="settings">`
and
`<div class="app_settings_block">`
screws things up, and the app block will no longer be shown as expected
in the web interface.
This issue has been introduced with
odoo/odoo#103799
The current revision reverts the change so it becomes as before,
the `<t>` blocks with only `groups="..."` are removed from the
architecture, even if they have not been added by the postprocessing
itself.
An alternative fix is done,
directly in the `web_studio` module of odoo/enterprise,
to overcome the issue odoo/odoo#103799 was solving.
Both issues are covered with unit tests:
- the issue odoo/odoo#103799 was solving is covered with the unit test
added in the related odoo/enterprise#33075
- the issue solved by the current revision is covered with units tests
added in this revision directly.
closesodoo/odoo#104542
X-original-commit: 56d2de23919f9efa3cd1eef756725e8bc9b86d81
Related: odoo/enterprise#33410
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Before this commit, opening the Page Manager in debug mode would throw
an error, stating that the website.RecordFilter has a t-foreach with
duplicated keys.
As per the [owl documentation]: "Owl requires the presence of a t-key
directive, to be able to properly reconcile renderings." and "A key
should be a unique number or string."
This commit fixes the keys to be the website id instead of the website
object.
[owl documentation]: https://github.com/odoo/owl/blob/master/doc/reference/templates.md#loopsclosesodoo/odoo#104540
X-original-commit: 0d1c263298ca6724a6fe6c31e2a2d3221c5e8c75
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Using a `frozenset` leads to non deterministic issues.
Because when nothing is set in the context key `allowed_company_ids`,
`self.env.companies` will fallback on `self['res.company'].browse(user_company_ids)`
Since the browsing is done on a non ordered set, the recordset doesn't
follow the `_order` set on the model, by definition.
This has the effect of not being deterministic when iterating on
`self.env.companies`.
For instance
https://runbot.odoo.com/runbot/build/20539598closesodoo/odoo#104538
X-original-commit: bfee55b14c918c44ebbb2563d5dc0e102edf396e
Signed-off-by: Rémy Voet <ryv@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Steps to reproduce:
Go to a product form view that has a BoM.
Issue:
The price is diplayed collapsed with the units and currency text.
Solution:
We need to remove the class "o_row" in order to be displayed in 2
columns as it is in other versions.
opw-3041120
closesodoo/odoo#104460
X-original-commit: 812614b7d6e194f510491ff83f9a8e48594ae7c5
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
*: website_blog, website_event, website_forum, website_slides
With [1] it has been made easier for partners to extend search options.
This task introduces similar inheritable functions for blog posts,
events, forum posts, slides, pages and hybrid results.
[1]: https://github.com/odoo/odoo/commit/d29f2f3ac5f8c3e8109287e0933609bdbe0cadb1
task-2897924
closesodoo/odoo#97908
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
When `make_json_response` was added in
034d01b2f3 and `_response` was updated
to use it, the `http_status` extracted from the error object was
removed.
But it's still set by `handle_error` and a local is defined for
it. Drop that.
closesodoo/odoo#104507
X-original-commit: b0ea1cd6a2628a6acd1e2d79cc862976c63b1565
Signed-off-by: Julien Castiaux <juc@odoo.com>
Xavier Luyckx (xlu)