When sending the same survey to the same partner, the system detects it and
allows the user to choose between sending a new invitation or resending the
old one so that the user can continue the survey that might already be ongoing.
The detection was not working anymore and this fixes the problem.
Technical note: _compute_existing_partner_ids was intersecting record set
partner_ids (the one currently added) and a record set of partner for which an
invitation has already been sent. The intersection didn't work because
partner_ids relation was not completely set and instead of id, had "origin" id.
Comparing id using a filter solves the problem (using the trick that .ids,
return also the origin ids).
Task-3087702
closesodoo/odoo#111687
X-original-commit: fea798047118f0a482dc2421d92e73f51dd04816
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Signed-off-by: Dufays Pierre-Yves (pydu) <pydu@odoo.com>
Because of the M2M relation, an account.move.line can be linked to
several sale.order.lines, making the cardinality of sale_line_ids
superior to 1.
Even if it is not possible to obtain this result with standard code,
a custom module could create this situation and posting the invoice
would result in a "ValueError: Expected singleton" exception.
This commit prevents this exception by checking whether the line is
linked to at least one downpayment SO line in the method action_post.
The test also checks that the methods button_draft and button_cancel
behave properly (spoiler alert: they will fail too in 16.0).
closesodoo/odoo#111686
X-original-commit: a2344a4cd9283e3a74caf454ce218eecf5855de0
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Paul Morelle (pmo) <pmo@odoo.com>
model/model_terms translations:
A transifex link if available is displayed after the language in the translation
dialog to help translators to contribute their translations. The tooltip message
for mouse hovering is 'Contribute'
code translations:
Setting -> Translations -> Application Terms -> Transifex Code Translations
In order to reuse the list view and search bar, model transifex.code.translation
is created to store all code translations.
This model is
1. readonly
2. reloaded on demand/by cron(7 days) to avoid increasing the Odoo restart time
3. updated for new installed modules/languages while opening the list view
4. shared to all users without duplicated translations
closesodoo/odoo#111685
X-original-commit: 7b30badb52e2a948c41f4340a01f6118818c6711
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Wang Chong (cwg) <cwg@odoo.com>
Before, when we tried to open the Partner detail screen, we had an issue when the price list weren't loaded.
But since this commit: 40f0482b680a7872d338fa8fd10eec4663637b46
The price list are not mandatory anymore, we can get rid of the check that consisted of verifying the price list were set on the partners.
closesodoo/odoo#111665
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Steps to reproduce:
- Install Dashboard, Inventory apps
- Go to Inventory > Products
- Add a custom filter "Quantity on hand > 0.00001"
- Favorites > Add to my dashboard > Add
- Go to dashboard app
Issue:
JS Traceback is raised: `Expected "]", got "(name)"`
When executing the rpc call to `/board/add_to_dashboard`, the number
`0.00001`, which is passed as argument, is decoded as `1e-05` in the
python code and stored in the custom view.
When parsing the same view in the frontend, the tokenizer fails to
detect `1e-05` as a floating number and an error is thrown while parsing.
Solution:
Add regex for floating point numbers in scientific notation in `py.js`.
The regex accepts numbers such as:
- 1.2
- 12.
- .1
- 1e-02
- 1.2E-2
- 12.e+2
- .1E3
opw-3038707
closesodoo/odoo#111664
X-original-commit: d2d23e517fb81ab3779f6f0dbf0d035544c863d8
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Signed-off-by: Stefan-Calin Crainiciuc (stcc) <stcc@odoo.com>
After this commit was introduced: 3cad1312ca35c136440a98dc1b1c82a483bdbd3e
There was an error when using the half up method in the point of sale.
The method was always set to up or down even if the method should stay as half-up.
Now, we make sure to inverse the rounding method only if it's not a half up method.
closesodoo/odoo#111627
X-original-commit: 34dc7e24ec2ee3d853c06c2865fecdccf965ae71
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Since f0beddf534a57e972ac3a7bef6afa1caae1dcff3, the crud rights of
readonly fields is not sent to the client anymore.
In most cases, it has no impact, but for fields readonly server-side
and specified as editable in the xml, the client will consider
relational fields as always creatable and writable.
See:
* many2one_field.js where canCreate and canWrite are undefined in this
situation because the server doesn't send the crud data.
* owl library, where undefined props fallback on the default props
value, which is true for Many2OneField canCreate and canWrite.
After investigation, it has been concluded that modifying the data sent
to the client was too heavy for such a rare usecase that we don't want
to support anymore.
This commit fixes the only know case where a readonly field was supposed
to be editable client side, by converting it to a compute editable,
s.t. the server doesn't consider it as a readonly field and correctly
sends all the necessary information to the client for this field.
It also allows users to disable product templates creation & update in
the lines of a Sales Order (and makes sure that if it's enabled, you have
the creation/edit rights to see 'Create' & 'Create & Edit' dropdown choices).
opw-3144319
opw-3140988
opw-3080838
closesodoo/odoo#111546
X-original-commit: dbc56c66366dbb54384e2098c57484853a6d1daf
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Before this commit
==================
GST Treatment will not be assigned to those invoices/bills
whose partners don't have GST Treatment.
After this commit
=================
GST Treatment will be assigned to those invoices/bills whose
partners don't have GST Treatment.
closesodoo/odoo#111528
X-original-commit: de944b54715db0a0b6898fb9b049449c5ced29c9
Related: odoo/enterprise#36555
Signed-off-by: Josse Colpaert <jco@odoo.com>
This demo data was made for the purpose of GST return report but now we have
new functionality of GST return E-filing(l10n_in_reports_gstr) so moves demo
data in that module so we don't need the demo data in this module.
X-original-commit: 0981188715210c6e5a170e9a70f2bcb5a6785e04
Part-of: odoo/odoo#111528
Runbot currently doesn't use Pylint 3 in order to still have "style"
lints (since removed), however compatibility with pylint 3 is useful
to run tests / lints locally (and possibly eventually in future python
versions for which 2 might not be compatible).
Fix a few deprecation warnings:
- the `__implements__` magic thing has been deprecated
- `check_messages` has been renamed to
`only_required_for_messages` (better explains the purpose)
Also remove second parameter of `is_message_enabled` call, if
specified it's supposed to be a `Confidence` value, not a
number. Recent pylints changed the way it's checked, so it now errors
even if not using the confidence system (or something like that).
closesodoo/odoo#107960
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Before this commit, the `field_digits` options of the monetary field
has not been reimplemented since the owl conversion and so the digits
of the currency was used.
Now, when the `field_digits` option is given, the digits of the field
is used instead of the currency digits.
task 3072702
closesodoo/odoo#111308
X-original-commit: 996cc74745a2fb72547053991a79d233d6916587
Related: odoo/enterprise#36568
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The goal of this commit is to add the possibility to define a <control>
in the arch of a kanban view. This works exactly like in the list view
arch. So we can add <create> and <button> that will be present when the
arch is used by an x2m in kanban view.
As a reminder, <control> allows you to add buttons to an x2m in list or
kanban view without js customization:
<create> allows to add a button allowing the creation of a record with
a different context
<button> allows to add a button action.
closesodoo/odoo#111307
Taskid: 3143419
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
*: website_event
Since [1], it was not possible to customize the SEO values of an event
sub-page because a condition was inverted by mistake. Opening the SEO
dialog on those sub-pages actually displayed (and allowed to save) SEO
values related to the event main page.
[1]: https://github.com/odoo/odoo/commit/ac55f2bb113ecf7c774fe6e96d28e716184a97d1
Related to task-3129034
closesodoo/odoo#111289
X-original-commit: 2072a7739eb9a9ee87c8b3c7b0d43a82a7e2375f
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: website_sale
During the big "website-in-backend" refactoring, [1] and [2] were made
to add the "edit-in-backend" and publish buttons in the systray. At the
same time, the information about if the main object of the iframe is
available to "edit-in-backend" / is published was added on the loaded
iframe's html element (as was already the information about what the
main object is).
The problem is that [1] + [2] were merged around the same time as [3]
which decided to put the existing data addition on the html element...
in a t-if. [1] and [2] ended up adding the new information only if the
user is a designer, while it is actually needed as restricted editor
users. As a result: the publish and "edit-in-backend" buttons did not
appear anymore for restricted editor users.
At the same time, [3] seems wrong on its own, as it moved some
information in the conditional block although we wanted that information
to be available even for visitors (especially, the main object which is
for example used by the product snippet*). This is fixed by this
commit too.
* Steps to reproduce:
- As a restricted editor, go to /shop in the backend iframe
- Click on a category at the top
- Edit
- Add a "Products" snippet in the category-related area
- Click on it and choose "Current" as the value for the category
=> Crash. That crash actually also occurs as a visitor on page load if
such a snippet was saved by an admin first (but the crash in that case
is silent).
Note that the "seo-object" info is not needed by public users but was
restored as a public data as it was the case in 15.0. It might make
sense to some custo. However, the "oe-company-name" info, which was
public in 15.0, is kept shown for designers only as it seems to be dead
code in 16.0 (will be removed later on in master).
Unfortunately, no stable fix can really be made to solve this issue:
this commit had to modify the existing `website.layout` XML. So to solve
this issue in existing databases, you either have to patch the view
accordingly or update the website app. That should be ok, considering
that the only real problem is that some options cannot be used as a
restricted editor user.
[1]: https://github.com/odoo/odoo/commit/f260e3c1441b380d0c9f5294d7cadcaad9c90662
[2]: https://github.com/odoo/odoo/commit/028efcbffe1cbaa00fe6a262151c75fda922008d
[3]: https://github.com/odoo/odoo/commit/b0a2a41d78292cb8b9e53788d40c6dc5915a466d
task-3129034
X-original-commit: bfb6d7820c35f3eba3bb760810866350092a16d9
Part-of: odoo/odoo#111289
The page properties and optimize seo menu items were not explicitly
marked as not shown for non-designers. An unrelated bug currently hides
those items by chance... but as that bug will be solved in a further
commit of this same PR, it had now to be explicitly hidden in that case.
Note that after this a related bug remains: the "This page" title on
top of those sub menus is left visible if no sub menu is shown and
clicking on it actually crashes. That bug will be solved in another PR.
Also note that it might make sense to show the optimize seo dialog for
restricted editor users when they have the correct rights... but this
would be an improvement to consider in master.
Related to task-3129034
X-original-commit: 26c46ba70bac227c2b6a28a941e5c4f13bfe9029
Part-of: odoo/odoo#111289
Before 16.0 and the website-in-backend refactoring made at [1], the
publish button of the frontend had this behavior:
- The record is unpublished
- Click on the publish button -> a rpc to publish is sent but the
switch visual state is not updated (the internal checkbox is still
unchecked)
- The rpc comes back with the response -> the switch visual state is
updated (red -> green)
This is actually the behavior since the bug fix made at [2]. The main
point of this commit was to prevent toggling the checkbox while its
javascript behavior was not initialized yet.
From 16.0, that loading problem is not an issue anymore, as the publish
button is instantiated client side and thus only appears when it is
possible to use. We can thus update the visual switch state as soon as
the user click on it for a better UX. However, that was flawed:
1. If the publish action actually failed, the switch was kept
checked/unchecked while it should be reverted to unchecked/checked.
2. If you clicked very fast multiple times on the button, many RPC were
sent and their result order was not guaranteed.
3. There is no possibility for tours to wait for the actual publish
action to be done... and that will be needed in a further commit of
this PR.
This commit fixes all those flaws:
1. If the RPC fails, we now revert to the status before the user clicked
on it. Inspired by [2], the internal checkbox is now disabled, which
leaves its status entirely up to OWL instead of browser behaviors.
2. The switch now stops listening to clicks while a RPC is being
performed.
3. While a RPC is being performed a "data-processing" attribute is added
to the whole switch area.
Note: in master, the whole switch system should be reviewed. The publish
button one's structure actually makes no sense: a <div> which contains a
<a> which contains a <label> (already invalid DOM), with the <div> being
the event handler of the switch status changes...
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
[2]: https://github.com/odoo/odoo/commit/2e751d80dd4b23abf374d5aa488827faaa593e62
Related to task-3129034
X-original-commit: 36a8fe44d6ec609a9bad8d960768766a44d4074e
Part-of: odoo/odoo#111289
Harmonize _get_display_price between event_sale &
event_booth_sale.
Do not rely on contextual stuff when information is
available without using contextual data.
closesodoo/odoo#110833
Related: odoo/upgrade#4256
Related: odoo/enterprise#36210
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Harmonize currency conversion of unit prices:
* Make sure no rounding is applied during the conversion
(it'll be managed by the price_unit decimal precision
and the currency rounding will only be applied by the
monetary fields later in the computations).
* consistent parameters for the conversion (date,
company, currency).
* code simplification
* consistent behavior when the SO has no currency specified
...
Part-of: odoo/odoo#110833
This commit makes the data entry of numeric fields
easier by selecting all the content of the input on focus.
task 3132899
closesodoo/odoo#110181
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit hides name of user from many2many avatar user of
activity view similar as kanban view so it'll display many2many
tags properly in activity view.
task-3132890
closesodoo/odoo#109855
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Migration of the js code of `product_pricelist_report` to OWL.
Task - 3058360
closesodoo/odoo#105341
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Co-authored-by: Xavier (xlu-odoo) <xlu@odoo.com>
Seems unnecessary, most of the information already lives in
`sys.modules`. We can just check that.
There are a few changes in behaviour, but they seem minor:
- if post_load fails, subsequent attempts to load the module will
"succeed"
- since we didn't remove/reload the module, a failure because of an
incorrect post_load wasn't fixable, however it was possible to
update the manifest
Still seems like a wonky state to be in, and one we should ignore.
Also remove the logging of the error: since we're re-raising as-is,
the parent logs it with a traceback, so this is unnecessary and
redundant.
closesodoo/odoo#103933
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
It looks like these methods where an alternative to `has_groups`,
but not used since a while.
In Odoo 10.0, there is only one hit, in point_of_sale,
which has been replaced by `user_has_groups`
in 11.0 with revision
34c661111b
In Odoo 9.0, there are a few more hits in base,
which have been replaced by `self.env.user.has_group`
in 11.0 with revision
4ddc323139closesodoo/odoo#111622
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
This commit is a forward port from v16. It completes another commit that was
done in master only:
https://github.com/odoo/odoo/commit/7c415e972fa97ba52d8d5165fd47494965e3053d
---
Module `pos_restaurant` synchronizes orders between different POS devices. It
works by pushing order from POS to server and loading it back. This commit
assures that loyalty fields are correctly prepared before returning values to js
client. Specifically, many2one fields must be just ids [1] [2], and not `[id,
name]`. Similar cleaning is already done in `pos_restaurant` module for `product_id`
field [2].
To correctly implement this patch, empty `_prepare_order_line` is added to
`point_of_sale` module to be sure that extension of that method in `pos_loyalty`
is not ignored: the method in `pos_restaurant` didn't have `super` call and
`pos_loyalty` module doesn't depend on `pos_restaurant`
STEPS:
* install pos_restaurant, pos_loyalty
* prepare gift card
* open pos, create order, apply gift card
* switch to floor screen and then back to table (order) screen
[1]:
https://github.com/odoo/odoo/blob/c4b90db77705139333bdf5faf26b12fc120d1661/addons/pos_loyalty/static/src/js/Loyalty.js#L833
[2]: https://github.com/odoo/odoo/blob/c4b90db77705139333bdf5faf26b12fc120d1661/addons/pos_restaurant/models/pos_order.py#L76closesodoo/odoo#111617
X-original-commit: 0cf1fb6cf9dad69d58939d735081428a5e1650f4
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Ivan Elizaryev (iel) <iel@odoo.com>
Before this PR, recovering from an offline/online switch could
take up to 20mn. Indeed, WebSocket are based on TCP that uses
FIN packets to close the connection. In case of a sudden loss
of internet connection, the client is unaware of the already
dead TCP connection. It is up to the browser to assume the
connection is dead after some time.
This commit solves the issue by closing the connection properly
upon the reception of the offline event. When the client is back
online, the connection is opened again thus allowing an almost
instant recovery.
At the same time, this PR increases the default keep_alive_timeout
for websocket connections. Indeed, those re-connections lead to cursor
usage bursts and are not required so frequently.
closesodoo/odoo#111274
X-original-commit: d3a3792e5247cc41a58b47d148d4adf4fb0e4631
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
before this commit, the precision given for the field product_qty in mrp.bom model is Unit of Measure, which is not existing by default in Odoo decimal precisions.
after this commit, precision will be updated to default Product Unit of Measure precision
closesodoo/odoo#111115
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Before this commit, the buttons of the draft record in a
list view were disabled. Now, they are enabled and will
save (create) the record before executing the button's action.
closesodoo/odoo#110383
Task: 3132960
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This PR change generic calendar view to make it behave more like
google calendar.
These changes includes :
- Scss rules for small event(<15 minutes) so that the title is always readable.
On top of that, the top border of a darker color has been removed
for these even to allow more space.
- Event longer than 24h are now shown in the all day column independent
of their 'allday' status
- Time is now added in the event description, if the event is
shorter than 30 minutes, only the start time is displayed at the end
of the line.
If the event is longer, the start time and end time are displayed
on a new line.
task-id : 3114155
closesodoo/odoo#109736
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
This commit adds a new widget to the field registry. This button
is represented with an icon and acts as a boolean field widget.
The label is shown as a tooltip when hovered.
A test file has also been added to verify its behavior.
task #3121078closesodoo/odoo#110365
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps to reproduce (Using Chromium-based browser > v. 108):
- Install Survey module
- Open 'Feedback Form' survey
- Click on 'See Results' button
- Try to print the 'results' of 'Feedback Form'
Issues:
- Hundreds of empty pages added when printing.
- Chart not fully displayed.
Cause:
- The chartjs library add some HTML elements not displayed (inside div
with class `chartjs-size-monitor`) to handle the resizing of the
chart canvas.
One of the element has a width and height of 1000000px with an
overflow:hidden, but the overflow does not work properly when printing.
(Issue introduced in Chrome v. 108, working fine in v. 107 or on any
Firefox version)
- The chart canvas is not resized to 100% of its parent container and
therefore not fully displayed. (Not working in all Chrome and Firefox
versions)
Solution:
(in print media rule)
Add CSS :
- Set style to `display: none` on `chartjs-size-monitor` HTML element.
- Set the width and height of the chart canvas to 100%.
Remove css that set a fixed max-width on the parent element of the
chart canvas parent.
opw-3109523
closesodoo/odoo#111640
X-original-commit: a3fd499b1cd1416093d1f4348302f090b0f38554
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
Current behaviour:
You cannot set the Default Analytic Plan for projects in the settings.
Expected behaviour:
You should be able to set the default plan, like any other settings.
Steps to reproduce:
- Install Accounting, Project, (Timesheets if you want to test
project creation with an auto-created analytic account)
- Settings > Check Analytic Accounts
- Try to change the Default Plan in Settings > Project
- Upon saving, the change is lost
Reason for the problem:
The `analytic_plan_id` in the project's `res.config.settings` is
related to the same field on the `res.company` model.
The `analytic_plan_id` that is set on the company upon installing the
project module is a non-stored computed field, which makes a call to a
`_get_default` -> the field cannot be set. It will always return
the first default plan in the sequence.
Fix:
Since the field isn't stored (which would have worked if it was),
we use `ir.config_parameter` to write and read to it, per company.
In master we should just add a `store=True` and write a migration
for it?
Affected versions:
- 16.0
- saas-16.1
- master
opw-3127638
closesodoo/odoo#111635
X-original-commit: 11b0e2556ce824048bb4c760893b05e98537d171
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Some people create a lot of references but don't use them in their
stock. To avoid a big computation time to know the quantities for
each product in each location, we only compute it for product having
`stock.move`
For a database with 60 000 `product.product` and 6 replenish locations
but with 100 `stock.move` it goes from 50s to 0.5s
opw-3144094
closesodoo/odoo#111628
X-original-commit: 95ddf47a1ca105d9de8fec01c69fbe53b720bfe2
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Problem:
It is possible for an `account.bank.statement.line` to have in the
database the field `amount` set to `NULL`. It happens when importing
from the 'bank statement line' list view (Favorites>Import Records), a
csv file that have no column 'amount'.
This causes an issue for the queries accesing that value, as they expect
a number and get a Nonetype (for example in the function
`_compute_running_balance`).
Solution:
As this is stable, we cannot change the attributes of the field.
So here, in the `create` function, we set the amount to 0 if
it is not specified. Like when you create a bank statement line with the
'create' button, where this field is set to 0 per default (client side).
opw-3161652
closesodoo/odoo#111585
X-original-commit: 37b271e777576fbaed6e718bb7cd1c064fdb9a54
Signed-off-by: Laurent Smet <las@odoo.com>
To reproduce the issue:
1. On [Settings]>[Users & Companies]>[Users] add a user with:
- admin rights to purchase and accounting, user right to inventory
- admin rights to all three
2. Go to [Purchase], create a RFQ and click Create Bill
3. On the top right corner left of Receipt, Vendor Bills will be shown
4. It is only viewed by user with admin rights to all three apps
Request: Allow Inventory users to view vendor bills as in pre-versions
Applicable versions: 16.0 up to master
opw-3135682
closesodoo/odoo#111564
X-original-commit: bee4d91d030e305ba8c44704a38c4fd8d614997b
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: Lee, Hansun (hale) <hale@odoo.com>
When resetting the editor, we need to remove the focus listener if one
was previously added. Otherwise, the editor will try to connect too
much for each resetEditor call.
task-3164032
closesodoo/odoo#111541
X-original-commit: ed73015ee8dc53692026d3bc040ece4226e2c117
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
By making the search_read inside 'get_table_draft_orders' non-hardcoded,
its domain can now be modified by inheriting
_get_domain_from_draft_orders from other modules.
closesodoo/odoo#111609
X-original-commit: 64156e5ed6a9825bdbe2277783f250b471636004
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
When confirming a MO for a SN-tracked product with
at least one SN-tracked component, most of the time
is taken by _update_reserved_quantity and _apply_putaway_rule.
Since a component is tracked by serial number, there will
be one move_line with product_uom_qty = 1.0 and one reserved_quant
with associated quant of 1.0 by serial number. When the
mrp.production.product_qty gets bigger (> 1000) this becomes
a performance bottleneck as it slows down the creation of smls
and the search for candidate move_lines in _update_reserved_quantity.
To fix that, this commit introduces a delay when creating move_lines
with sn-tracked products. Because move_lines with sn-tracked product_id
are not eligible as to-update candidates, we can create them at the end
of the method.
This speeds up the search for to-update candidates as these lines
are not written to self.move_line_ids during the for loop. This also
speeds up the creation of serial-tracked smls as it calls self.create
only once at the end.
opw-3125714
closesodoo/odoo#111608
X-original-commit: 57ac92fc4c14bf305ffd9ef98212cc80013345f5
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Current behavior:
When a user scans a badge, the user is prompted to enter his pin. If
you click on cancel on the pin window you would be sent directly in the
pos and no user would be logged in.
Steps to reproduce:
- setup any employee badge with number and PIN
- Enable Multi Employees per Session in POS settings
- Open a new session for this POS
- Scan the badge with barcode scanner
- At password screen, click cancel
- No employee is shown in the top right but the session can be used
opw-3110299
closesodoo/odoo#111513
X-original-commit: 79a32fca91538a179a0f546a552176b46134c403
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
This commit adds a new feature to the web editor of a website. A "text"
input field has been added to the link editor panel, allowing users to
edit the label of a link.
The label will only be updated when the input is changed, to prevent
loss of formatting (e.g. if one letter is bold).
However, only formatting applied to the entire selection will be kept
(e.g. if you have a "link <b>like</b> this", nothing will be in bold if
you update the label in the editor panel).
Additionally, if there is a media element (such as an image or icon)
included in the selection, the "text" input will be hidden.
task-2900529
closesodoo/odoo#99239
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Pierre-Yves Dufays