When printing a done MO with a non-tracked finished product that doesn't
have a product barcode, an invalid zpl file is created (i.e. there is
no end to the label in this case). Instead of an invalid label, we now
write "No barcode available" to have a valid ZPL and to match what
happens in the PDF version of this label.
Part of task: 2494740
Part-of: odoo/odoo#82389
Previously the PDF product labels were not printing to any standard
label size/format. This commit makes it so they match the 4x12 format
(same used by Product Labels). Because of the dynamic number of labels
that may be printed (i.e. units have 1 label printed per 1 unit), this
template is much more complicated than previous template. Note that we
expect these labels to ALWAYS print in a 4x12 format (i.e. we keep all
logic contained within 1 template to avoid custom report/wizard python
code).
Also, this commit removes the logic for printing labels for products of
not 'Done' MOs since this didn't seem to be a possible situation (report
appears to always print blank in this case).
Part of task: 2494740
Part-of: odoo/odoo#82389
When a product has a valid EAN barcode, we would like to include the qty
of the product + its uom in its GS1 datamatrix (dm). There are a lot of
hardcoded values in report in order to fit GS1 standard:
- GS1 UoM codes are ALWAYS 3 digits (to indicate which UoM) + 1 digit
(to indicate number of digits) EXCEPT for Units UoM. Because we cannot
update a dict in QWeb, we check for both whether it's a supported GS1
UoM or a Unit separately rather than 1 general check.
- We hardcode the GS1 units value as '30' in this case (there are 2
options) because the code is specific to qty of a product (not qty of
product within a SSCC GS1 dm, there is a different value for that).
There are some limitations to this implementation due to
incompatibilities between Odoo + GS1, specifically:
- some Odoo UoMs are not included as GS1 UoMs => won't be included in dm
- # of Odoo quantity digits can exceed the number of digits allowed in
GS1 (8 digits for Units, 6 digits for all other UoMs, including
decimal values from rounding precision, e.g. 1 cm with rounding
precision 0.000001 has 7 digits as 1.000000) => won't be included in
dm in this case
- Odoo treats "fl oz" (Volume) and "oz" (Weight) as separate UoMs but
GS1 does not => we only handle weight for now
- Odoo supports non-integer values for Unit UoM but GS1 does not => we
round quantity to an integer value.
Note that implementation includes flexibility for users so they can
add/remove UoMs from the GS1 nomenclature rules as wanted/needed. This
includes user created custom codes (e.g. 90, 92-99 + extra character -
code isn't required to start with these numbers, but it won't be GS1
compliant) to handle UoMs not included in GS1 specifications as long as
they are correctly configured as quantities if user wants to be able to
rescan quantities back in with barcode app and match the 6 digits or
less quantitiy requirement when printing.
Part of Task: 2494740
Related ENT PR: odoo/enterprise#23323
Part-of: odoo/odoo#82389
When a package name is a valid SSCC number, we prefer to auto-print the
datamatrix to be used by shippers, which includes:
- the SSCC number
- the pack date (i.e. when it was put in pack)
- the weight of the package (only when less or equal to 6 digits)
Pack date field was added to accomodate this and defaults to when
package is created (e.g. when buying packaged meat at the supermarket,
it's assumed the pack date is when the package of meat was created).
SSCC datamatrix will auto-print now in 3 package reports:
- Package with contents
- Package Barcode (PDF)
- Package Barcode (ZPL)
Note if ability to create datamatrix appears to not work (only in PDF
versions) then standard 1D barcode will be used.
Part of Task: 2494740
Related ENT PR: odoo/enterprise#23323
Upgrade PR: odoo/upgrade#3202
Part-of: odoo/odoo#82389
This commit adds a new print menu option for pickings so users no longer
have to click on picking form > Packages smartbutton > switch to list >
select all packages > Print "Package Barcode with Content" to have the
same result.
Part of Task: 2494740
Related ENT PR: odoo/enterprise#23323
Part-of: odoo/odoo#82389
When printing Lot/SNs barcodes, it's sometimes desired that we print a
GS1 compliant datamatrix with the following info (when applicable):
Product barcode,
Lot/SN barcode,
Best By Date,
Expiration Date
For flexibility, a setting has been added for when the GS1 datamatrix
should print instead of 1D barcode.
Note that datamatrix will automatically exclude invalid product barcodes
(i.e. non-EAN compliant) and datamatrix size can vary based on amount
of data in datamatrix (so size has been set to accomodate expected
largest gs1 compliant datamatrix possible).
If it appears that datamatrix cannot be created, then default to
standard 1D barcode. Note that zpl printer has built in datamatrix
creation command, so we can always assume they will print correctly.
Part of Task: 2494740
Part-of: odoo/odoo#82389
When a product's barcode is EAN compliant (i.e. EAN-8, EAN-13, GTIN-14})
and feature to create DataMatrix is fully installed then we would like
to print its GS1 datamatrix on the package content report.
Additionally, if the product is tracked, we would like to include its
SN/Lot if assigned one + any "use by"/"expiration date" to make the
overall usefulness of the report go up.
Part of Task: 2494740
Part-of: odoo/odoo#82389
Two updates:
1. Match the ZPL layout, i.e. remove text centering / horizonal lines.
2. Make layout match 4x12 format (same used by Product Labels). Note
that unlike the Product Labels, we expect the lot labels to ALWAYS be
printed in a 4x12 format (i.e. we keep it simple and contained within
1 template).
Task: 2494740
Part-of: odoo/odoo#82389
Adding GS1 rules for UoMs in Odoo. Also adding 'yard' UoM since it
was not already part of standard UoMs but does have a GS1 rule.
Unfortunately not all standard Odoo UoMs have a GS1 rule so we add what
we can and will probably have to figure out how to handle these
unsupported UoMs when scanning GS1 barcodes. Note that 'lbs' rule is
needed not only to read in UoM quantity, but also to read SSCC (i.e.
package w/extra info) barcodes when their package contents' info is
included in the barcode.
Small update to GS1 rules sequences as well to make it easier to add
more rules in the future without having to worry about overlapping seq
numbers.
Part of task: 2494740
Part-of: odoo/odoo#82389
reportlab package is already in use to print barcodes, but it requires
extra packages (pylibdmtx and libdmtx) to print Data Matrix barcodes.
Unfortunately the python3-pylibdmtx package is not currently in the
Ubuntu version being used by Odoo SaaS and odoo.sh => we cannot install
this package automatically. Therefore we leave both packages as optional
extra installs for users since pylibdmtx is available via pip3 and
additional libdmtx package can be installed at that time (libdmtx0b on
linux, other OS info in pylibdmtx pip page).
We default to Code128 to avoid blocking stacktrace in case
Reportlab cannot print Data Matrices.
Part of task: 2494740
Part-of: odoo/odoo#82389
The current behavior is that we are exporting the line subtotal as
chargeAmount of the line.
This is an issue as this field is expecting the unit price instead.
A bugfix was done for importing extern invoices properly that broke
importing factur-x files from Odoo as it doesn't support that custom
behavior anymore.
Thus, this will correct the export to properly store the unit price
in the GrossPriceProductTradePrice ChargeAmount.
At the same time, add the NetPriceProductTradePrice ChargeAmount,
which is required and should contain the unit price with discount
applied.
closesodoo/odoo#83647
X-original-commit: c93f7dba0720e5e4f7d0a26ce05a854094e6a279
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Florian Gilbert <flg@odoo.com>
Signed-off-by: Nicolas Viseur <vin@odoo.com>
Steps to reproduce:
- go to inventory report
- remove the "Product > Location" Group by filter.
Problem:
The buttons “Inventory at Date” and “Create” are like merged together because there is no margin right
opw-2721995
closesodoo/odoo#83453
X-original-commit: a33e04df672658c8306a1052b1db79f233f8c54c
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Italians do not always mention the country code in the VAT
number of the partner, but we can suppose in that case that
it is within Italy. Instead of IT0477472701, they would put
just 0477472701.
closesodoo/odoo#83324
X-original-commit: 91b4168b5481d57e6af6e0c64895e97e47303ae8
Signed-off-by: Cedric Snauwaert <csn@odoo.com>
Signed-off-by: Josse Colpaert <jco@odoo.com>
Issue:
Padding impacting all reports since css file imported in common
report assets.
Solution:
part revert of commit: https://github.com/odoo/odoo/commit/69a1289eca79272efe7e53f8b3ad70de6df3d96a
use .swissqr_title and .swissqr_content selectors for most of the CSS
instead of body.l10n_ch_qr that will not work for installation of l10n_ch
that happened with fix 69a1289eca (8 september 2021 up to this fix).
opw-2686597
closesodoo/odoo#83283
X-original-commit: 71ae792d63b57627cc15eadc1e63a7b7a7dfbe70
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
Steps to reproduce:
- install only sale_project
- go to Project > Configuration > Projects
-> Warning in the JS console
Cause: sale_order_many2one widget is added by sale_expense which is not
a dependency of sale_project, so we should not use the widget in
sale_project.
OPW-2717655
closesodoo/odoo#83593
X-original-commit: d5f62067685503b6698d6b876a842512834027bf
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: yosa-odoo <yosa@odoo.com>
Steps :
- Attendances > Kiosk Mode
- Log in or out several times
Issue :
- Interface slows down
Cause :
- When a kiosk is destroyed, poll is started
- Yet each time a kiosk is started, the old kiosk is destroyed, which starts a new poll.
Fix :
- Given that the kiosk mode can't be escaped from the interface,
it is not necessary to restart polling when destroying.
opw-2735324
closesodoo/odoo#83517
X-original-commit: b3e9b4b17a4b444372fe24f07ad3c947fba540fb
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Whenever a user is modified, if at least one of a predefinet-field list
is being touched (e.g. companies or groups), cache is automatically
invalidated. However, that field list is harcoded, which prevents it
from being inherited and extended.
This commit moves such fields to a separate method, which makes
possible to inherit such method and extend the list.
closesodoo/odoo#79986
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Followup of #82838 and #82844
By default, every subclass of BaseModel is registered in a mapping for
the automatic discovery of model classes by registries. Prevent
registration of the mockup class used for rendering the database manager
templates.
closesodoo/odoo#83626
X-original-commit: 3bce74b20f8c15befee453382e3ab4697bee6960
Signed-off-by: Raphael Collet <rco@odoo.com>
Set fec_data to attachment True to avoid storing data in DB and generating memory alloc errors.
closesodoo/odoo#83620
Task: 2453453
X-original-commit: e2d4a6bd03361188f7454015574896b52aa797ef
Signed-off-by: William André (wan) <wan@odoo.com>
Due to some changes in the ORM, the previous implementation doesn't allow the override of a method to be called.
closesodoo/odoo#83595
X-original-commit: b1af44bad3a87a92f8726ed69eadffdbe4ac7c0b
Signed-off-by: Masereel Pierre <pim@odoo.com>
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Before this commit, the call participant cards in the sidebar of the
call viewer didn't respect the 16:9 aspect ratio on some browsers like
chrome. This commit fixes the issue.
task-2738622
closesodoo/odoo#83406
X-original-commit: 1f9ea3a1ef3832ed339337063f321c1bc2eacaf3
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
When start_nextworkorder, if the WO is already cancelled, we
should try to check next one the this WO.
Task-2678388
closesodoo/odoo#83566
X-original-commit: 30fcfcc6c6ebb6fe9620d29475e1a7b6f1a46923
Related: odoo/enterprise#23819
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Yuchen Huang (yhu) <yhu@odoo.com>
When the assets are regenerated, the previous attachments are deleted.
This may happen during the execution of t-call-assets directives in a
qweb view.
However, some properties that have been accessed with a sudo() were
accessible in the cache. Clearing the cache during the view rendering
could lead to access errors, which wouldn't be present without this
directive.
This commit works around this problem by removing these attachments with
a SQL query, without relying on the classic unlink, so that the cache is
preserved in this case.
By the way, sanitize the filename when marking it for deletion.
closesodoo/odoo#83570
X-original-commit: 627d508edfb62449067a05b0e3c1a0004f0af32c
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Olivier Dony <odo@odoo.com>
Signed-off-by: Paul Morelle <pmo@odoo.com>
Properly define relational fields as owner/owning/content.
For instance, with viewing attachment in a dialog, the modelling
looked roughly like this before the commit:
```
attachment_viewer -----> dialog
```
- where attachment viewer owns dialog
This commit changes it to:
```
attachment (image/card) ------> dialog -------> attachment_viewer
```
- where attachment (image/card) owns the dialog, and dialog has
attachment viewer as content
These changes should make modelling of dialog feels more natural.
Task-2738648
closesodoo/odoo#83519
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
The possible index names have been renamed "btree", "btree_not_null"
(instead of "not null") and "trigram" (instead of "gin").
Task 2742526
Part-of: odoo/odoo#83274
Issue
-----
Via the field prefetch mechanism, when we need a value of one field
(not in cache of course), the ORM will prefetch all fields
(which has the attribute to `prefetch=True`, the default value of this
attribute is `True`) for all record ids in `_prefetch_ids`.
Then, for each translate fields (where translate is not a callable)
the ORM need to make a `LEFT JOIN` on the `ir_translation` to fetch the
translated value. For big model, it leads to a simple `SELECT` with
several `LEFT JOIN` on ir_translation but each LEFT JOIN have a cost
in the planner time (a small cost in the execution time) of PostgreSQL.
By example, for `product.template` (stock/sale/purchase installed),
there are 6 LEFT JOIN to get all translated fields (5 of this
fields are rarely used).
Proposed solution
-----------------
Deactivate the prefetch by default for all translate fields expect if
this field is the `_rec_name` of the model (which is more likely to
be used).
In the example on the `product.template`:
Without prefetching the translated fields, there is only one LEFT JOIN
(the name, which is translated but is the `_rec_name` of the model).
With the 6 translated fields to fetch, the
query takes 5 ms to plan and 2 ms to execute VS with 1 translate field,
it 1 ms to plan and 1.5 ms to execute.
Side change note
----------------
- All translate of fields of `website.seo.metadata` should be prefetch
to avoid lot of website errors (it is because, website put in cache data
in sudo before reading it without sudo)
- `description` (`mail.message.subtype`), `subject` (`mail.template`),
`body_html` (`mail.template`) should be prefetch to avoid lot of extra
query from mail module.
- `vat_label` (`res.country`) should be prefetch to avoid a extra query
for each website page.
- Increase some queryCount (when it is legit, due to `subtitle` of
`blog_post` or `description` of `event.type.ticket`, etc)
task-2738029
closesodoo/odoo#82896
Signed-off-by: Raphael Collet <rco@odoo.com>
In debug mode, when a company ir.rule raise a exception
for one or multiple records, a feedback message is
display with limited records information.
Add company name to these information to help the user to change
his current company to the correct one directly.
task-2628865
Part-of: odoo/odoo#79073
Currently, product.name_get goes through
each product in the record set
before calling _get_combination_name
on its attribute values.
This can lead to some slowdowns when the recordset
starts to grow (> 100 products). The reason for
that is that _get_combination_name
filters the recordset twice.
This commit speed-up _get_combination_name
by "resetting" prefetch_ids to self._prefetch_ids,
i.e. the prefetch_ids of the whole recordset.
opw-2624261
closesodoo/odoo#83563
X-original-commit: 2065c53a6e0c3f1c363f5b2bea401782a1f4b31b
Signed-off-by: Raphael Collet <rco@odoo.com>
Before this commit, you had to click on a "validate" button to
validate the modification/creation of a ribbon. Now this is done
automatically with every modification while editing.
task-2501515
closesodoo/odoo#74206
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, changing the model on an existing xml-id may lead to
strange results.
create any record in xml, ie: id=my_xid, model=new_model
=> Odoo will create a new external_id, pointing to (new_model, id=1)
change only the model in the xml, ie: id=my_xid, model=ir.cron
=> Odoo will use the id of the existing external_id with the new model
and points now to (ir.cron, id=1)
AND REPLACE the ir.cron id=1 (autovacuum_job) with the data of the xml.
This commit simply prevent that by raising when trying to recycle the
same xmlid for another model. An explicit upgrade script to remove the
existing xmlid and corresponding records should be write.
closesodoo/odoo#83422
Signed-off-by: Raphael Collet <rco@odoo.com>
Steps to reproduce the bug:
- Have company A and B
- Create a pricelist A with company A and pricelist B with company B
- Select company A as current company and B as allowed company
- Create contact A without linked company
Problem:
You can select pricelist B while the current company is A, this causes an access error if you save and only select company A in the selector.
It also causes an error when you open a new POS session.
This contact is not linked to a company, so it should be accessible from all companies.
Solution:
Add a domain to allow the user to only select the pricelist linked to the current company or a pricelist that are not linked to a company
opw-2745267
closesodoo/odoo#83537
X-original-commit: 9f79c62fa56a1bb92ea3fc79fd82431bf9041d5c
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Step to reproduce:
- Go to ‘my profile’
- Action "assigned tasks"
- Create task
Current Behaviour:
- Traceback because default assignee is not correclty set up
Behaviour after PR:
- Correct default assignee
- No traceback
opw-2742199
closesodoo/odoo#83539
X-original-commit: a80bb0c0312e07d233d01f9196ee040e07cffc83
Signed-off-by: Laurent Stukkens (ltu) <ltu@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>
Since [1] when web's owl services were made available to the frontend,
the navigation mixin does conflict with the hotkey service.
E.g.: navigation mixin consumes the 'alt' keyup event, which prevents
the hotkey service from cleaning up the hotkey overlay.
After this commit the old mixin is neutralized and hotkeys in website's
pseudo-backend layer are handled by the general hotkey service.
Also since [2] the menu items are inside `<div>` instead of `<li>`,
adapted the scss to take this into account.
Also added a CSS rule to neutralize the outline on website's menu
dropdowns which are `<a>` instead of the already handled `<button>` in
web.
[1]: https://github.com/odoo/odoo/commit/db7b485d984e50fae5a52308634166460e5fc908
[2]: https://github.com/odoo/odoo/commit/84715436d87bb05b421bc9ccaacda67d07571690
task-2738578
closesodoo/odoo#83529
X-original-commit: 88438fa9b363530aa4e5dec5599c1568fb7ccea0
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Notification handling in some acquirers presents a subset of the
following issues:
1. The signature of synchronous notifications (redirect payloads) is not
checked. (Alipay, Authorize, Buckaroo, Mollie, PayU money, PayULatam)
2. When the signature check fails, we raise a ValidationError which
counts as an HTTP 200 for some providers (it's not the case if they
expect a specific string). (Adyen, Paypal, Sips, Stripe)
3. If a ValidationError is raised when processing the feedback data, it
is allowed to bubble up to the provider. (Alipay, Ogone)
The issues are respectively addressed as follows:
1. If the acquirer implements payments with redirection, make sure that
if either makes a request to the provider to validate the data or
that it verifies the signature. Verifying the origin of the request
is not enough: the payload must be checked too.
2. Instead of raising ValidationError's, raise an HTTP 403 FORBIDDEN
error if the signature check fails.
3. Wrap the call to `_handle_feedback_data` of the webhook method inside
a try/except clause to catch any ValidationError, log a warning, and
acknowledge the notification to avoid having the provider disable the
webhook because of too many failures.
task-2688139
task-2693293
closesodoo/odoo#81607
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Co-authored-by: Lucie Van Nieuwenhuyze <luvn@odoo.com>
Tiffany Chang (tic)