*: l10n_co_pos, l10n_fr_pos_cert, l10n_gcc_pos, l10n_in_pos,
l10n_sa_pos, pos_adyen, pos_discount, pos_epson_printer,
pos_epson_printer_restaurant, pos_hr, pos_loyalty, pos_mercury,
pos_restaurant, pos_restaurant_adyen, pos_restaurant_stripe, pos_sale,
pos_sale_product_configurator, pos_six, pos_stripe
We are about to refactor most of the Javasript code base of the point of
sale and related modules. In doing so, we will move a lot of files and
modernize the entire code-base. In order to avoid diffcult rebases,
their conversion to odoo-modules is done as a first step to avoid
getting lots of conflicts on files that were unindented, which marks the
entire file as being in conflict. Conflicts will occur during forward
ports but they will be easier to manage as the changes will be much
smaller in scope, and the author will have the context of the change
that causes the conflict in mind when dealing with it.
closesodoo/odoo#107621
Related: odoo/enterprise#34910
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Now that dashboard views have been removed, there is no reason
to keep a dedicated module with 2 custom fields that could be
in community.
* Move sale.report fields:
* invoice_status field is simply moved as is
* avg_days_to_confirm is removed, as it was only used and meaningful in the dasbhoard view
* Merge views content inside the parent view
Task-3011195
closesodoo/odoo#104920
Related: odoo/enterprise#33588
Related: odoo/upgrade#4010
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The aim of this commit is to simplify and standardize the settings archs.
To do this, a small DSL exclusively for the settings was created. This
new DSL introduces 3 tags: `app`, `block` and `setting`.
The `app` tag is used to declare the application on the settings view.
It creates an entry with its logo on the sidebar of the view. It also
acts as delimiter when searching.
```xml
<app string="CRM" name="crm">
...
</app>
```
- `string` : The "display" name of the application.
- `name` : The technical name of the application (the name of the module).
- `logo` *optional* : The relative path to the logo. If not set, the
logo is created using the `name` parameter :
`/{name}/static/description/icon.png`.
The `block` tag is used to declare a group of settings. This group can
have a title and a description/help.
```xml
<block title="Title of group Bar">
...
</block>
```
- `title` *optional* : The title of the block of settings (the old h2),
you can perform research on its text.
- `help` *optional* : The description/help of the block of settings
(the old h3), you can perform research on its text.
The `setting` tag is used to declare the setting itself. The first field
in the setting is used as the main field (optional). This field is
placed on the left panel (if it's a boolean field) or on the top of the
right panel (otherwise). The field is also used to create the setting
label if a `string` is not defined. The `setting` tag can also contain
more elements (e.g. html), all of these elements are rendered in the
right panel.
```xml
<setting string="this is bar">
<field name="bar"/>
...More elements
</setting>
```
- `type` *optional* : By default, a setting is visually separated on two
panels (left and right), and is used to edit a given field. By
defining `type='header'`, a special kind of setting is rendered
instead. This setting is used to modify the scope of the other
settings. For example, on the website application, this setting
is used to indicate to which website the other settings apply.
The header setting is visually represented as a yellow banner on
the top of the screen.
- `string` *optional* : The text used as label of the setting. If it's
not defined, the first field is used as label.
- `title` *optional* : The text used as tooltip.
- `help` *optional* : The help/description of the setting. This text is
displayed just below the setting label (with classname
`text-muted`).
- `company_dependent` *optional* : If this attribute is set to "1" an
icon is displayed next to the setting label to explicit that
this setting is company-specific.
- `documentation` *optional* : If this attribute is set, an icon is
added next to the setting label, this icon is a link to the
documentation. Note that you can use relative or absolute path.
The relative path is relative to
`https://www.odoo.com/documentation/server_version`, so it's not
necessary to hard-code the server version on the arch anymore.
closesodoo/odoo#106425
Task-id: 3081367
Related: odoo/enterprise#34337
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: "Michael Mattiello (mcm)" <mcm@odoo.com>
Unused catch block arguments are now forbidden even when prefixed with an
underscore: if the argument on the catch block is not needed, the use of the
optional catch binding is enforced.
Part-of: odoo/odoo#105433
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>
Current behavior:
In the sales report of a product, the margin was not appearing
for product that were sold in the PoS.
Steps to reproduce:
- Activate the margin option in the settings
- Create a product available in PoS, the product should have a price
and cost set
- Start a PoS session and sell the product, then close the PoS
- Go on the product page, click the "Sold" smart button
- Add the "Margin" measure to the pivot
- There is no value in the margin column
opw-2937616
closesodoo/odoo#101168
X-original-commit: b230194d8f6a93d374a31f05e74c8fb26277d905
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
When an invoice is generated from the POS there are no payment terms and
due dates put on the invoices. It was not really an issue before the pay
later feature, but now it is needed.
closesodoo/odoo#100189
X-original-commit: ed49bc766cf6956691ca87be50f352247828453f
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
This link module corrects some behaviors when both modules are installed and used.
The loyalty programs of quotations and sales orders are properly handled by the Sale app
and its corresponding loyalty module. Even when it is settled by the Point of Sale app,
it is still properly being handled by the Sale loyalty module and it should continue as such.
The loyalty programs of Point of Sale is not considering the order lines created by a
quotation or sale order.
closesodoo/odoo#99756
Signed-off-by: Masereel Pierre <pim@odoo.com>
Steps to reproduce:
- Install pos_sale module
- Create a product and set it as available in POS
- Create 2 variants and set a weight for each variant
- Open a POS session and make an order with one of the variants
- Go to the Sales -> Reporting -> Sales and select view pivot
- Set Gross Weight as measure
Issue:
Weight for ordered variant is set to 0.
Cause:
Sales Analysis is an SQL view and it use product template in instead
of product product to get the weight value.
opw-2956457
closesodoo/odoo#99518
X-original-commit: 3a2f845375400623e4cabba57e66373abe9d0b85
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
The goal of this revision is to get rid of the `groups_id` field of the model `ir.ui.view`.
- This feature wasn't really known or used by most developers,
and not straight-forward to understand.
Removing it allows one less complicated thing to learn for developers.
Besides, thanks to odoo/odoo#95729,
changing the behavior of the `groups=` attribute,
we can easily get rid of this `groups_id` feature
by simply adding `groups=` in the elements of the views
using the `groups_id` field, it will have the same effect:
adding the elements in the view only for the users part of the specified group.
- By getting rid of the groups_id many2many field on ir.ui.view,
it makes possible to cache the view architecture without
requiring to use the groups in the cache key.
Currently, if we want to cache the view architecture,
it would be required to use the intersection of the user
groups with the groups_id groups of the view,
making it costly to compute the cache key,
therefore altering the performance point to cache the view
architectures.
Part-of: odoo/odoo#98551
Before this commit: if the "Limited Partners Loading" were enabled, the
partner wouldn't set when using the "Quotation/Order" functionality
for unsynced partners.
Steps to reproduce the issue on the runbot:
Enable developer mode.
Go to the Point of Sale.
Open the config of any pos.
Enable "Limited Partners Loading" and set "Number of Partners
Loaded" to a low number (like 5 or 10)
Disable "Load all remaining partners in the background."
Open a new PoS session for the configured PoS
Use the "Quotation/Order" functionality.
Select any order, for example, S00043.
The customer is not set for the current pos order.
Solution
The solution is to load the partner.
Also, there was an issue when using the limited number of partner loading
when it tried to load the cached and paid orders' partners. I added a function
to load missing partners.
opw-2883686
closesodoo/odoo#97442
X-original-commit: 4d7c05346e0c253c8b11736b9ee9f8426a87f2af
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
The `sale.report` `paid` state is added in `pos_sale` and shouldn't be considered in the standard `sale` code.
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#96125
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Because MobileSaleOrderManagementScreen is rendered inside
SaleOrderManagementScreen, the `useListener` calls in
SaleOrderManagementScreen are called twice. This is because
MobileSaleOrderManagementScreen is derived from
SaleOrderManagementScreen. Because of this, when an event is triggered
in the SaleOrderManagementScreen, say the 'click-sale-order', the
handlers are called twice. To fix this, we should not render
MobileSaleOrderManagementScreen inside the SaleOrderManagementScreen
anymore. Instead, depending on the screen size of the device, identified
using `env.isMobile`, we show the appropriate screen, that is, when
`isMobile` is true, we show MobileSaleOrderManagementScreen otherwise,
we show SaleOrderManagementScreen.
closesodoo/odoo#95282
X-original-commit: 6a8a43d09a798be3dfc5581561b67bc5c5521634
Signed-off-by: Masereel Pierre <pim@odoo.com>
When opening the sale order management screen, we should always start
with the default domain so that we don't have instances where fully-paid
sale orders show in the screen.
X-original-commit: 5b8cff6a545d1fb3ee614cdd347e0aa463dc8a5e
Part-of: odoo/odoo#95282
When in mobile view, the sale order management screen don't show when
clicking the Quotations button.
This change fixes this problem. Check the comments in the changes for
more details.
X-original-commit: 4ac8c363213dec747a7ca1bf5f2b22c6e2c6abf2
Part-of: odoo/odoo#95282
Because the setup method is not properly executed, sale order management
screen crashes when viewed in mobile screen.
X-original-commit: c27716c97c4d32bb0b12f3772ea55941fa423c63
Part-of: odoo/odoo#95282
Sale orders' amount in POS are displayed in the POS currency but they
can be in another currency making it possible to settle the wrong amount
Steps to reproduce:
1. Install Point of Sale and Sales
2. Go to Settings > Invoicing > Currencies and activate another
currency (e.g. EUR)
3. Go to Settings > Sales > Pricing > Pricelists and create a new
pricelist for the new currency
4. Create a new Sale Order with the EUR pricelist and any product and
confirm it (do not invoice)
5. Open a new session in the POS Shop
6. Go to Quotation/Order
7. The new SO is displayed with the amount in EUR but the currency
symbol is USD
Solution:
Add a filter on the POS currency to the domain of the rpc call
search_read on sale orders
Problem:
The field `amount_total` is used to display the price but this field can
be in any currency
opw-2865371
closesodoo/odoo#94710
X-original-commit: 0ebe29c794813a0854c7a6f433088a919a52cbbc
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
Purpose:
- Move PoS settings in general settings to be consistent with the rest
of Odoo (PoS being the only app where settings are split in two locations)
- Clean settings by enabling obvious settings or dropping unnecessary ones.
closesodoo/odoo#84719
Task-id: 2753430
Related: odoo/upgrade#3260
Related: odoo/enterprise#24425
Signed-off-by: Masereel Pierre <pim@odoo.com>
Current behavior:
When selling a product that have a taxe set in a PoS, the sale report
was not correct. The collumn untaxed amount to invoice would contains
the amount to invoice that includes the taxes wich is not correct.
Steps to reproduce:
- Install sales & pos
- Set the Acoustic bloc screen tax to 15%
- Open a pos session and Sell an acoustic bloc screen
- Validate the payment and close the session
- Open the sales app
- Sell an acoustic bloc screen to any customer
- Deliver it (update it's quantity if necessary)
- Sales > Reporting > Sales
- Switch to the pivot view
- On the "measures" button, check "Untaxed Amount Invoiced" and "Untaxed Amount To Invoice"
- Show the entries by Order#
- "Untaxed amount to invoice" should be the same as "untaxed total"
opw-2681477
closesodoo/odoo#92217
X-original-commit: 8c20fb4e126822d81fa7e1de6912d5c75a881b7b
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Currently, when customer does not specify taxes on down payment product in pos
and tries to use down payment for quotation, they get javascript error.
With this fix we will assign down payment tax 0 in case there is no tax
specified
fixes OPW-2843483
closesodoo/odoo#91077
X-original-commit: c6ec2ccf611fa099187f0547222a5fa3c09da9af
Signed-off-by: Masereel Pierre <pim@odoo.com>
Before when reporting in the sale module in a multi-company
environment currencies where not converted to a unique currency
before mathematical operations (sum, avg, ...).
Now before mathematical operations currencies are converted to
the currency of the company currently selected.
Task - 2696759
closesodoo/odoo#83550
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
If applied, this commit will fix the following bug by making the
behavior of applying a down payment similar to doing it in sales app
Steps to reproduce:
1- install sales, POS
2- set customer tax t on down payment product and use the product in
POS and sales
3- Create a product p with tax t
4- add p to a new sales order so
from sales:
5-apply a down payment of a percentage per (let's say 100% for clarity)
6- the down payment is calculated correctly and the total amount to
be paid is per * (p.untaxed_price + t * p.untaxed_price)
now from POS:
5- choose SO from the list
6- apply down payment of percentage per
7- the down payment is calcualted incorrectly. the SO is double taxed.
now the amound due is
(per * (p.untaxed_price + t * p.untaxed_price)) * (1 + pos_default_tax)
Bug:
when applying a down payment the full amount is treated as the untaxed
amound and then later the POS tax is added on it.
Fix:
using the untaxed total and also using the down payment product tax
similar to what happens in sales since the 2 flows can be mixed
OPW-2790821
closesodoo/odoo#89915
X-original-commit: 7dbd8d8e6ea5149c0b8d388ebfb1d97e43d47783
Signed-off-by: Masereel Pierre <pim@odoo.com>
When showing the discount the to the public, the down payment and gift card products were taken into account in the discount computation shown in the receipt.
This also fix a mistake made in fc546e0481ae0159e67791240833bc1e38a4440f where it was implemented in the wrong place and returning a wrong value in a reduce callback.
closesodoo/odoo#89603
X-original-commit: 597ea7aa3f28ad82e602e1ba5679bb49d2973b78
Signed-off-by: Masereel Pierre <pim@odoo.com>
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Previously, only one popup is allowed such that when one is not
yet close, but another one is requested, the new one will replace
the old. The function that tries to wait for the replaced popup
will never resolve resulting to some potential broken state.
This commit resolves the said issue which now allows multiple
popups at a time. We can use POS instance without demo as an
example.
Before this commit: The popup that asks whether to load the demo
products will be shown but it will be replaced by the cash opening
popup.
After this commit: The popup that asks whether to load the demo
products will be shown, then the cash opening popup will show.
When the user is done with the cash opening popup, the demo products
confirmation is shown next.
closesodoo/odoo#83661
Related: odoo/enterprise#23859
Signed-off-by: Masereel Pierre <pim@odoo.com>
issues:
- search sale.report with `('order_id', '!=', False)` in list view =>
you might get lines without sale order, with the wrong product, ...
- group sale.report by product on list view => you might get lines with
a different product than the group
cause:
the sale.report IDs are an union of sale_order_line.id and
pos_order_line.id => so there can be 2 lines of sale.report with same
IDs but pointing two completely different record.
rejected solution:
using row_number() over() for ID after the UNION ALL => rejected since
there was a `row_number` on sale.report at one point that was removed
because of performance issue (03bd6f5243e189cd05b3fc7ad774cc07ea733e14).
solution:
using negative IDs for pos_order_line lines
drawback:
in 14.0, we already use negative IDs for sale_order without lines =>
the probability of conflict is lower for this case and sale.order.line
not being in conflict is better.
opw-2586062
opw-2694529
closesodoo/odoo#83621
X-original-commit: cdaf046637704b53047b79984669ed2044cd8da6
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
This commit modifies most of the usages of read_group and uses
_read_group instead. _read_group doesn't join automatically on the
many2one fields when no order_by is specified, making it more performant
when the "name" of the many2one is not relevant, which is the case for
most back-end cases
closesodoo/odoo#84908
Task-id: 2479334
Related: odoo/enterprise#24877
Signed-off-by: Raphael Collet <rco@odoo.com>
All named arguments on the catch block must be used. If for some motive
the named argument on the catch block is not used, its name must begin
with '_'.
closesodoo/odoo#85569
Related: odoo/enterprise#24867
Related: odoo/design-themes#552
Signed-off-by: Géry Debongnie <ged@odoo.com>
* remove unused delay column (there was no field using the value server
side)
* remove unused joins in the FROM part of the table definition (join on
pricelists)
* fix broken inheritance API
pos_sale inheritance adds a null value for fields not available added in
sub modules (website, invoice_status, ...). But this was only working
because the default value of the fields parameter of the _query method
was overridden to a dict in all overrides, filling the record while
climbing the inheritance chain.
This was clearly too magic, using information provided higher in the
inheritance chain, assuming you were calling the super before generating
the pos part of the query.
This commit cleans the methods and API of the model, providing clean
hooks and reducing the mess of values given in overrides of _query.
closesodoo/odoo#85125
Related: odoo/enterprise#24626
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Multiple refactors
- The module pos_hr had two attributes `cashier` and `employee` referencing to the same actual person. The `employee` attribute was removed for the sake of `cashier`.
- Refactor of the `useSelectEmployee` which returned functions that where used in two components. Instead, a mixin class was implemented and inherited from both components.
- Renaming of the substring `client` and `customer` to `partner` (css included) when it was referencing to the actual `res.partner` object. This way, developers will always know that the object used in the UI is coming from `res.partner`.
- Renaming of the substring `client` to `customer`(css included) when it was referencing to a real life person. This avoid having ambiguity since the term `client` can refers to multiple things (hardware, browser, person, ...)
closesodoo/odoo#83983
Related: odoo/enterprise#24477
Signed-off-by: Masereel Pierre <pim@odoo.com>
Current behavior:
In the PoS when you add an order the 2 terms "Settle the order" and "Apply down payment" where hardcoded in the code.
Steps to reproduce:
- Have PoS and Sale module installed
- Go in PoS
- Try to add an order sale
- The 2 terms are hardcoded and cannot be translated
opw-2754052
closesodoo/odoo#85168
X-original-commit: 440cd020cfce4147973d356fd714a5d78c315c70
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
In 6d13271aac, the API of useAutofocus was chanded but the calls to
useAutofocus in the module point_of_sale were not adapted accordingly.
We adapt them in this commit.
Part-of: odoo/odoo#84306
1. Create a SO in Sales App.
2. Open POS session.
3. Load the SO in POS.
4. Select "Apply a Down Payment". Insert any percentage (eg: 50%). Pay
5. Go back to SO in Sales App.
6. Deliver the product.
7. Create an Invoice and apply the down payment.
8. Open the draft invoice and delete it.
Downpayment made on POS is unlinked and cannot be reinvoiced.
This change will avoid deleting the downpayment if it is coming from the
POS. As that the order is validated in the process, it should
be not possible to modify/delete it anymore
opw-2744281
closesodoo/odoo#84140
X-original-commit: 0b1e2be9b6d41c53fdec718b576ba794b9c020ac
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Steps to reproduce the bug:
- Install pos_sale
- Connect as Admin
- Create a SO with qty > 1
- Create a new user and give him:
- “Administrator” access to inventory
- no access to POS
- Connect with this user
- Go to the SO created by the admin > delivery
- Try to validate a partial delivery and create a backorder
Problem:
Traceback is triggered, because we are trying to read the `pos_order_line_ids` field while the user does not have access to POS
opw-2746938
closesodoo/odoo#84248
X-original-commit: bdd20fa37a73436788c470190d7fbf5e4c83f913
Signed-off-by: Masereel Pierre <pim@odoo.com>
Current behavior :
When creating an invoice from a PoS the description attached to the product was not the same as the one in the SO
Steps to reproduce:
- create a SO from Sales
- create an invoice from the SO
- preview the invoice
- open a POS session
- fetch the same SO
- validate the order with an invoice
compare the 2 invoices, they are not the same
opw-2674896
closesodoo/odoo#83833
X-original-commit: dbd766f1b87f91eefce7b6e5946856961fd96c70
Signed-off-by: Masereel Pierre <pim@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
This commit accomplishes multiple objectives:
1. Loading of model data for the POS UI is now done in single
request (with some exemptions).
2. Backbone.js is removed and is replaced by reactivity.js
authored by the js framework team.
3. Better organization of assets in the `__manifest__.py`
Data Loading
------------
One request per model -- that's always been how the data is loaded
in POS UI. Now, we move the aggregation of data to the backend which
simplified the data loading. In the frontend, data loading is
initiated in `load_server_data` which makes the single rpc call
to the `load_pos_data` defined in `pos.session` model.
There remains some rpc calls during loading but the number is
greatly reduced.
This change result to faster loading of the POS UI. However,
there is no more progress bar during the loading.
Notable entry points:
- .js: `PosGlobalState.load_server_data`
- .py: `pos.session.load_pos_data`
It is possible to make customizations in the loading, but is done in
several steps:
1. Override `_pos_ui_models_to_load` to include the new model to load.
2. Define `_loader_params_<model_name>` to define the `search_params` and
optional `context`.
3. Define `_get_pos_ui_<model_name>` to return the data that will be
included in the full `loaded_data`. Perform the organization in this method
whenever necessary.
4. Override `_pos_data_process` for further post processing. The final
form of `loaded_data` in this method will be sent to the frontend.
Removal of Backbone.js
----------------------
POS is no longer dependent from `Backbone.js`, but it's replaced by a
new dependency -- `reactivity.js`. It's invented by the js framework
team which will be available in owl v2.
The consequences of this change are the following:
1. The old `PosModel` is renamed to `PosGlobalState`.
2. The name of the other models are kept (except Paymentline which
is renamed to Payment).
3. The name `PosModel` is now used as the base model of the data models.
This is symmetric to our use of `PosComponent`.
4. The instance of `PosGlobalState` is made reactive in `Chrome` (the
root component). As a result, whatever mutation made in that instance,
`Chrome` will rerender. But rendering is batched so multiple mutations
in a single sychronous function call will only result to a single
render call.
5. `PosModel`s can be extended in the `Registries` the same way as we
extend the `PosComponent`s.
```js
// E.g.
Registries.Component.extend(Chrome, PosResChrome);
Registries.Model.extend(Order, PosResOrder);
```
Reorganization of assets declaration
------------------------------------
This is a simple change that replaced the explicit enumeration
of loaded .js and .xml files. Also, we now have regions in the
manifest separating:
1. Augmentations of dependencies
2. Assets for `point_of_sale.index`
3. Assets for the qunit test (soon will be improved)
Other notable changes
---------------------
- Automatic call to `Order.save_to_db` is batched.
- Instances of `devices.DeviceProxy` (`proxy`), `devices.JobQueue`
(`proxy_queue`) and `BarcodeReader` (`barcode_reader`) are moved
to `point_of_sale.env`. Together with `posbus` and `posMutex`
(previously `flush_mutex`).
- `ActivePrograms` is now passed a props.
- `cashier` is no longer saved to `localStorage`.
- `pos_cache` is overhauled.
- `cache` is taken out from `PosDB` to prevent infinite rendering
loop whenever `cache` is mutated. It's now called `CACHE` in
the `db.js` file.
- reactive version of `posmodel` is exposed globally when in debug mode.
This means that calling when calling a mutator, the UI will react.
- Added control buttons in the `ProductScreen` is sorted during `Chrome`
setup. As a result, we don't need to worry on the loading order of the
control buttons components.
- Model can be simply instantiated using `BaseModel.create(obj)`. This
takes into account the extensions.
- `pos_coupon`: rewards are now updated whenever set_order is called.
- Component unit tests were removed. It wasn't useful and it just blocks
the development. We'll be introducing better unit testing later.
closesodoo/odoo#82461
Related: odoo/enterprise#23344
Signed-off-by: Masereel Pierre <pim@odoo.com>
Co-authored-by: Jacky (trj) <trj@odoo.com>
In the next version of Owl, all exported terms are directly available
from the top level `owl` object. This commit aims to adapt existing
imports to this new system. This is done by importing any Owl property
used in files at the top, right after the `import` or `require`
statements.
closesodoo/odoo#82736
Related: odoo/enterprise#23609
Signed-off-by: Géry Debongnie <ged@odoo.com>
When you are choosing to apply a down payment on a sale order in pos,
it'll add a line to the pos order with the down payment product and the
value you choosed.
In this case we are considering that the down payment product is set and
a traceback is triggered when you try to apply down payment.
So we are now handling this error when no down payment is configured.
closesodoo/odoo#83037
X-original-commit: a103a7f3c129cc1140b734f8f0be24cd4b8667b8
Signed-off-by: Masereel Pierre <pim@odoo.com>
Set up a [TEST] product with a tax A
Create a SO with [TEST] and a tax B and confirm
Open POS, import the created SO
[TEST] will be imported with tax A
while tax B should be pulled from the sale order line instead
opw-2699793
closesodoo/odoo#81580
X-original-commit: 0a5cbfeb7edcce6e6bb915d6e61c736491695ada
Signed-off-by: Masereel Pierre <pim@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Edoardo (pied)