This commit adapts the directional icons to improve the usability and
maintain consistency with the ui icons library.
task-2818586
Part-of: odoo/odoo#116641
*: l10n_ae_pos, l10n_co_pos, l10n_fr_pos_cert, l10n_gcc_pos,
l10n_in_pos, point_of_sale, pos_discount, pos_hr, pos_loyalty,
pos_mercury, pos_restaurant, pos_sale, pos_six
The code of the pos was one of the first adopters of owl 1, as such, the
code was not initially written to take full advantage of the owl
reactivity system that would eventually make its way into owl 2. In
order to convert the code quickly when migrating to owl 2, a big
shortcut was taken: whenever something in the state of the pos changed,
the entire UI would be rerendered. While this works decently well in
practice, it can create confusing situations because the mental model
needed to understand how components work in the pos is different from
the rest of the code base.
This commit changes the existing code to use the typical fine-grained
reactivity model used everywhere else: components individually subscribe
to the pieces of state that they use and will rerender on their own when
this state changes. In order to achieve this, the pos global state has
been removed from the environment and should now be access through the
use of the custom hook `usePos` which will subscribe the component to
the state that it reads. This also has some minor performance benefits
as we only render the parts of the UI that actually need to update
whenever there is a state mutation, instead of the entire UI which can
be expensive in some cases (eg, the product screen will filter all
products during rendering to find only the products that match the
search, which is expensive when there are a lot of loaded products)
closesodoo/odoo#120992
Related: odoo/enterprise#40873
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
- The calculator logo of the cash opening popup has been changed to a
bill logo to be more explicite for the end user.
- The cash input is autofocused at the opening of the cash opening
popup. Select number input on focus and align numbers right money
details popup.
- Rearrange Close pos popup layout.
- Set the Gift Card amount to the price of the refound if there is one.
- Change pos_payement_method_view form id order to sequence. Set the
order of payement methods in PayementScreen to sequence.
- Fix markut issue in the chatter.
Task-3215901
closesodoo/odoo#118288
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
In odoo/odoo#120070 We refactor the pos to stop using the
action service, but one call in override pos_loyalty was
missed. This commits adapts that call to prenvent a crash.
Part-of: odoo/odoo#118288
The previous commit highlighted the fact that the pos is not really
tested on mobile. This commit creates a new class that extends the
TestUi class from point_of_sale, which runs most of the pos tours, and
runs all the same tours on mobile.
In order for these tours to run to completion correctly, a bunch of tour
utils have been adapted to add mobile-only steps or fork a step into two
mutually exclusive steps that run only on desktop or only on mobile. A
tour in pos_loyalty has been adapted to the change in the pricelist
selection utility function.
closesodoo/odoo#120791
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
The correct behavior for the gift cards should be that the value of the
gift card is equal to the value of the order line.
For example :
-50$ giftcard -> Apply discount 50% on the order line -> 25$ gift card
If we want to apply a discount on a gift card we need to use the global
discount
The commit we are reverting was forcing the value of the gift card to be
the base value of the order line.
This reverts commit 83ceeecde76a859749d0659d6c387d95155c8425.
OPW-3264945
closesodoo/odoo#120794
X-original-commit: 023e2f2571ab7c814ed3cad45871fc221562fb67
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
*: l10n_ae_pos,l10n_fr_pos_cert,l10n_gcc_pos,pos_loyalty,pos_restaurant,
pos_sale,pos_sale_product_configurator
This commit is the start of a series of changes in the definitions of formatters
and rounders used in pos. We are introducing a new service called
`contextual_utils_service` that loads when the `pos` service is ready making
sure the currency is loaded. In this service, we define `formatCurrency`
(potentially others) which is the replacement to `format_currency{_no_symbol}`.
Also, instead of defining our own formatter, we are depending on web's
`formatMonetary`.
In this commit, we are replacing all uses of `format_currency{_no_symbol}` with
`formatCurrency` that's based on web's `formatMonetary`.
Part-of: odoo/odoo#120317
*: l10n_ae_pos, l10n_co_pos, l10n_fr_pos_cert, l10n_gcc_pos,
l10n_in_pos, l10n_sa_pos, point_of_sale, pos_adyen, pos_discount,
pos_epson_printer, pos_epson_printer_restaurant, pos_hr,
pos_hr_restaurant, pos_loyalty, pos_mercury, pos_restaurant,
pos_restaurant_adyen, pos_restaurant_stripe, pos_sale, pos_sale_loyalty,
pos_sale_product_configurator, pos_six, pos_stripe, web
Previously, the pos assets included almost the entirety of the
assets_backend. Most of the contents of the assets_backend is completely
useless in the PoS, meaning that the PoS will load slower because it
loads much more JS than it needs. It also means that it gets all the
side effects of this bundle (global event listeners, among other things)
that we don't want.
This commit removes the dependency of the pos assets on the
assets_backend to solve these issues. The pos assets are now their own
bundle with only what is needed in the PoS.
As for the unit testing bundle, the same logic applies but
unfortunately, because the unit testing code from web that we want to
use (eg automatic cleanups, cleaning of registries, etc) depends on the
legacy code, we need to include a lot more files than would otherwise be
needed. This situation will probably be improved as legacy code is
removed from web, but in the mean time, it is not very important for
this bundle to be lean, as it's a test bundle and loading speed is less
important.
Linked to: odoo/enterprise#40502closesodoo/odoo#120070
Related: odoo/upgrade#4626
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Previously, when a reward was applied on a product, the product was
checked against the reward_product_ids field, which is a computed m2m
field that contains all the IDS of the products on which this reward is
available. In many cases, rewards are available on all products, causing
the computation of the m2m to fill it with the ids of all products.
This caused performance issues on all DBs with lots of products (~200k)
in all flows involving rewards.
We can't remove reward_product_ids from the data loaded in the frontend
in stable because existing JS customisations might crash if they depend
on its presence. As such, to keep compatibility with existing databases,
an ir.config_parameter has been introduced to opt into the new
behaviour. This parameter is set when creating a database so that new
databases don't suffer from this performance penalty.
For existing databases, the parameter can be set by hand if the old
behaviour is not necessary and the performance penalty is an issue in
practice, but is unset by default.
When opting into the new behaviour, the reward_product_ids field now
always evaluates to an empty recordset, and the desired behaviour should
be achieved by evaluating records against the reward_product_domain
instead. In the point_of_sale, the products available on rewards are
calculated by evaluating each product against the reward when it is
loaded. In the loyalty modules, instead of using the in operator on the
reward_product_ids field, we instead evaluate the reward product domain
against the product, which is much faster. This is always done even when
not opting into the new behaviour as the change in implementation cannot
be observed outside of timing.
closesodoo/odoo#120074
X-original-commit: 6f72d053a31aca520cbfbba2d1257568b7f7c0cb
Related: odoo/enterprise#40503
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
When a valid gift card is added in a empty cart, the pos will display a
notification of the resume of the gift card.
We also made the notification component to preserve white space.
Task-3265311
closesodoo/odoo#118609
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
The price_manually_set variable was used to largely, we fix it
by adding a price_automatically_set variable. The price_manually_set
is now used when changing the price through the numpad, whereas
price_manually_set is used to indicate that the price is not
the price set in the database.
closesodoo/odoo#119362
X-original-commit: aa4f346d27aa28c23f8ee02fe73b892a1f5ef2dc
Signed-off-by: Heinz Robin (rhe) <rhe@odoo.com>
*: l10n_fr_pos_cert,portal_rating,pos_adyen,pos_epson_printer,pos_loyalty,
pos_mercury,pos_restaurant,pos_restaurant_adyen,pos_restaurant_stripe,
pos_sale,pos_six,pos_stripe,web
This is part of the continuous effort of refactoring pos addons towards using
more modern modules and programming patterns (such as services). After this
commit, point_of_sale addons are now left with the use of the legacy
`web.concurrency` module because of the `MutexedDropPrevious`. It's okay to keep
it because it's relatively an independent module compared to other legacy web
module.
The following summarizes the changes in this commit.
- import `_t` from `@web/core/l10n/translation`.
- convert `PosDB` to js native class
- remove use of `format` in `TicketScreen`
- To determine the cached orders are up-to-date, we now deserialize the dates
coming from the server using web's `deserializeDateTime` function. Then,
instead of initiating `cacheDate` as native js Date, we use the luxon's
`DateTime` which is supported by the web date utility methods.
- There is no need for the `format` function from `web.utils` legacy module.
- convert `PaymentInterface` to native class
- remove use of `web.config` module
- remove use of `web.time` module
- use `serializeDateTime` from web.
- remove use of `web.rpc`
- remove use of `web.utils` module
- introduce simple check for email address input
- Replace use of `web.utils.Markup` with `@odoo/owl.markup`.
- 'web.utils'.{round_decimals,round_precision,float_is_zero} copied to
'@web/core/utils/numbers'.{roundDecimals,roundPrecision,floatIsZero}.
- These helper functions are not removed from the web addon because they
are also used from other addons that are not linked to pos.
- `floatIsZero` is now computed by directly comparing the result of
`roundDecimals` to zero. This works because rounding a decimal number
which will result to zero will exactly give zero.
- remove use of `web.field_utils`
- Replace `web.field_utils.parse.float` with
`@web/views/fields/parsers.parseFloat`.
- Replace `web.field_utils.format.float` with
`@web/views/fields/formatters.formatFloat`.
- Replace `web.field_utils.format.date` with
`@web/core/l10n/dates.formatDate`.
- Replace `web.field_utils.format.datetime` with
`@web/core/l10n/dates.formatDateTime`.
- convert `PrinterMixin` and dependents to native class
- `PrinterMixin` is converted to `BasePrinter`.
- `Printer` is converted to `HWPrinter` (extending `BasePrinter`).
- `EpsonPrinter` retained its name and is converted to extend `BasePrinter`.
- Moreover, we also removed the convoluted `PrintResultGenerator`, replaced by
simply creating object with the following signature:
```js
{ successful: boolean; message?: { title: string, body?: string } }
```
- remove use of `web.Session`
- replace use of `qweb.render`
- We use `renderToElement` as replacement to templates that produces valid
html.
- Note that `renderToElement` is introduced in `@web/core/utils/render` module
which is extracted from the original `renderToString` method.
- For the epson printer template, we kept the xml layout and manually add
required xml element to contruct the xml that will be sent to the epson in
making print requests.
- use `Mutex` from `@web/core/utils/concurrency`
- remove use of `Markup` when rendering receipt info (`ticket`) in order to
render new lines.
- Remove use of `jquery` in `htmlToImg`.
closesodoo/odoo#117231
Related: odoo/enterprise#39078
Signed-off-by: Samuel Degueldre <sad@odoo.com>
The loyalty details on the orders were not useful for the end user.
Now we delete it from the order widget. It also fits the sale behavior where we don't show those informaitons.
closesodoo/odoo#118789
Task-id: 2980232
X-original-commit: bafcda0e8c851fb66b0f6c6cb890cf0bdaad596d
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
After this commit, we will be using float_compare function to compare
points. This will ensure that any floating point errors are properly
handled and that we receive correct responses from the
`validate_coupon_programs` function.
opw-3264681
closesodoo/odoo#118829
X-original-commit: 48013733a6e8b655cbc81211b1010e76102b9c2a
Signed-off-by: Heinz Robin (rhe) <rhe@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
*: web
This commit removes the use of the legacy environment from the PoS, as
it is no longer needed. This will allow us to more easily use the new
unit testing infrastructure from web.
Part-of: odoo/odoo#117290
Steps to reproduce the error:
1. Open a Pos
2. Without any orderline, click on `+-` button
3. You will see an error
issue https://github.com/odoo/odoo/issues/115642closesodoo/odoo#117620
X-original-commit: a588bb7fbe9ad6accaa12ebf1ce59767284c4f12
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
In the current tour steps, there's ambiguity in the failing step and its
preceding steps. Basically, the failing step asks to click a selection item
that contains "Monitor Stand" and the previous step also do the same: clicking a
selection item with "Free Product - [Desk Pad, Monitor Stand]". And if you
notice, both step has text "Monitor Stand". Given the nature of the tour runner,
it will try as fast as it could to do the steps, so it will click "Free Product
- [Desk Pad, Monitor Stand]" then it will immediately be followed by clicking
"Monitor Stand" which is the same element clicked by the previous step. In
essence, the two steps only resulted in one action.
As a solution, we make sure to distinguish the first step of selecting
the reward program, followed by selecting the reward product.
We use the fact that a second span under `.selection-item` will be rendered
when displaying the program selection, therefore, we introduce an
extra_trigger in first step (provided by `claimReward` helper function).
Then, we add more steps that checks the selection items on the expected
2nd selection popup.
closesodoo/odoo#116819
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Current behavior:
When you sell a gift card in the PoS with a discount, the value of the
gift card is not correct. For example, if you sell a gift card of 100€
with a 50% discount the customer should pay 50€ and the gift card should
be worth 100€. But the customer pays 50€ and the gift card is worth 50€.
Steps to reproduce:
- Create a gift card program
- Open a PoS session
- Sell a gift card of 100€ with a 50% discount
- Pay the order
- The value of the giftcard should be 100€ but it is 50€
opw-3221553
closesodoo/odoo#116746
X-original-commit: 1631ab332a6c9c7ca5e1f2451a51fb663534cb8e
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
**Notable feature changes**
- PoS app continues to load even if no nomenclature_id is configured.
- When scanning, an error popup is shown to the user mentioning about
the misconfiguration.
- We introduce a default error handler that shows the ErrorBarcodePopup
when there are no registered barcode handlers via the
`useBarcodeReader` hook.
closesodoo/odoo#115906
Related: odoo/enterprise#38444
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Previously, the payment button was larger than the others and next to
the numpad. The other buttons were managed by a mixin and arranged
in a predefined order.
Now, the payment button only stays in place when the "order" button is
not present, currently it can only be present if the restaurant module
is installed and a printer configured.
When it is present, it takes the place of the payment button and the
latter is added to the mixins with the other buttons
closesodoo/odoo#115988
X-original-commit: f32c07f28e2fd2830f568757d4700fa77b83ced7
Related: odoo/enterprise#38476
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Add a stat button on customers views to easily retrieve all
the linked loyalty cards.
task-3050152
closesodoo/odoo#107375
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Before this PR, the name of the program from which an award comes
was not displayed in the selection popup.
closesodoo/odoo#112122
Taskid: 3069449
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
* The tours are now run by the `MacroEngine` defined in `macro.js`.
* This is accomplished by converting (at runtime) the user-defined tours to
`Macro`s. See `tour_compilers.js` for the step (and tour-to-macro) compilation.
* API is kept the same as much as possible. Basically, declaring tours stayed
the same with some exceptions:
* `allowInvisible` can be provided in a step to allow consuming the trigger
element even if it is invisible.
* `isCheck` can now be used to replace the no operation `run` that is
traditionally signals the runner to only perform a check.
* Before, multiple `run`s can be called simultaneously. Now, each `run` method
is awaited before proceeding to the next step.
* If the trigger element is `disabled`, the tour runner will *not* proceed on
calling the `run` method and the runner will stay on current step until the
trigger element becomes `enabled`.
* However, the tour runner is okay with `disabled` trigger element if the step
has `isCheck = true`. As long as the trigger element is found for `isCheck`
step, the tour runner will happily move to the next step.
* Some tours are adjusted to properly run with this new tour runner.
* When the tour failed:
* The dom string is not logged anymore.
* However, a warning message containing the relative location of the step will
be logged. This is better in helping the author in locating the failed step.
**Some guidelines learned during the development:**
* Each step may trigger a dom mutation. It's a good practice to insert an
intermediate step that *checks* the existence of an element that result from
the action of the previous step.
* Refrain from using the `run` method for assertions. `run`, in principle, is
provided to perform actions that are not offered by the helper. Use the
`trigger` for assertions.
* During dev, find `SHOW_POINTER_DURATION` and set it to `250`. This will show
the pointer (pointing to the trigger element) for 250ms when watching the
tour.
closesodoo/odoo#107618
Task-id: 3082036
Related: odoo/enterprise#37560
Signed-off-by: Géry Debongnie <ged@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
*: l10n_co_pos, l10n_fr_pos_cert, point_of_sale, pos_loyalty,
pos_mercury, pos_restaurant, pos_sale, pos_sale_product_configurator
This is a step in the direction of making the pos no longer depend on
the legacy environment.
closesodoo/odoo#114668
Related: odoo/enterprise#37906
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Before this commit, when loading the pos with pos_loyalty, even if limited product was activated, all the products were loaded to make sure that we could apply rewards.
Now, we don't load all the products but we only load the rewards by default.
closesodoo/odoo#114021
X-original-commit: 60e7cdee62cf6b19ce0b26f2c7cbe708f74a806e
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Currently, when there is a huge number of loyalty cards (>4000) for
the LoyaltyProgram for instance, loading the Customer View in a
pos session can take a few seconds. This is mostly due
to the getLoyaltyCards function in JS.
This commit adds a small cache in the form of a partner_id ->
coupon_ids mapping. This cache is a kind of like a view
on the couponCache and it allows to retrieve the PosLoyaltyCard
instances from the couponCache much faster.
opw-3145342
closesodoo/odoo#113805
X-original-commit: 2e88d9fef8e713ccc4227cd14b0fa85420d983e3
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Van Delft Aurélien (avd) <avd@odoo.com>
Steps to reproduce:
- Install pos, pos_loyalty, sales and activate the discounts and coupons
- Create a Discount code for the POS.
- Go to the POS see panel of buttons.
Issue:
Having discount codes in active won't trigger the button for enter the
code to be activated.
Solution:
We added the discount codes (`promo_code`) to the part in
`PromoCodeButton.js` that handles when we display the button.
opw-3193426
closesodoo/odoo#113646
X-original-commit: 200cf4ffa2e18498fdda62c51f7016cf0172e273
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Maruan Aguerdouh Mohtar (magm) <magm@odoo.com>
*:point_of_sale,pos_ayden,pos_discount,pos_hr,pos_loyalty,pos_mercury,
pos_restaurant,pos_sale,pos_six
Previously, the point of sale and related modules made heavy usage of
`useListener`. This is because the pos was converted early to owl, and
in owl 1, using events to communicate between components was encouraged.
In owl 2, the decision was made to stop encouraging this way of
communicating between components, because it encourages communication
accross many layers of components, and is also hard to debug. In
addition, in owl 2, because components can have 0 or more than node,
including non HTMLElement nodes like text or comment nodes, owl removed
the implementation of useListener, as useListener relies on the presence
and unicity of a root HTMLElement per component on which we can attach
event listeners.
Another problem is that events rely on the fact that the components are
in the DOM so that the event can propagate, which can lead to issues in
some cases and in particular, in the PoS, if you load the point of sale
and switch tabs, some things will be broken because we are triggering
events, but there have not been any animation frame fired in the tab
because it's not focussed, and so owl has not mounted the component yet.
When migrating odoo to owl 2, we introduced a shim for this.el and
useListener in LegacyComponent, with the hope to remove it as soon as
possible.
This commit removes all usage of useListener from the pos modules for
those reasons. In some cases, useListener was incorrectly used intstead
of t-on, and the event was triggered and handled by the same component,
in other cases, a simple callback could be passed to a child component.
In a few cases, a method had to be implemented on the store as we wanted
this method to be available everywhere.
closesodoo/odoo#112219
Related: odoo/enterprise#36888
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Current behavior:
When you have a loyalty program with a free product, and a rule with a
minimum amout. The free product is not added to the order if the free
product is already in the order.
Steps to reproduce:
-Set a loyalty program with the following Conditions:
Minimum Qty: 1
Minimum Spend: $5
Grant: 10 Points/Order
-Reward:
Type: Free Product
Item: Any item (eg: Bacon Burger)
Exchange: 30 Points
1. Open POS that has this loyalty program.
2. Process sales with a Test User until user has 30 points.
3. Attempt to redeem the Free Product under "Reward".
Note: I modified the other test, IMO it makes sense that when triggering
the rewards it adds Product A and Product A * -1. Because if the product
that was already in the order become free, the rule to trigger the
rewards is not met anymore.
opw-3135794
closesodoo/odoo#113313
X-original-commit: 253d308a26f1e6479c1d3c5342e1cede6f635198
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Currently, it is possible to assign the same "Cash" payment method to multiple PoS.
At the moment, when creating a new PoS, Odoo tends to assign it by default. Although this is highly not recommended as it can only lead to incorrect cash control (two PoS devices rarely share the same till and therefore needs their own cash payment method).
This commit makes sure payment methods of type Cash aren't set by default when creating new PoS.
it also blocks the user from setting the same Cash payment method to multiple PoS configs.
closesodoo/odoo#92664
Task-id: 2857417
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
*: pos_discount, pos_hr, pos_loyalty, pos_restaurant, pos_sale, pos_six
Previously, all components in the pos and related apps would inherit
from the PosComponent base component, this component contained a bunch
of methods that were as such available on every component in the pos
passively. In previous commits, a bunch of these methods have been moved
either to the pos store or to their own services, so that component
dependencies are explicit instead of every component having a clobbered
namespace and having access to everything implictly.
This commit factors out the last method of the PosComponent,
`setSyncStatus` and as such the PosComponent is now empty and can be
removed completely, as can the Gui singleton utility which was used to
access these methods from outside of components.
Components in the pos modules now inherit from LegacyComponent which
PosComponent extended. The end goal is to remove the use of
LegacyComponent as well, but currently it is still needed as components
in the pos modules make extensive use of `useListener` which requires
the shim for `this.el` provided by LegacyComponent. This is nonetheless
a first step in that direction.
This commit also removes some components that were used in the navbar as
they were very small and it made more sense to just have the behaviour
they implement directly in the navbar component or elsewhere. Most of
the CashMoveButton was moved to the CashMovePopup, the TicketButton has
so little behaviour that moving that behaviour to the navbar itself
makes sense.
closesodoo/odoo#112295
Related: odoo/enterprise#36860
Signed-off-by: Heinz Robin (rhe) <rhe@odoo.com>
*: l10n_fr_pos_cert, point_of_sale, pos_discount, pos_hr,
pos_hr_restaurant, pos_loyalty, pos_mercury, pos_restaurant, pos_sale,
pos_sale_product_configurator, pos_six, pos_stripe
Continuing to move things out of the Chrome god component, this commit
does the following things:
- moves the showScreen and showTempScreen methods and the corresponding
closing methods into the pos store so that components that need them can
access them through the pos service in a more explicit way. To that end,
these methods have been removed from PosComponent and Gui.
- introduces a popup service instead of using a bus in the env, this is
mechanically very similar but closer to what's done in web and hopefully
a first step to using the dialog service instead. It also removes the
showPopup method from the PosComponent and Gui, to make components
depending on the popup service explicit.
- makes the number buffer into a service instead of being a directly
imported singleton, which will enable it to be used with hooks instead
at a later point, and allows easier dependency injection in tests.
- removes showNotification from the PosComponent and Gui, the
notification system was already converted to a service in a previous
commit for the same reasons as showPopup and the end goal is to use the
notification service from web to reduce duplication.
closesodoo/odoo#111844
Related: odoo/enterprise#36668
Signed-off-by: Samuel Degueldre <sad@odoo.com>
This commit is a forward port from v16. It completes another commit that was
done in master only:
https://github.com/odoo/odoo/commit/7c415e972fa97ba52d8d5165fd47494965e3053d
---
Module `pos_restaurant` synchronizes orders between different POS devices. It
works by pushing order from POS to server and loading it back. This commit
assures that loyalty fields are correctly prepared before returning values to js
client. Specifically, many2one fields must be just ids [1] [2], and not `[id,
name]`. Similar cleaning is already done in `pos_restaurant` module for `product_id`
field [2].
To correctly implement this patch, empty `_prepare_order_line` is added to
`point_of_sale` module to be sure that extension of that method in `pos_loyalty`
is not ignored: the method in `pos_restaurant` didn't have `super` call and
`pos_loyalty` module doesn't depend on `pos_restaurant`
STEPS:
* install pos_restaurant, pos_loyalty
* prepare gift card
* open pos, create order, apply gift card
* switch to floor screen and then back to table (order) screen
[1]:
https://github.com/odoo/odoo/blob/c4b90db77705139333bdf5faf26b12fc120d1661/addons/pos_loyalty/static/src/js/Loyalty.js#L833
[2]: https://github.com/odoo/odoo/blob/c4b90db77705139333bdf5faf26b12fc120d1661/addons/pos_restaurant/models/pos_order.py#L76closesodoo/odoo#111617
X-original-commit: 0cf1fb6cf9dad69d58939d735081428a5e1650f4
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Ivan Elizaryev (iel) <iel@odoo.com>
This is a step closer to a goal of avoiding dependence on asynchronous
modules. Starting from this commit, new tour definition should be
registered to `registry.category("web_tour.tours")` registry.
So, instead of the following:
```js
import tour from "web_tour.tour";
tour.register(name, options, steps);
```
We now do:
```js
import { registry } from "@web/core/registry";
registry.category("web_tour.tours").add(name, optionsWithSteps);
```
Notice the `options` and `steps` params are merged when registering
the tour definition. It should look something like so:
```js
registry.category("web_tour.tours").add("account_tour", {
test: true,
steps: [ ... ],
});
```
And if the `TourManager` instance is needed, one can get it from the
registry like so `registry.get("tourManager")`. Note however that
this instance is only available when the `TourManager` has been
instantiated -- so it's not available at top level of the module.
closesodoo/odoo#111103
Related: odoo/enterprise#36335
Signed-off-by: Géry Debongnie <ged@odoo.com>
Previously, reward_id was an array of two elements containing
the ID and name of the reward. But in the frontend,
reward_id is supposed to be an int with the ID
Adaptation of the _prepare_order_line function in the following modules:
- point_of_sale
- pos_restaurant
- pos_loyalty
Now the data is correctly sent to the frontend and the error
is no longer present.
closesodoo/odoo#111048
Signed-off-by: Heinz Robin (rhe) <rhe@odoo.com>
*: l10n_fr_pos_cert, l10n_gcc_pos, pos_hr, pos_loyalty, pos_mercury,
pos_restaurant, pos_restaurant_adyen
In odoo/odoo#109928 the custom inheritance system of the pos was removed
and a bunch of modules were adapted. In a lot of those places, the
_super calls didn't forward the arguments to the super method, resulting
in broken methods. This commits fixes that.
closesodoo/odoo#110962
Related: odoo/enterprise#36269
Signed-off-by: Samuel Degueldre <sad@odoo.com>
*: 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_hr_restaurant, pos_loyalty,
pos_mercury, pos_restaurant, pos_sale, pos_sale, pos_sale, pos_sale,
pos_sale, pos_sale, pos_sale_loyalty, pos_sale_product_configurator,
pos_six, pos_six, pos_six, pos_six, pos_stripe, pos_stripe
Previously, the point of sale module used a custom inheritance system
for models and components. This system being non-standard, it makes it
hard for newcomers to understand how to use it or for people with
experience in the pos code base to understand how things are done
elsewhere. This commit removes the "registries" system from the pos
modules and adapts existing code to use standard inheritance mechanisms,
ie extending classes directly, and using patch to modify behaviour in
place.
task-3119628
closesodoo/odoo#109928
Related: odoo/enterprise#35795
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Co-authored-by: Samuel Degueldre <sad@odoo.com>
Current behavior:
When a global discount is applied, it is considered as a regular
orderline when computing the order discounts. Because of this if you
applied a coupon and a global discount, the pos would add a discount of
infinity value.
Steps to reproduce:
- Create a promotion with a discount of 10%
- Create a product with no taxes
- Enable the global discount feature, and make sure the Discount product
has a tax set on it.
- Create a new order, add the product, apply the promotion, and apply
the global discount.
- The order will have a discount of infinity value.
opw-3094784
closesodoo/odoo#108441
X-original-commit: 1ea082b933a9583a9af1839164e919a0ac7512f9
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
*: 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>
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>
Current behavior:
In the PoS if you apply a coupon on an order that contains 2 products
with different taxes, it will create 2 discount lines on the order.
If you change the pricelist, the discount lines won't have the correct
values.
Steps to reproduce:
- Create 2 different products with different taxes.
- Create a pricelist with a discount on the 2 products.
- Create a coupon that apply a 100% discount on the order.
- Start a PoS session
- Add the 2 products to the order and apply the coupon.
- The order total is now 0€.
- Change the pricelist to the one with the discount.
- The order total is different than 0€.
opw-3049098
closesodoo/odoo#106835
X-original-commit: 36dc1fce19403935770eaaaf5c1177fc8c1ef2bb
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Current behavior:
If you create an empty Db and just create one coupon program for the PoS
, the `enter_code` button is not displayed. This happens because the
condition to show the button was looking for program type `coupon`
instead of `coupons`.
Steps to reproduce:
- Create an empty Db (Important)
- Install PoS and PoS Loyalty
- Create a coupon program for the PoS
- Open the PoS, the `enter_code` button is not displayed
opw-3078726
closesodoo/odoo#106824
X-original-commit: 1eaa36faf8447d6fbe80f4bcdb512dd4505827d8
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Overall improvement and simplification (along with some minor re-alignment)
for the point of sale.
POS Dashboard:
- added a new check for companies that hasn't installed any chart of account,
this gives them a better understanding of the real problem.
- added a new `menuitem` in the configuration tab that list all the pos configs,
this gives the user a way to access the sub-config of a pos (and indirectly give
access to its whole settings)
Opening/closing control:
- the `MoneyDetailsPopup` is now opened through the `showPopup` method, we're
no longer using the css to show/hide.
- the details of the money (if it exists) is now given to the `MoneyDetailsPopup`
component, this allows to have a record data usable of the details and
the user doesn't have to start from scratch if he just wants to modify
one thing
- opening the `MoneyDetailsPopup` no longer resets the cash input, that way the
user can just quickly check if everything is correct again without having
to recount everything and this won't reset the outcome
Customer display:
- added "Powered by" before the Odoo logo in order to accentuate that
it's from the software used is from Odoo
Product screen:
- visual improvement of the `EditListInput` component which is mostly
used by the lot/serial number, it gives more information to the user
and better UX
- "Cash out" is now automatically selected upon opening the
`CashMovePopup`. No more minus sign (-) in the input amount. This
should give better intuitiveness and one less click to do
- no more clear search button shown if the search input is empty
- removed the hover and clickable effect on `CashierName` component
in the normal point_of_sale since nothing happens when we click on it
- increased the width of the click zone with a label in the
`ProductConfiguratorPopup` which makes it easier to select a radio input
- the `PrintBillButton`, `SplitBillButton`, `RewardButton` and
`ResetProgramsButton` are now disabled when nothing happens
- the `textarea` of the `TextAreaPopup` component has been fixed
and is no longer resizable
Partner list screen:
- fixed phone, mobile and mail icons the contact area
- increased details button size
Floor screen:
- when idle, no longer redirect to the floor screen if there's
an open error popup. An error popup is opened for a specific
reason, we shouldn't redirect while having this open or
automatically close it. Other kinds of popup will be
closed since those are issued by the user that went away.
task-2916197
closesodoo/odoo#97803
Signed-off-by: Masereel Pierre <pim@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
Brieuc-brd