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>
The license is missing in most enterprise manifest so
the decision was taken to make it explicit in all cases.
When not defined, a warning will be triggered starting from
14.0 when falling back on the default LGPL-3.
closesodoo/odoo#74245
Related: odoo/design-themes#48
Related: odoo/enterprise#19862
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Conversion of all modules to the new manifest assets declaration.
Part of task: 2352566
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Simon Genin <ges@odoo.com>
* account, analytic, calendar, coupon, crm, crm_iap_lead_website,
delivery, digest, event, event_crm, fleet, gamification, hr,
hr_expense, hr_skills, im_livechat, lunch, mail, maintenance,
mass_mailing, membership, mrp, point_of_sale, pos_mercury, product,
purchase, purchase_requisition, sale_management, sales_team, sms,
stock, stock_landed_costs, survey, website_crm_partner_assign,
website_event_exhibitor, website_event_track, website_forum,
website_slides, base
This commit removes oe_edit_only labels and adds placeholder
on fields in form views from a lot of apps to minimize the
shift when switching mode.
task 2330101
We now allow invoicing of finalized orders in an open session in this first
iteration of order management in the pos frontend. Additionally, receipt
reprinting is also introduced. With this feature, we can now reprint the
receipt of old orders.
closesodoo/odoo#51141
Task-id: 1981354
Related: odoo/enterprise#11690
Related: odoo/upgrade#1472
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Using a few regex like
\((_\(.*%s.*)(\) % )([\w\[\]][\w .\[\]\(\)'"]*)\)
($1, $3))
Old syntax is still compatible but starts the migration to the new
syntax that catches error.
The point of sale user interface has been adapted to work on mobile
devices.
We modified the design of payment lines to look like payment methods and
stack them together in the mobile view.
When you had a cash method, the amount was not preffilled during
payment, now we always prefill the amount to keep it more simple.
closesodoo/odoo#51891
Task-id: 1887609
Related: odoo/upgrade#1334
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
The ir.autovacuum model purpose is to run several garbage collecting
operations like removing files from the filestore when no attachment
references them anymore.
The precedent strategy to register new garbage collection tasks was to
override the `power_on` method and to imperatively execute a vacuum
cleaning method on a given model. All calls were executed in a single
SQL transaction without any error handling, meaning a single fail during
any call resulted in a complete failure of the entire vacuum cleaning
chain.
We introduce a new `@autovacuum` api decorator, its purpose it to
register garbage collecting methods that will be safely executed in
their own transaction by the vacuum cleaner. In order to ensure this
new strategy is used, we deprecate `power_on` extensions.
By the way, garbage-collecting methods can be quite heavy and we don't
want users to directly call them. We now ensure they are private.
closesodoo/odoo#47842
Task: 2154079
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Olivier Dony <odo@odoo.com>
render, render_template, load, activity_schedule_with_view,
get_website_pages should all be private:
It should not be possible to render an aribtrary template only with
its name or id
Still need to render some qweb views from js so the method
render_template is kept public.
This explains why the website editor still need read access on
ir.ui.view as we want to allow any snippet to be rendered.
With this commit, Selection fields with `required=True` which are
extended via `selection_add` are given proper ondelete policies to
ensure the cleanup of records containing these extended options during
uninstall of the extending module.
This commit also cleans up leftover uninstall hooks that were being used
to handle the same set of problems prior to the ondelete mechanism being
implemented for Selection fields.
closesodoo/odoo#46325
Related: odoo/enterprise#9117
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Purpose
=======
The current kanban view is messy. It is difficult to identify which
apps are installed or not. The user can completely miss a module
that might have interested him. A search panel would make things way
more readable.
closesodoo/odoo#44401
Taskid: 2181557
Related: odoo/enterprise#8144
Related: odoo/upgrade#879
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
When a payment line is created, and then the order is reloaded, by the
synchronization feature for example, the name displayed on the payment
line is empty.
This happens because the field name is not saved on the server, so
instead of using it, we are directly taking the name of the payment
method linked to the payment line.
closesodoo/odoo#43615
X-original-commit: ae4322cd81814cf4cdc462ff9d271f83ce2870c4
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Without demo data, for the odoo-master transifex project
closesodoo/odoo#41935
X-original-commit: dab7670b73506fb3a835695ee3bd735e0c5e5c2b
Related: odoo/enterprise#7287
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
It is by default in pos_mercury that pending payments are removed before
syncing the order to the backend. However, this is not the case for the
newly introduced API for payment terminals in pos. In this commit, we
are implementing this pos_mercury feature as default for all terminal
payment methods.
closesodoo/odoo#35579
Task-id: 1984690
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
If there is a Vantiv payment line, adding terminal payment line (e.g.
Adyen) was possible because Vantiv payment line is not recognized as
electronic payment. This commit generalizes the behavior where new
paymentline is prevented if there is a pending electronic payment.
task-id: 1984690
With the introduction of pos_adyen, pending payments are not counted in
the total payments. We are now implementing the same behavior for
pos_mercury.
task-id: 1984690
table is currently the html element that is used to display the payment
lines in pos ui. Though it is simple to use table element, customizing it
is not trivial and it requires significant effort specially when we want to
make modifications in with borders.
This commit converts the payment table to be represented by divs of grids.
This gives us more granular control in customizing the payment table.
task-id: 1984690
When there is a pending payment from a terminal payment method, and we
attempt to add a vantiv payment, an error message is displayed but is
not actually raised in the code. As a result, the code continues with
the effect of highlighting the currently selected payment to be like a
pending vantiv payment. This commit fixes the described issue.
task-id: 1984690
We had a traceback when installing pos_mercury if pos_iot was not
installed because the field `iot_barcode_scanner` was not present in
the view of pos_enterprise. Furthermore, if pos_iot is installed after
pos_mercury, this label will be again overriden.
We fix this by removing the override and changing the label when
pos_mercury is not installed.
closesodoo/odoo#39646
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Some barcodes nomenclatures and rules are added in the modules that use
the barcode module. We should set them in no update to avoid loosing
modifications when the module is updated.
closesodoo/odoo#37985
X-original-commit: c4251c1c55d010e52b956817c2d4a588ee9379a9
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
The previous change was done to solve a case of duplicated xmlids in
v12. By some confusion, both xmlids were changed in separated
commits. This new commit returns the original xmlid of one and assures
to avoid more confusions by adding 'settings' to the other.
Closesodoo/odoo#36885closesodoo/odoo#37755
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
For now when you are using payment terminals in the point of sale, you
have different way to configure payment temrminals, for the IOT, you
have to select the payment terminal in the pos config, and for adyen and
ventiv you have to configure them in the payment method.
So we've modified it to always configure payment terminal on payment
mehthod, and not on the pos config anymore, with iot you'll be able to
select the specific device you want to use, even if it is not on the iot
box set on the pos config.
closesodoo/odoo#35665
Task-id: 2042382
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Main goal of this task is to create single accounting entry
(AE) when closing a pos.session instead of individual AE for
each order in the session.
This significantly minimizes the number of created journal
entries by point_of_sale which also results to faster closing
of session when there is large numbers (order of thousands)
of orders. It also eases the reconciliation of payments because
on one hand, cash payments are automatically reconciled and on
the other, other payments are combine in a receivable line
based on the payment method.
**Important points to note**
1. Two new models (pos.payment.method and pos.payment) are
introduced replacing the functionalities of account.journal
(and account.bank.statement) and
account.bank.statement.line, which served before as payment
methods and payments.
2. The creation of single AE relies on the receivable_account_id
defined in each pos.payment.method. This receivable_account_id
is supposed to be different from the account module's receivable
account, thus, a new receivable account for pos is introduced
in each localization.
3. A simple example below can illustrate this change.
Given the following orders:
+---------+----------+----------+-----+-------+-------+
| order | payments | product | qty | price | total |
+---------+----------+----------+-----+-------+-------+
| order 1 | cash | product1 | 10 | 10 | 100 |
| | | product2 | 5 | 20 | 100 |
+---------+----------+----------+-----+-------+-------+
| order 2 | bank | product2 | 7 | 20 | 140 |
| | | product3 | 1 | 30 | 30 |
+---------+----------+----------+-----+-------+-------+
| order 3 | bank | product1 | 1 | 10 | 10 |
| | | product2 | 3 | 20 | 60 |
| | | product3 | 5 | 30 | 150 |
+---------+----------+----------+-----+-------+-------+
Instead of generating 3 accounting entries, a single
accounting entry (linked to the pos.session) will be created.
This accounting entry will have the following lines:
+---------------------+---------+------------+
| account | balance | reconciled |
+---------------------+---------+------------+
| sale | -590 | - |
| pos receivable cash | 200 | yes |
| pos receivable bank | 390 | no |
+---------------------+---------+------------+
| Total balance | 0.0 | |
+---------------------+---------+------------+
Note that the cash receivable line is already reconciled
because it can assumed that the payment is already received.
The unreconciled receivable line can be reconciled manually
using the reconciliation widget.
More examples can be seen in the tests.
TASK-ID: 1862388
Receipt are now printed as JPGs so receipts need to be formatted as
classic HTML to be rendered as images by Wkhtmltoimage.
There were two versions of the receipt for an order. The one in XML,
to be printed, and the one in HTML, that was displayed in the POS.
Since both of them are now HTML, we can remove one of them.
TaskID: 1939455
Martin Trigaux