Before this commit, owl was in the linter's accepted global variables.
This allowed direct access to owl global object.
For instance, to use xml from owl, you could do :
`const { xml } = owl;`
or you could use it directly:
`owl.xml`
Now, owl is not accepted on linter's global variables anymore, so to
import xml, now you need to use a proper import:
`import { xml } from "@odoo/owl";`
task-id 3498859
closesodoo/odoo#137517
Related: odoo/enterprise#48364
Related: odoo/design-themes#709
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
This commit, adds a new python method (`web_save`) to save a record, and
optionally read-it again in one rpc call. This optimizes the current
behavior that is to save a record in one rpc, and read-it in a second
rpc.
web_save, will receive the list of IDs of the records to save (if this
list is empty it will create the records, if not, it will write on the
existing records), the list of changed fields, and the unity
specification as optional argument to read the created/modified records
(if the specification is not set, the function will return a list of IDs
of the created/modified records).
closesodoo/odoo#133021
Task-id: 3453184
Related: odoo/enterprise#46559
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
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
Before this commit:
If the barcode nomenclature uses the or `|` symbol.
The part after it would be used as a "contains" instead of a
"start with".
e.g: `123|456`
would be transformed in the JS code to `^123|456` instead of:
`^123|^456`
As such, you would have error "can't find product with barcode" if
you set such a rule and a product barcode contains the second part.
For e.g: the barcode `44445666` would match, but should not!
After this commit:
Force the second (and following if any) part to start with.
Note: in practice it is pretty rare to have `|` in the pattern, but
it is the case for a default rule in version 16, see:
https://github.com/odoo/odoo/blob/5ac58ebf983c1c02019253c0430fde3502e13e7c/addons/pos_loyalty/data/default_barcode_patterns.xml#L10
In this case, if a regular product have `044` in its product barcode,
the PoS will tell that there is no corresponding coupon instead of
adding the product.
But the issue itself still apply in version 14 in case of custom rules
opw-3356951
closesodoo/odoo#130961
X-original-commit: 103566699d3492b682219efc3614f26d2ea972e5
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Loan Sens (lse) <lse@odoo.com>
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
This commit adapts the code in addons w.r.t. the introduction of
the RelationalModel.
Main changes that were requested are:
- record datapoints no longer always have an "id" key in their
data (they still do if the id field is in the view), so we use
record.resId instead
- the new model is based on fined-grained reactivity, so several
components that previously relied on onWillUpdateProps to update
their internal state no longer worked. Typically, using the hook
"observeRecord" is the way to go now.
- specialdata are no longer handled in the model, so the components
needing specialData can use the hook "useSpecialData"
- more generally, all overrides of models (RelationalModel or
KanbanModel) needed to be reworked.
Part of task~3179751
Part-of: odoo/odoo#114024
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: FrancoisGe <fge@odoo.com>
Co-authored-by: Jorge Pinna Puissant <jpp@odoo.com>
Co-authored-by: Pierre Rousseau <pro@odoo.com>
Due to GS1, now the barcode contains a lot more than a single identifier for
an object (e.g. product, location,etc). Sometimes it contains a combination of
multiple information. It's common now to have a size greater than 32 that
we remove the parameter.
TaskID - 3150983
Part-of: odoo/odoo#116799
To reproduce the issue:
(Need `stock_barcode` and a real barcode scanner)
1. Create two products P01 and P02, each one with a barcode
2. Barcode > Operations > Receipts, Create
3. Scan P01
4. Scan P02
5. Click on the `+1` button on the line of P01
6. Scan P02
Error: Both lines are incremented. Scanning P01 should not impact the
quantity of P01
Because of step 5, the focus is still on that button when scanning
again P02 (step 6). Moreover, the scanner ends the barcode transmission
of P02 with an `enter` -> it will generate an event on the `+1` button,
which explains why the quantity of P01 is also incremented.
OPW-3232437
closesodoo/odoo#122200
X-original-commit: a5f566b57ace1d82e77f56f4c059eb595350e1cf
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
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>
*: barcodes_gs1_nomenclature,point_of_sale
In this commit, we are converting the `BarcodeParser` to js class. As a
consequence, instead of having 2 options of instantiating the parser -- via
nomenclature_id or via nomenclature -- we are removing the first option.
Instantiating the parser will now only require the built nomenclature object.
This is possible because in all the pathways where the parser is instantiated,
the web services are ready, meaning `rpc` and/or `orm` services are ready. As a
result, the consumer of the parser can just build the nomenclature object itself
by fetching the nomenclature details from the server. A helper static method
called `fetchNomenclature` is introduced in the `BarcodeParser` class to aid in
building the nomenclature object it needed.
Furthermore, the methods that return the required nomenclature and rule fields
are converted to static fields which can still be patched (check
barcodes_gs1_nomenclature in enterprise).
closesodoo/odoo#120228
Related: odoo/enterprise#40582
Signed-off-by: Samuel Degueldre <sad@odoo.com>
In this paragraph, we are trimming the string and then converting it to an int type. But there is no guarantee that value_string can be converted to int
closesodoo/odoo#119059
X-original-commit: 84fca48dfbabbaa928823d3a27621c77cc53d6dd
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
This commit converts almost all odoo module by native module.
The goal is to deprecate odoo.define in favor of native module and then
simplify boot.js by removing the regexp that finds module dependencies.
task id: 3162300
closesodoo/odoo#117305
Related: odoo/enterprise#39118
Signed-off-by: Géry Debongnie <ged@odoo.com>
They dates from < 2027 and are quite outdated. Favour the nl
translation instead.
n_BE is not on Transifex so it was not possible to correct bad
translations.
closesodoo/odoo#115845
X-original-commit: d04c8b7e484db8306d858c891a7a2b11885fdcd9
Signed-off-by: Martin Trigaux (mat) <mat@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>
According to Wiktionary, French spacing is "the archaic practice (though
still current in French) of inserting a space around colons, semicolons,
question marks, and exclamation marks". This is not standard practice in
English and most languages of the world.
The purpose of this commit is to start purging the code from this typo,
as it may reflect poorly on the software for some people.
closesodoo/odoo#114533
Related: odoo/enterprise#37853
Signed-off-by: Sébastien Theys (seb) <seb@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>
Before this commit, the field's description was stored on the
component and this component was then registered.
Now, an object describing the field is used on registration the same way
as it is done for views since https://github.com/odoo/odoo/commit/b828cfc72c587d0b73fcc5459695705640437671.
This split the component's description (props, template, ...) of
the field's description (displayName, supportedTypes, ...) and makes
it clearer.
closesodoo/odoo#112498
Task: 3171520
Related: odoo/enterprise#37105
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The goal of this commit is to convert the last legacy client actions from
/hr_attendance to owl.
Client actions:
hr_attendance_greeting_message
hr_attendance_kiosk_confirm
hr_attendance_kiosk_mode
hr_attendance_my_attendances
closesodoo/odoo#110095
Taskid: 3138068
Related: odoo/enterprise#35884
Related: odoo/upgrade#4296
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
This commit removes the legacy implementation of the form, kanban
and list views. It also removes the legacy view widget registry,
and all legacy widgets it contained. The legacy field registry
couldn't be removed yet as some fields are still used (e.g. in
client actions: FieldMany2One, FieldMany2ManyTags...), and
sometimes accessed from that registry (e.g. uom service). More
clean up will come later. Note that all tests using legacy views
have thus been removed, even though the tested feature might still
remain (e.g. FieldMany2One tests have been removed, but that field
is still there). However, those features are deprecated and
unlikely to evolve. They should be removed in the next saas, or the
one after.
Finally, this commit also removes the legacy view dialogs.
Task 3168640
Part-of: odoo/odoo#111809
This is mostly a cleaning/refactoring change.
The current API for init hooks (pre, post, uninstall) is to pass
`cr, registry`.
But the first thing which was done by most
post init and uninstall hooks was to create an env using
the cr passed
e.g.
`env = api.Environment(cr, SUPERUSER_ID, {})`
and the `registry` argument was unused in all these hooks,
completely.
By changing the API of hooks to pass `env` instead
of `cr, registry`, we gain in average two lines in every
hooks:
- the line creating the env `env = api.Environment(cr, SUPERUSER_ID, {})`
- the line importing `api` and `SUPERUSER_ID`
Therefore removing ~250 lines of repeated code lines accross odoo/odoo and
odoo/enterprise.
In addition to these lines removed,
it also ease the API of init hooks for Odoo developers,
who are used to that `env` and not so much how to create an `env`
from a cursor.
Part-of: odoo/odoo#108254
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
Before this commit, in new views, it is no longer possible to click
on buttons with barcode_trigger="..." using a barcode scanner.
Why:
New views no longer propagate all attributes to the button.
How to reproduce:
- Go to a form view with a button with barcode_trigger="doit"
- Scan "O-BTN.doit", "Enter".
Before this commit:
Nothing happens.
After this commit:
An event click is applied to the button.
closesodoo/odoo#102423
X-original-commit: b4cb2ee2662173e08f671eb736130f8332265de7
Signed-off-by: Georis François (fge) <fge@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>
The default value of max_time_between_keys_in_ms in barcode is 55 ms.
The default value of 55 ms is too low and creates an issue for RFID readers.
The default value of max_time_between_keys_in_ms is increased to 100 ms.
task-2996072
closesodoo/odoo#101331
X-original-commit: 9eda9679bd51b63bbc7b796419b3efdec4ba99bb
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: phwa-odoo <phwa@odoo.com>
On Chrome, have a field that supports autofill (you have to have set up an adress in Chrome first).
Click on that field, and apply the autofill proposition.
Before this commit, there was multiple crashes, roughly one for every handler of event `keydown`.
This was caused by the fact that the autofill feature triggers keydown events without the field `key`.
(https://bugs.chromium.org/p/chromium/issues/detail?id=581537, I could not find a better ticket).
This seems to be a bug on Chrome's side, since the spec doesn't mention that field may be unset (https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/key).
After this commit, there is no crash.
closesodoo/odoo#99348
Signed-off-by: Bruno Boi (boi) <boi@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>
In the QUnit test suite, we have cleanup code that runs after each
test to ensure that event listeners, setTimeouts... registered
during a test are removed. This is particularly useful for services,
as they do not have a "destroy" function to cleanup those handlers
they would have registered at startup. Side note: they don't
because it would only be useful for tests, as a service lives
forever in the prod environment.
Before this commit, that cleanup code didn't remove callbacks
registered with a setInterval. Moreover, we didn't remove event
handlers bound on document.body either. As a consequence, there
were memory leaks in the test suite (e.g. callbacks of the tooltip
service), and some crashes could occur if the user interacted with
the window after test completion.
closesodoo/odoo#97100
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The previous commit removes a good part of the barcode form view. The
rest of the code was only used by the barcode_handler widget. Since it
is now much simpler, we can just implement the behaviour: simply set the
value to the barcode, so onchanges can be properly called.
closesodoo/odoo#95892
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
With this commit, we simplify the way barcodes prefixed by `O-CMD.` are
handled, by simply executing a ui action whenever it happens. The code
is much simpler, instead of having to add a widget=barcode_handler in a
specific view.
Note that it changes the behaviour: now, barcodes are available
everywhere, instead of just a selection of form views. This seems more
natural, since we consider that the barcode scanner is basically some
kind of input device.
Part-of: odoo/odoo#95892
Note that more 'non printable keys' are escaped now, like 'Home'.
This seems like a bit naive solution but it avoids having to list
every key.
The only issue we might have is if a device sends the whole value in the
'key' property directly without sending sequentially several keydown events.
As a reminder, 'ctrlKey', 'metaKey', 'altKey' properties are used
because we also want to ignore keys pressed while this modifier is
active. For example, if you press CTRL+e, we want to ignore 'CTRL'
AND 'e'.
Useful references:
https://w3c.github.io/uievents/tools/key-event-viewer.html
Part-of: odoo/odoo#93387
Before this commit 'tab' was escaped because isSpecialKey was true.
This was strange because this key was defined in 'endRegexp'.
So, there were only 'enter' key who worked as a barcode end key.
Note that it wasn't a big deal if 'tab' was used because checkBarcode
was executed anyway after a timeout.
Now the barcode value is directly checked if the strind ends with
'enter' or 'tab' (by-passing this timeout).
Part-of: odoo/odoo#93387
As we now use 'inputmode=none' on the barcode field, the mobile virtual
keyboard doesn't open anymore. So, there is no need
to have to blur barcode input after receiving a value.
There is no issue to keep the focus on this field. We only did it
to close the virtual keyboard as soon as they pop up after each scan.
Part-of: odoo/odoo#93387
And remove most of barcode_events. The goal is to have a service that
can be used by components to reliably detect a barcode action. For now,
we keep barcode_events around, but the goal is to completely remove it
as soon as all the code using it is updated
Part-of: odoo/odoo#93387
No method was readily available to know if a user is `internal` (has
group `base.group_user`), which was inconsistent with other base groups.
_is_internal is now used in the codebase where it is clear that
`.has_group('base.group_user')` is called on a single record.
Part-of: odoo/odoo#85703
Jorge Pinna Puissant