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>
Since commit, odoo/odoo@f2b71d51aa
the text ellipsis is working again with long breadcrumb.
But in form view when there is a long breadcrumb, the
'form status indicator' (save, discard) is not visible anymore.
In this commit, we move the 'form status indicator' outside the
breadcrumb, so it can't be hidden anymore.
Note: we also changed the `align-items` to `flex-start` to keep all
buttons aligned on the top ('form status indicator', action menu, pager,
create button, send message, ...).
Steps to reproduce:
* Go to Sales
* Select a Quotation
* Click on the customer (to go to customer form view)
* Change its name to have a long breadcrumb
* Go back to the home menu
* Go to Sales
* Select the same Quotation as before
* Click on the customer (to go to customer form view)
* Change some data in the customer form => BUG
'form status indicator' isn't visible
closesodoo/odoo#104476
X-original-commit: df41c270b2372cd28226a16e089b71db32307159
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
"div" as a child of "tr" is not really allowed. Because of this,
custom widgets in a list_renderer are not properly styled resulting
to issue where a widget doesn't take the full height of the
parent "tr" element.
This was missed during initial wowl porting so in this commit,
we are putting the widget inside a "td" element.
closesodoo/odoo#104475
X-original-commit: 092b6b66d998795a03de82be4d33990a138396e1
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Since the iOS 16.1 update, the WKWebView used in the iOS mobile app
crashes when trying to instanciate a `SharedWorker`... even if this
feature was newly added in iOS 16.0.
Safari iOS doesn't seem to be impacted.
This commit works around this issue by disabling the usage of the
`SharedWorker` in the iOS mobile app, using instead the existing
fallback to a regular `Worker`.
Steps to reproduce:
- On a device running iOS 16.1
- Open Odoo in the iOS mobile app
=> Once connected the app freezes with a gray screen
opw-3045539
closesodoo/odoo#104459
X-original-commit: afac382bd711b1a506629742456d91526cc52c53
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
In `_compute_analytic_distribution`, we're dealing with recordset and so, should iterate on it.
Also, the distribution expects an id, not the record.
closesodoo/odoo#104458
X-original-commit: d41d5ef7aebc9f65066ecf86939e3f60aa515539
Related: odoo/enterprise#33378
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
Current behavior:
When setting up a sales team in the PoS setting and trying to invoice an
order, a traceback is raised.
Steps to reproduce:
- Go in PoS settings and set a sales team
- Open a PoS session
- Select a customer and add some products to the order
- Go to the payment page, select a payment method and clic on "Invoice"
- A traceback is raised
opw-3038413
closesodoo/odoo#104444
X-original-commit: b941f3999087146d1a7412bb35cec38fce6dd1a6
Signed-off-by: Masereel Pierre <pim@odoo.com>
Steps to reproduce:
- Setup Wire transfer as Payment Provider
- Create a sale from shop
- Use Wire transfer as payment method
- Go to Sales > Confirm the quotation
- Create Invoice
- Click 'Preview' to view invoice in customer portal view
Issue: internal server error
The `provider` field has been renamed to `provider_code` in b7f5eb54453737f371eda4ca897300b89abd9c2e
opw-3031308
closesodoo/odoo#104441
X-original-commit: 4841aae833c462cd28fe3dbc81f12fb35afc8187
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Signed-off-by: Stefan-Calin Crainiciuc (stcc) <stcc@odoo.com>
Necessary improvement to the snailmail invoice layout for snailmail to work since Pingen has deprecated their v1 API with the plan to shut it down at the end of 2022 + their v2 API's validation is stricter.
closesodoo/odoo#103806
X-original-commit: 69950a650115536f2d57b1f68b5adadd4c0453f3
Signed-off-by: Florian Daloze (fda) <fda@odoo.com>
Signed-off-by: Solan Delvenne (sode) <sode@odoo.com>
Pingen's v2 API does not offer an endpoint to generate a Cover Page automatically with an API call anymore, thus the need to generate it and append it to the invoice from the client-side beforehand.
X-original-commit: 13f934cebc35511f8ba587b9d07a658bf7c1e640
Part-of: odoo/odoo#103806
Steps to reproduce
==================
- Go to Project > My tasks
- Drag a card to another column
-> An error occurs
Cause of the issue
==================
`personal_stage_type_ids` was not changed to `personal_stage_type_id`
opw-3036820
closesodoo/odoo#104442
X-original-commit: 3afc32af953556227dc07f8c65b5301d10fa92fe
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
Also correct mistake in name of RDC in manifest.
Modification in the COA (clearer name) + change made on some account about reconciliation, before this commit there was way to much reconcilable account, it's now corrected
Demo company modified
Menu item added
closesodoo/odoo#104440
Task-id: 2350061
X-original-commit: 0caa35df57061576ffb14252b08379a382e39ef9
Related: odoo/enterprise#33372
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
Steps to reproduce:
In a base runbot with just contacts installed and the module
"account_edi_ubl_cii".
Go to contacts, Configuration, and Bank Accounts, try to create a bank
account for any user.
Issue:
The creation throws an error and doesn't let us create any bank account.
Solution:
We need to add the missing decorator: @api.model_create_multi, which is
needed when we work with vals_list.
opw-3039048
closesodoo/odoo#104427
X-original-commit: e83da6166da40f5c30c396e6aa9811c8ee1d0e6e
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Since we introduced in 15.0 the possibility to limit the number of
product loaded at the launch of the POS and to load the remaining ones
in background, we don't need anymore a cache of the products to have a
faster way to start the POS.
So we remove this module as it won't be needed anymore.
closesodoo/odoo#104423
Related: odoo/upgrade#3997
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
- Changes the tooltip of the account_prefix field
- Changes the name of the analytic_distribution field
- Changes the name of the group for the conditions
- Changes the size in the analytic_distribution_model_views of the analytic_distribution field
- Changes the name of the group for the analytic distribution field
closesodoo/odoo#103636
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Without this, it will simply ignored the given `_text` variable as the
t-nocache part is scroped. It means it can't access natively the
variables outside of its scope unless those are passed to the scope
through the `t-nocache-var_name` form.
Basically, it resulted in the "My Cart" never shown next to the cart
badge counter.
Most of the time, this text is used in replacement of the `fa` icon, so
it led to poor UI: a floating badge left alone.
task-3044936
closesodoo/odoo#104416
X-original-commit: cd50114cc422941920ff4d579ab6b48aae75cc6a
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Since the settings in POS have been moved to the general settings, we
have two way to access those general settings. First throug the general
settings, second when you open the shortlist of settings editable by
every pos manager and follow the link to the general ones.
In the second case, when we arrive into the general settings, the
settings displayed are not always the one of the POS config you come
from, because by default it only show the settings of the latest pos
config editted.
So we are now checking if we are comming from a pos config to display
the correct one.
closesodoo/odoo#104391
X-original-commit: b0df10c1e497f65b891f7141055e7f339d11b4b1
Signed-off-by: Masereel Pierre <pim@odoo.com>
Florent de Labarre