Steps to reproduce:
(Activate Project, Timesheets, Sales, and Inventory)
- connect with portal
- open Projects
- try to open project "AGR - S00021 - Sales Order"
Issue:
Access Error
Cause:
We want to access to the field "is_gs1_nomenclature" for which Portal has no access.
Note:
On the main Runbot (all apps) it does work because the subcontractin_portal adds the Barcode Nomenclature access to Portal user
opw-3073064
closesodoo/odoo#106493
X-original-commit: e0fec5af209229546061c70509c834bb28dd1336
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
'Barcode GS1 Parser' test sent RPC to the server (moreover
it was wrong rpc). Fix it.
closesodoo/odoo#102239
Signed-off-by: Steve Van Essche <svs@odoo.com>
Let's say the company use a GS1 nomenclature and a user scans such a
barcode:
`(01)11111111111113(10)xyz(30)40`
It means a product P:
- that has the barcode value '11111111111113'
- for the lot 'xyz'
- with a quantity equal to 40
The GS1 nomenclature explains that a lot consists of a prefix `10` and
of up to 20 alphanumeric characters. In the above example, we could
believe that the lot is actually `xyz3040`. To prevent this kind of
issue, the GS1 standards use a special character: the Group Separator
(its hex value is `\x1d` and does not have any visual representation).
So, when reading the barcode of the above value, the barcode reader will
detect the GS between `z` and `3` (so we know that this is the end of
the lot name).
Because GS has no visual representation, the way the GS character is
given by the scanner to the device depends on the scanner itself. For
instance, some barcode readers try to encode GS thanks to its unicode
input (as used on a Windows device): it enters Alt+0+2+9 (i.e., the
unicode value of GS). This is an issue since we filter out all keydown
events with the `Alt` key pressed.
Also, our way to interpret the barcode value depends on the device: on a
desktop device, we listen the events. As explained above, this could be
an issue (for instance with Alt+029). On a mobile device, we let the
barcode reader write in an hidden input and we then extract the written
value. There is also an issue here: the GS is not present in the
extracted string.
For these reasons, some changes are need. The idea is to let the user
lists the ways his barcode readers will encode the GS character (the
scanners often give the possibility to set a value manually.). There is
already a field for this:
https://github.com/odoo/odoo/blob/320025ee630acadd4a5cbd32f425cddee4f81c1e/addons/barcodes_gs1_nomenclature/models/barcode_nomenclature.py#L18-L20
However, this is not correctly working. Suppose we now stop to filter
out the `Alt` keys: in the above example, the scanned value becomes
`011111111111111310xyzAlt0293040`(as you can see, there is an `Alt029`
at the end of the lot). Suppose also that we defined
`gs1_separator_fnc1` with `Alt029`. When parsing the barcode value, we
have:
https://github.com/odoo/odoo/blob/1c0dec6d5813fa81a0fec8668ee13d8036cde5c5/addons/barcodes_gs1_nomenclature/static/src/js/barcode_parser.js#L91-L98
So, when we try to extract the lot name, the values will be:
- barcode: `10xyzAlt0293040`
- regex: `^(10)([!\"%-/0-9:-?A-Z_a-z]{0,20})(?:(Alt029))?`
And here is the issue: `Alt029` will be caught by the second capturing
group of the regex (instead of the third one), so it will be considered
as part of the lot name, we still have an issue => considering the
`Alt`/`Control` keys and defining some values in `gs1_separator_fnc1`
are not enough, we need to parse twice:
- The first parsing is used to convert all occurrences of
`gs1_separator_fnc1` into the hex `\x1d`. Then, it is also used to
remove all useless `Alt`/`Control`/`Shift`.
- The second parsing is the already-existing one and this parser is
already able to catch all `\x1d` as group separators:
https://github.com/odoo/odoo/blob/1c0dec6d5813fa81a0fec8668ee13d8036cde5c5/addons/barcodes_gs1_nomenclature/static/src/js/barcode_parser.js#L90
For the mobile device, it means that the users will have to define a
special character that stands for GS (e.g., `#`), so we will retrieve it
in the input.
OPW-2930873
closesodoo/odoo#99730
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Before this commit, search for product without barcode while GS1
nomenclature is enable causes a traceback.
To reproduce:
- Install `stock_barcode` and enable GS1 nomenclature;
- Make a search for `product.product` with following domain:
[('barcode', '=', False)]
While triyng to parse barcode, it will encounter an error because it
will try to decompose the barcode (as a GS1 barcode can have multiple
data) and to know if there is something to process, it will check the
barcode length.
As the barcode is `False` in this case, there is no length.
closesodoo/odoo#91807
Related: odoo/enterprise#27547
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
To reproduce the issue:
(Need stock_barcode)
1. Create a product:
- Barcode: 1234567890123
2. Print the label
3. Try to scan the barcode and check the value read.
Error: The value is 1234567890128, the last digit is incorrect (8
instead of 3)
When printing a barcode, we use the library 'report-lab' to generate a
barcode image from a value and a barcode type. In case of EAN-13, if the
value contains a non-digit character, it will raise an error. We then
catch the error and retry to generate the barcode according to the
barcode type Code128:
https://github.com/odoo/odoo/blob/87698d90f02bfe93c6e643f4876a5ccd74788eff/odoo/addons/base/models/ir_actions_report.py#L569-L575
However, if the value contains only digits, the method will use the 12
first digits:
https://github.com/mattjmorrison/ReportLab/blob/dade0f303cb6fcdbe535c4cc92e6102c2417b699/src/reportlab/graphics/barcode/eanbc.py#L187-L188
and will then add the last one, the check digit, which is computed by
the library. This explains why, in the above use case, the barcode value
returned by the scanner is not the same than the expected one.
Note: Similar behavior with type EAN-8
OPW-2902150
closesodoo/odoo#97052
X-original-commit: a2c7470f8fd46b2520f7b8f0750c63216273ce96
Related: odoo/enterprise#30160
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
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>
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
Some already exist, but let's add m^3 and ft^3 as well for demo data
purposes since office furniture supply stores are more likely to work
with these volumes than the existing ones.
Task: 2623434
ENT PR: odoo/enterprise#21179
X-original-commit: baecc0d502b111a5652e0a2d6ce29bd0fb204843
Part-of: odoo/odoo#77597
See 15f2bbd40a70d9d9
Do not want to force installing freezegun on production databases
closesodoo/odoo#76453
X-original-commit: 104abf024c16198999a832d4ce7f56b3b988612f
Related: odoo/enterprise#20827
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Two changes:
- The `barcode_rule_gs1_16` was renamed `barcode_rule_gs1_17` (and its
AI was changed too) as the AI 16 is about the sale by date, not the
expiration date;
- The `qty_done` rule type was changed for `quantity` as `qty_done`
refers to the move field, but the rule isn't only about this field as
it could be used by other model like `stock.quant`.
closesodoo/odoo#75699
Related: odoo/enterprise#20482
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
For `stock`, adds package type demo data (pallet and box).
For `barcodes_gs1_nomenclature`, adds a custom rule (AI 91) to recognize
the package type in the Barcode Application.
As there is no standard GS1 nomenclature's rule for the package as
defined by Odoo and there is a bunch of free-to-use AI (from 91 to 99),
using one of them for the package type could be useful to be able to
scan a new package and create it on the fly with the wanted type.
task-2627002
Part-of: odoo/odoo#75699
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>
In order to integrate and use GS1 nomenclature into `stock_barcode`,
adds a new module with GS1 nomenclature and rules, and overrides parsing
methods.
task-1968113
closesodoo/odoo#65858
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Co-authored-by: ryv-odoo<ryv@odoo.com>
Yolann Sabaux