In this commit, all usages of env._t() are replaced by _t().
In templates files, env._t() didn't work because terms used
in attributes where not extracted into the translation files.
Only string are exported from .xml files to translation files.
So, to make it works, we set a variable that is then used
in attributes.
For example :
<t t-set="string_to_translate">String to translate</t>
<Dialog title="string_to_translate>...</Dialog>
task-3292454
closesodoo/odoo#131390
Related: odoo/enterprise#45631
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
As all the templates are now imported in the owl app, there is not need
anymore to specify the owl="1" attribute in the templates.
Part of task~3443861
Part-of: odoo/odoo#130467
In the commit [1], the patch has been refactored to support the
native keyword `super`. The current commit just adapts the codebase
to that change.
task 3410198
[1]: 19ea1ac08043e22a811630968e44715cc3bfc495
Part-of: odoo/odoo#125716
In a previous commit 8bfa76a, _lt() returns _t().
So, in this commit, all usages of _lt() are replaced by _t().
task-3292454
closesodoo/odoo#130179
Related: odoo/enterprise#44906
Signed-off-by: Luca Vitali (luvi) <luvi@odoo.com>
pos*: l10n_ae_pos,l10n_co_pos,l10n_fr_pos_cert,l10n_gcc_pos,
l10n_in_pos,l10n_sa_pos,pos_adyen,pos_discount,
pos_epson_printer,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
In the previous commit, we moved and renamed files such that they
better follow certain guidelines.
In this commit, we adapt imports accordingly.
In order to efficiently accomplish this task, i used the following [script](https://github.com/vlst-odoo/tools/blob/main/fixImports.py)
Task: 3394192
Part-of: odoo/odoo#127056
pos*: l10n_ae_pos,l10n_co_pos,l10n_gcc_pos,l10n_in_pos,
l10n_sa_pos,pos_adyen,pos_discount,pos_epson_printer,
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,
The POS has a large number of add-on modules. As such, it is
important that they all respect strict guidelines when it comes
to file structures.
Before, each module had more or less it's own rules when it came to
this, apart from the fact that code was mostly organised into
`js` and `xml` folders.
In this PR, we move to a much more structured approach,
in which each module follows the following pattern:
src/
|-- app/ <-- the module's own new logic
|-- overrides/
| |-- components
| | |-- overridden_component_a
| | | |-- overridden_component_a.js
| | | |-- overridden_component_a.xml
| | | |-- overridden_component_a.css
| |-- models
| | |-- overridden_model.js
Apart from the structural changes, this PR introduces changes
to file names, such that they respect the default pattern of
snake_case naming.
In this commit, we move the files. In the following one we
make the needed changes in the code, such as adapting imports.
In order to efficiently accomplish this task, i used the following [script](https://github.com/vlst-odoo/tools/blob/main/rename.py)
Task: 3394192
Part-of: odoo/odoo#127056
*: point_of_sale, pos_adyen, pos_hr, pos_mercury, pos_restaurant
Adds online payments in Point of Sale using the payment module.
The pos_online_payment module is meant to be used by shops for paying online instead of using a physical terminal and by restaurants for paying an order either from the paying station or in the self-order process (smartphone used to order and pay online).
The module depends only on point_of_sale (and account_payment to support online payments).
The online payments support for self-order will be added in another commit.
The feature can be used by configuring a special pos.payment.method for one or many pos.config.
Operation:
The frontend session user can enter one or several online payment method lines (with or without other payment methods).
When he validates the order, if the online payment amounts are valid, a popup with a QR code is displayed on the frontend screen and on the customer display. This QR code allows the customer to open the payment page to pay online for the order.
The amount to pay for an order on the payment portal is the remaining unpaid amount or a lower amount if several online payments lines are used. Therefore, at any time, the customer will be able to pay the amount of the order that is unpaid, without requiring a staff operation to update the amount to pay.
When an online payment is done for a POS order, the generated account.payment is linked to the POS order through a pos.payment that is created with the online payment method configured for the pos.config, and the POS order paid process is triggered (it is the responsibility of the server to finalize the validation of POS orders that have at least one online payment, and not the responsibility of the POS session web client). If for any reason, there is no longer any online payment method configured for the pos.config of the order, a new one can be created automatically and exceptionnaly used to link the done payment with the POS order. This guarantees that any online payment saved by the payment module will be linked to the POS order.
The session web client is notified of successful online payments through web socket communication, to make the cashier screen automatically and quickly react to payments.
If several online payments are used for a single POS order, they are processed one after each other.
Working principles:
- The POS session web client is not allowed to save online payments on the server. Only the Odoo server, which handles the payment, can save online payments for a POS order.
- The POS session is only responsible for saving the order (especially other payment methods) and the next online payment amount to pay (in case of several online payments) on the server before the online payments are made by the customer, and for displaying the online payment status and the link (QR code) to open the payment page.
That means that modifications that are made after the order is fully paid are not taken into account by the server.
- Before validating an order, the POS session checks with the server if any online payment has been made for that POS order. If the user wasn't aware of one, the validation process is aborted, notifying him.
- The sensitive online payments data is received by the frontend user with RPC to the server when validating an order, cancelling an online payment or receiving a notification through the POS bus (web socket communication).
This data is used to update the cashier data for the specific order.
- No sensitive information is sent through the POS bus (web socket communication).
Indeed, the bus communication is only protected by the name of the channel, and there is no mecanism to prevent several attempts. Therefore, no sensitive information is sent through it, only a notification to invite the local browser to do a safe RPC to the server to check the new state of the order.
- Online payments for a POS order cannot be modified or removed when they succeeded. Checks ensure to never allow an online payment to make the total paid amount greater than the total amount of the POS order.
- If the frontend user clicks on the "Cancel" button of the online payment popup, the order can potentially still be paid online. Indeed, the order will be removed from the server only if it was added only for the online payment flow, and any order that is not paid can be paid on the online payment portal (if the customer has the web link).
This behavior ensures that in a shop, starting an online payment and then cancelling it doesn't prevent the user to close the POS session. And it ensures to don't delete a draft order that is used for other flows, like in a restaurant or when there are trusted POS configs.
Payment portal features:
- The payment portal pages of a POS order are protected with its access_token.
- If the amount of the order has changed when the customer clicks to pay, an error is fired to notify him and give him the choice to continue or abandon the payment.
- An exit_route argument (an URL) can be passed to allow the customer to exit the payment portal at any time (with a button), which could be used for self-order flow.
- A button to go back to the payment page is displayed when an error occurs during a payment transaction, which allows the customer to retry a payment without needing to scan again the QR code.
- If the customer is not logged in in the payment portal (most frequent case), it is considered as the public user partner for the payment flow to don't give him privileged access to sensitive data like payment tokens.
- The accounting process of online payments for POS orders is made in the same way that the pos.payment.method that have split_transactions to True.
- The POS customer of a POS order has no link with the customer making an online payment for that POS order.
- The payment portal is made using the pos.order id and not the pos_reference because the latter is not guaranteed to be unique.
Some tests have been written, especially one that simulates a whole online payment flow starting from nothing, creating an order, requesting an online payment, faking this online payment by doing web requests to the payment portal, then finally closing the POS session to check that there is no accounting issue.
The design of the payment portal is temporary.
closesodoo/odoo#123237
Task-id: 3276404
Related: odoo/enterprise#41776
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Specify explicit route for each ,, line
This is part of task 3230280 where global ir.model.access will be
forbidden.
The goal is to make access to public/portal explicit. Too often,
global access was granted with only employees in mind.
Remove ,,0,0,0,0 lines
mail:
employee already had read access to mail.group
still needed to subtypes as in ir.rule domain
mail_group: employee already had read access
pos_mercury: only needed for employees
membership:
move public access for website_membership as needed in the controllers
website_customer: employee already had read access
website_event_booth: no need for category
website_event_exhibitor: retrieved in sudo
website_event_track: not needed for location
Part-of: odoo/odoo#125216
*: l10n_ae_pos, l10n_co_pos, l10n_fr_pos_cert, l10n_gcc_pos, l10n_in_pos, point_of_sale,
pos_adyen, pos_discount, pos_epson_printer, pos_hr, pos_loyalty, pos_mercury,
pos_restaurant, pos_sale, pos_sale_product_configurator, pos_six, pos_stripe
After the architectural refactor of the PoS App, there are two classes that make sense to merge.
In this refactoring task, we're merging them.
closesodoo/odoo#124477
Task: 3358550
Related: odoo/enterprise#42257
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
pos*: l10n_ae_pos, l10n_co_pos, l10n_fr_pos_cert, l10n_in_pos,
point_of_sale, pos_discount, pos_epson_printer, pos_hr, pos_loyalty,
pos_mercury, pos_restaurant, pos_sale, pos_sale_product_configurator,
pos_six
Previously, none of the templates of the pos were namespaced, this means
that depending on context, you have to access them differently: in xpath
the module prefix is necessary even if the template name itself isn't
namespace, but in owl components you cannot use the namespaced version
because owl doesn't have the notion of modules.
This commit namespaces the component templates of all the pos modules so
that it's consistent with the rest of the code base. It also removes
some extraneous calls to super.setup() that were leftover and are not
necessary for components extending directly owl's base Component.
closesodoo/odoo#124069
Related: odoo/enterprise#42094
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
pos*: l10n_co_pos, l10n_fr_pos_cert, l10n_gcc_pos, l10n_in_pos,
l10n_sa_pos, pos_adyen, pos_discount, pos_epson_printer, pos_hr,
pos_hr_restaurant, pos_loyalty, pos_mercury, pos_restaurant, pos_sale,
pos_sale_loyalty, pos_sale_product_configurator, pos_six, pos_stripe
The previous commit reorganizes the files in the pos, this commit
renames all of the imports of those files to match their new location.
This is done in a separate commit to allow git to better keep track of
the changes and apply forward-ports more seamlessly.
Part-of: odoo/odoo#123498
Currently, only stable releases see their translations updated. This has
resulted in master accumulating outdated stuff for years, which can be
confusing for users testing master on runbot.
This one-shot commit resynchronizes master translations based on the
content from 16.0 and removes empty PO files (i.e. no longer containing
translations).
closesodoo/odoo#121629
Related: odoo/enterprise#41171
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
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>
*: 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>
Fixed the popup call. The call was made with the old method showPopup.
The call is now made with the new .add method on the popup service.
closesodoo/odoo#120274
X-original-commit: d174e6cdacfdde6973e4ced931bb7572b6bd0511
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Signed-off-by: Monnom David (moda) <moda@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>
Since 8fb53c53c3, Order model is no longer
a backbone model therefore, we can no longer call the "trigger" method
on it. Normally, the old "trigger" call means we want to rerender the
screen and persist the new order information in the local storage.
The order object is already setup to do those mentioned (rerendering
and saving to local storage) when it's mutated. Therefore, we can just
simply remove the "order.trigger" and "this.render" calls as proposed
in this commit.
closesodoo/odoo#117915
X-original-commit: 603d73ad8f181a4e5154153cad2cbb18a493b536
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@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>
Problem:
When point_of_sale and pos_mercury are both installed,
_gc_old_tokens will get called by the scheduled action "Base: Auto vacuum internal data"
and it will try to remove the Vantiv tokens from POS orders that are 6+ months old.
However, there are fields named ref_no and record_no that exists for pos.order;
so the AttributeError will get thrown.
Solution:
It is safe to remove the entire method since the Mercury API documentation
does not explicitly mandate the tokens be removed from old POS orders.
It was recommended by JOV to not modify the method to prevent the modification of
potentially 8 years old POS orders from client's databases.
Since the method is removed, the error will not be thrown when auto vacuum is called,
pos_mercury is installed, and POS orders are 6+ months older.
opw-3082616
closesodoo/odoo#115466
X-original-commit: 41a82c3326150fba6948667c9e455ae82088bb6d
Signed-off-by: Trinh Jacky (trj) <trj@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>
The type fields of actions already defaults to
the model name in the base model definition.
Therefore, specifying `ir.actions.server`, `ir.actions.act_window`
& so on as type is useless (and adds noise since it's the same as
the action model).
closesodoo/odoo#114539
Related: odoo/enterprise#37855
Signed-off-by: Julien Castiaux (juc) <juc@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>
*: 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>
*: 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>
*: 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>
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
in v14 `_render()` on `ir.ui.view` returned `str`. In v15 it returns
`Markup` instead. This inadvertently changed the behavior of
`_do_request()`. The rendered view stored in `xml_transaction` is
added to the request as the SOAP body and is supposed to be
escaped. This is done by `html_escape(xml_transaction)` but since
`xml_transaction` is already `Markup` it won't escape. On top of that
concatenating the `soap_header` and `soap_footer` `str`s causes them
to be escaped when they shouldn't be.
This commit changes `xml_transaction` to be a single `Markup()` that
inserts the escaped view and password inside of
`<mer:CreditTransaction>`. This has the added benefit of solving an
issue when the password includes a character with a special meaning,
although I'm not aware of a real case where this happened.
opw-2919085
closesodoo/odoo#98759
X-original-commit: 8e51b1df76f35a7c01e5f86920c84b2c1c976d9b
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Masereel Pierre <pim@odoo.com>
This commit aims at removing unuseful help message to:
1/ reduce translators work, to focus on more useful translations
2/ not sending unuseful information in load_views
3/ reduce help message to useful messages, so that we can mark
fields having a tooltip in the future UI.
4/ some cleanup of existing messages too
The main use cases:
- REMOVED: help redundant with the field name, providing no extra info
- MOVED TO COMMENT: technical help messages, that should not be in UX
closesodoo/odoo#97279
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
The "pressing a specific key to confirm/cancel a popup" behavior was added but the problem was that
some popups only had one button which was either confirm or cancel. It was thus possible to close
those popups by bypassing the default behavior (e.g. possible to "cancel" a popup which only
has one button linked to an overridden confirm method and vice-versa). Also, we normalize the use of
`confirm` and `cancel` methods in the popups so that when the specifics keys are pressed, the right
behavior is executed.
closesodoo/odoo#97069
X-original-commit: a14ade59744855a9dea8b16f23a3d61eb88678de
Related: odoo/enterprise#29957
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Without this the payment line amount is overridden before the request
is made to Mercury.
When a Mercury payment method is clicked a payment line with the right
amount is created. When a card is swiped it types a sequence like:
%B999000090000009^TEST...
The "typed" numbers are immediately interpreted by NumberBuffer and
will result in the payment line amount being updated to something like
9990000.... When the "barcode" is finished credit_code_transaction()
in pos_mercury will do the request using the amount from the
payment line (swipe_pending_line.get_amount()).
As a result a request is made to Mercury with a huge amount which
results in an error: "Error 1000211: Invalid Field - Purchase Amount".
Luckily NumberBuffer already supports barcodes, so the problem can be
solved by setting useWithBarcode. A small method was extracted to
override this cleanly.
opw-2892608
closesodoo/odoo#96392
X-original-commit: 49df357a3b897bc06aa5978c4b77c4cfda29070c
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Masereel Pierre <pim@odoo.com>
As werkzeug.utils.unescape is deprecated in werkzeug 2.0 and the
markupsafe version of unescape just uses the built-in html.unescape [0],
we can use directly the same built-in method.
[0] pallets/markupsafe@c35603a903
Part-of: odoo/odoo#91927
Remove most values uselessly specified because giving the same value as
the default one (see _DEFAULT_MANIFEST in odoo/modules/module.py)
* auto_install is Falsy by default
* author is Odoo SA by default
* summary & description are empty strings by default
* application is False by default
* test, demo, depends and data are empty lists by default
This will reduce noise/inconsistencies between manifests specifications,
simplify analysis of manifests content, ...
closesodoo/odoo#90209
Related: odoo/enterprise#26807
Signed-off-by: Victor Feyens (vfe) <vfe@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>
There were inconsistencies in the calls to `_render`.
* the view context could contain information that misled developers.
Indeed, the context and value of the view are not supposed to be found
in the rendering. Thus by calling `ir.qweb` with the name of the
template, we ensure that there is no unwanted information and in
addition the cache key is that of the name of the template which saves
a query.
* the context used for rendering was modified by a method on
`ir.ui.view`, except this is not information used by this model. There
is now a `_prepare_environment` method residing on `ir.qweb`. This
method allows to modify the value dictionary as well as the context in
which the rendering will be done. This preparation of the data as well
as my security check is done only once per rendering. This also saves
some queries
* Freeze options for rendering were inconsistent. It could be that
options on which rendering depends were not part of the cache key. Thus,
depending on the user who generated the generation of the rendering
function, there was or was not information in the template. For example
for automatic branding. This is no longer possible, because it is the
context that is used. The options serving as a cache key are only
recorded for information (for the profiling system for example). A
simplification of the `ir.qweb.field` models could be made.
The report rendering and call `ir.qweb` instead of `ir.ui.view`.
Part-of: odoo/odoo#85110
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>
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>
In order to limit encoding decoding, the _render method returns a
unicode string in the markup safe object instead of a MarkupSafeBytes
closesodoo/odoo#68299
Related: odoo/upgrade#2454
Related: odoo/enterprise#17270
Signed-off-by: Antony Lesuisse (al) <al@openerp.com>
Pierre Pulinckx (pipu)