Add the possibility to dynamically change the logger level of Odoo and
per IoT handler (drivers and interfaces).
This will be done through the "Handler List" page.
This will be useful to troubleshoot purposes.
In particular when it happens on a specific handler.
The level set should persist on shutdown as saved in Odoo's configuration
using the `--log-handler` parameter, see:
https://www.odoo.com/documentation/16.0/developer/reference/cli.html#cmdoption-odoo-bin-log-handler
Notes:
- When changing Odoo's level, `werkzeug` logger will change to the same
level automatically (except in `debug` on which `werkzeug` will be set
to `info`)
- `--log-level` Odoo config wasn't used as it has unintended side
effects when dynamically switching to this level
- `load_iot_handlers` was modified as otherwise the loggers `__name__`
could be wrong and inconsistent on which several logger for a handler
exists. For example: `PrinterInterface.py` and
`odoo.addons.hw_drivers.iot_handlers.interfaces.PrinterInterface`. In
this situation `_logger` can be different from one used in the class.
In addition, of that, the parent logger for the different loggers could
be different (root and Odoo generally)
opw-3493585
closesodoo/odoo#139970
X-original-commit: 931456fed24c0d7700defd7672157d8bc54c3fe5
Signed-off-by: Loan Sens (lse) <lse@odoo.com>
Steps:
- Install project app.
- Go to task view from specific project.
- Open activity view.
- Set an activity on any task.
- Click on "Schedule Activity" button.
Issue:
- User able to select all tasks instead of tasks from
that specific project as it is working for first time
user opens that view.
Cause:
- Domain of `SelectCreateDialog` became empty when
load calls from other activity view actions.
Fix:
- Pass props in load method call to have default data as
it is when calling load method.
task-3293310
closesodoo/odoo#143721
X-original-commit: fd96a43af96ef6706680a97d19a184c6e4aad6fb
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Signed-off-by: Kartik Chavda (kcv) <kcv@odoo.com>
Due a typo, sortedKeys were not always cleared when pruning the
new trees after an update. Consequently the method _getTableRows could be
called on a inexisting sub tree. Here we simply fix the typo and a test.
opw-3584675
closesodoo/odoo#143714
X-original-commit: 3fa2d6e418daa2b1fa0df3c8d1ca643fac4cbaa2
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
__Current behavior before commit:__
When searching for an **Internal Reference** of a product variant on the
website shop, the fuzzy search is likely to return a wrong result.
If the **Internal Reference** of a product template resembles the
searched term, it will take it as a fuzzy term and will not even search
for product variants internal references.
This is because the method `_basic_enumerate_words` only parses the
fields of the model considered but not the "subfields", in this case the
`product_variant_ids.default_code`.
__Description of the fix:__
Run `_search_exact` in any case and only then, if no result is found,
run a fuzzy search.
__To reproduce on runbot 15.0:__
In the website shop, search *FURN_0096*. Although there is a variant
of *Customizable Desk* that has this exact **Internal Reference**, the
search will only return *Office Chair Black* because this product
template has a **default_code** set (*FURN_0269*).
opw-3476643
closesodoo/odoo#143635
X-original-commit: 5887b4f7246dac734f192025404d65002fff6f20
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
The white color for floor background is changed to "rgb(249, 250, 251)" instead
of the original "rgb(255, 255, 255)" (pure white). This new white is used as
color of the demo "Main Floor".
Part-of: odoo/odoo#143515
Since [this other commit], the `link_tools` tour is failing because the
`_syncContent` between url and link text is not working anymore. This is
due to the ZWS that are added to the link to permit the user to select
edges of the link.
[this other commit]: https://github.com/odoo/odoo/commit/ab40f484d55e151e175ccf9d6b3ea3bf34c56b35
runbot-18747
closesodoo/odoo#143728
X-original-commit: 1afd1ca1539dc61ddb12345160bb82957efae143
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Improve the uninstallation of payment providers by allowing to
uninstall payment providers which have a payment method line on
a journal but no payment yet.
Task id #3595006closesodoo/odoo#142112
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
In case of chained stock moves, we need to consider that
a purchase order might be linked to other orders which
are already fulfilled differently on the same order line,
so we filter for those which are still relevant for propagation
or change in procure method.
closesodoo/odoo#143338
X-original-commit: 468fc94afe4e2776abb526a67cc3785d903f088a
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
The unit prices should always be positives in the Peppol Bis 3 xml,
otherwise, a validator will raise "[BR-27]-The Item net price (BT-146)
shall NOT be negative.". Add a constraint in the code to ensure this.
task-3607341
closesodoo/odoo#143648
X-original-commit: db52055f72ce5d9b1667ee89c55301756a0fabab
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Julien Van Roy (juvr) <juvr@odoo.com>
When recursing on non-stored recursive fields, modified() only considers
the records that have some value in cache. But when fields are context-
dependent, we may miss some records because we look up for cache values
in the wrong context. Instead, consider cache values in all contexts
for that matter.
closesodoo/odoo#143644
X-original-commit: f19732c199e6bb2b8bdd55808658cb82c8cd44b4
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Signed-off-by: Raphael Collet <rco@odoo.com>
The following situation happened with module industry_fsm, when trying
to delete a cancelled sales order corresponding to a task. When doing
so, the server crashes with error "Could not find all values of X to
flush them", which means that a dirty field (pending update) has lost
its value from cache.
The issue is related to recursive computed fields. Before deleting a
record, method unlink() invokes modified(), which determines all the
fields that depend on the record to be deleted, and marks them to
recompute. Those fields should be recomputed after the record is
deleted, and not before. We found out that the recursive call to
modified() made for recursive fields can force the recomputation of the
recursive field itself before the record is deleted, which causes
unlink() to crash.
The fix consists in marking the fields for recomputation at the very end
of method modified(), after all the fields to recompute have been
determined. This ensures that the processing of recursive fields always
uses the current value of the field instead of its recomputed value.
X-original-commit: 1f5293bc63ae7b06fd0df8d509dc7fafaa016a22
Part-of: odoo/odoo#143644
Since odoo/odoo@b3a2fb51bc, it is not possible to use partial
points rewards. However this commit only fixes the behavior for loyalty
cards, where it should be applied to many other program types.
closesodoo/odoo#143643
X-original-commit: 64ebec5c7db88c247f3dafbeecbd2ae2b9ee4238
Signed-off-by: Vallaeys Valentin (vava) <vava@odoo.com>
* product_configurator, comparison, stock(_wishlist)
Before this commit, the option "Prevent Sale of Zero Price Product"
would still allow some free products to be added to the cart (accessory,
optional and alternative products).
This commit makes sure no free product can be added to cart if this
option is activated.
Also, this option was conflicting with some other options and not well
handled in bridge modules. This commit improves the UX when this option
is activated.
task-2983615
closesodoo/odoo#143626
X-original-commit: 158f622f00bad7f3b24b81cfa715601f5ff7022a
Part-of: odoo/odoo#143504
Signed-off-by: Vallaeys Valentin (vava) <vava@odoo.com>
During upgrade, it try to create picking type if not exist
like pos type and everytime will create new sequence too
for that picking type. during the creation of picking type
there is python constraints that raised if
same sequence name with same company exist.
so to avoid that will check before creating new sequence
if already same company sequence exist then update the
sequence name with id using copy prefix to easily identify
as copy name.
closesodoo/odoo#143609
X-original-commit: e16c15b5306f841d8da6ec3e951aff606e377134
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Accounting > Reporting > Invoice Analysis
Open Pivot View
Collapse column group, expand by Date>Month
StopInteration traceback will raise
line: column = self._read_group_postprocess_aggregate(spec, next(column_iterator))
The error is caused by a missing interval attribute on the group by
pivot view default search.
This will make the view call `read_group` with a wrong groupby list
['invoice_date', 'invoice_date:month'], that will cause the error raise
opw-3603433
closesodoo/odoo#143595
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
Since the module loader rewrite, it now reports errors directly in the
DOM. The error alert also has the class "modal" so that in case a tour
comes accross a page with module loading errors, it will only look for
elements inside it and fail. But in the QUnit test suite, modals are
invisible by default, causing the page to be blank in those cases.
This commit adds a css rule to make sure that this error alert is shown,
and updates the code that was previously used to report these errors in
the qunit suite to instead simply check for errors reported by the
module loader.
closesodoo/odoo#143589
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Issue:
======
When we have a product as a free product reward in cart and we want to
add the same product from the shop nothing will happen and the cart
stays the same.
Steps to reproduce the issue:
=============================
- Create a loyalty program with the following options:
type: pormotions
rule: minimum quantity :1 , gran 1, minimum purchase 0, per order,
product: select anyone
reward: type : free product , quantity rewarded : 1, product : select
any other product
- Go to website and add the product from the rule to cart
- Go to cart and claim reward
- Go back to shop and add the product from the reward to cart
- Go to cart
- The cart stays the same
Issue:
======
When searching for the `line` it doesn't consider if the line is a
reward or not.
Solution:
=========
We filter the reward lines if `line_id=False`
opw-3550585
closesodoo/odoo#143581
X-original-commit: 2b97bb83b312f553d3ec1b6e96a74c744955aed6
Signed-off-by: Morgane Demesmaeker <edm@odoo.com>
Issue:
======
When we settle an order that has a product with uom not pos_groupable
and quantity isn't an integer for example 3.5 it will add 4 lines each
with quantity = 1 which is not correct.
Steps to reproduce the issue:
=============================
- Create a product with a not pos_groupable uom (kg for example)
- Create a sale order with that prouct and add a not integer quantity
- Go to pos and settle the order
- You will have 4 lines added each with quantity = 1
Origin of the issue:
====================
The quantity was hardcoded = 1
Solution:
=========
I addeed order lines equal to the integer part of quantity and one last
order line that have the rest quantity.
opw-3579225
closesodoo/odoo#143566
X-original-commit: 3db0515959861e65f05b572d4827692ed00a1925
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>
If the format set on a partner does not work for our peppol implementation, `enable_peppol` should be `False` and the checkbox should be hidden.
This commit checks invalid partners when computing `enable_peppol` on account_move_send wizard.
Since we hide the checkbox in this case, we don't need to show the peppol warning when opening send&print to such partners.
closesodoo/odoo#143565
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Aliya Tastemirova (alta) <alta@odoo.com>
Update participant status every 6 hours instead of once a day. Once a day is too slow for users and it looks like as if something went wrong.
Part-of: odoo/odoo#143565
The additional lines originating from the product configurator are
sometimes not well handled by the framework. With this additional steps
in the test, we ensure the line remains after selecting it without
editing anything, a case that was broken several times already.
closesodoo/odoo#143554
X-original-commit: ce9251badd8cc01edfb2f83fd192f7328d48e7f0
Signed-off-by: Vallaeys Valentin (vava) <vava@odoo.com>
Before this commit when you unlink a sale.order.line the field carrier_id of sale.order is set False for each delivery line.
This commit prevent also serialisation failure on ecommerce.
closesodoo/odoo#143533
X-original-commit: c9fe8d113deb8103ad531d999f75f74c5475f46e
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Co-authored-by: vava-odoo <112173839+vava-odoo@users.noreply.github.com>
Suggestions can now be accessed by entering a GST number in the Tax
ID field of the contact form.
Add the option of allowing completion even with an 'insufficient
credit' error.
closesodoo/odoo#143532
X-original-commit: 2e47f94eba7a6c9df278c887f879fffeb8552706
Signed-off-by: Louis Baudoux (lba) <lba@odoo.com>
Task Adhoc: 29838
Description of the issue/feature this PR addresses:
-It is needed to improve the filters and and "Group By" from the search view of own checks and third party checks.
* In "Accounting/Vendors/Own Checks" it is needed to:
1) Remove the filter "Checks on hand".
2) Remove from "Group By" the group "Third party check Current Journal".
* In "Accounting/Customers/Third Party Checks" it is needed to:
1) Add the filter "Checks on hand".
2) Add in "Group By" the group "Third party check Current Journal".
3) Remove the filter "No Bank Matching".
4) Rename filter "Third party check Current Journal" to "Current Journal".
- When a payment is created is needed show the updated search view "Accounting/Customers/Third Party Checks" when searching more checks if "Existing Third Party Checks" payment method is selected.
- Change spanish translate of "Third Party Checks" group "Third party check Current Journal" from search view from "Actual Diario de Cheques de Terceros" to "Diario de Pago".
- Translate to spanish the filter "No Bank Matching" to "No conciliado con banco" and update other translations to spanish.
Current behavior before PR:
* In "Accounting/Vendors/Own Checks" in the search view:
Exists the filter "Checks on hand" and exists the group "Third party check Current Journal" in the "Group by".
* In "Accounting/Customers/Third Party Checks" in the search view:
Don`t exist the filter "Checks on hand". Don`t exist the group "Third party check Current Journal" in the "Group by". Exists the filter "No Bank Matching". There is a filter named "Third party check Current Journal".
* When a vendor payment is created when searching more checks if "Existing Third Party Checks" payment method is selected then is showing the same search view as "Accounting/Customers/Third Party Checks".
* Spanish translate of "Third Party Checks" group "Third party check Current Journal" from search view is "Actual Diario de Cheques de Terceros".
Desired behavior after PR is merged:
* In "Accounting/Vendors/Own Checks" in the search view:
Not exists the filter "Checks on hand" and not exists the group "Third party check Current Journal" in the "Group by".
* In "Accounting/Customers/Third Party Checks" in the search view:
Exists the filter "Checks on hand". Exists the group "Third party check Current Journal" in the "Group by". Not exists the filter "No Bank Matching". There is not existing a filter named "Third party check Current Journal".
* When a vendor payment is created when searching more checks if "Existing Third Party Checks" payment method is selected them is showing the updated search view as "Accounting/Customers/Third Party Checks".
* Spanish translate of "Third Party Checks" group "Third party check Current Journal" from search view is "Diario de Pago".
Video:
https://drive.google.com/file/d/1H1ng4mPsN0sf1NwW_JMOmZrhe8TrrBlk/viewclosesodoo/odoo#143526
X-original-commit: c56c35eb9b161dc5bdeaa545b1ed4e9e2a093a44
Signed-off-by: Josse Colpaert <jco@odoo.com>
From odoo 16.4 we need run odoo with python >= 3.10
However Debian Bullseye can't run python > 3.9.2 from apt manager
Now we use Debian Bookworm with python 3.11
closesodoo/odoo#143517
Signed-off-by: Yaroslav Soroko (yaso) <yaso@odoo.com>
Add Viva Wallet to the POS.
A new payment method that allows payment in person via Smartphone
closesodoo/odoo#140353
Task: 2991908
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
This commit removes an unnecessary field validation for HTML field.
closesodoo/odoo#143307
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Nicolas Danhier (nda) <nda@odoo.com>
During an onchange, fields read from database are validated again. This causes
an infinite loop with HTML fields since Odoo 16 because we're revalidating a
value we're reading from the database, which triggers a sanitisation check,
which fetches the original value, etc etc.
Even if the functional bug only appears in 16.0 and above, the root cause is
also present in 15.0 so this commit targets 15.0
steps to reproduce (in 16 or next versions):
- Change Marc Demos's access rights Website = Restricted Editor
- Bypass HTML Field Sanitize = Off
- Inventory / Products / Product Variants
- Studio on the Sales tab and add website_description under Website Sequence
- Go to product [E-COM07] Large Cabinet and fill in the newly added website description
- Log out and log in as marc demo
- Navigate back to [E-COM07] Large Cabinet product variant and try to re-order the vendors on the purchase tab
- Error
before this commit:
Error (infinite loop) during onchange
File "/home/nda/dev/odoo/16.0/odoo/odoo/models.py", line 6489, in onchange
record[parent_name]._update_cache({name: record[name]})
File "/home/nda/dev/odoo/16.0/odoo/odoo/models.py", line 5310, in _update_cache
value = field.convert_to_cache(value, self, validate)
File "/home/nda/dev/odoo/16.0/odoo/odoo/fields.py", line 1977, in convert_to_cache
return self._convert(value, record, validate)
File "/home/nda/dev/odoo/16.0/odoo/odoo/fields.py", line 2000, in _convert
original_value = record[self.name]
File "/home/nda/dev/odoo/16.0/odoo/odoo/models.py", line 5897, in __getitem__
return self._fields[key].__get__(self, type(self))
File "/home/nda/dev/odoo/16.0/odoo/odoo/fields.py", line 1198, in __get__
value = self.convert_to_cache(record._origin[self.name], record)
File "/home/nda/dev/odoo/16.0/odoo/odoo/fields.py", line 1977, in convert_to_cache
return self._convert(value, record, validate)
File "/home/nda/dev/odoo/16.0/odoo/odoo/fields.py", line 2000, in _convert
original_value = record[self.name]
...
after this commit:
no error
opw-3575865
X-original-commit: 24d804e
Part-of: odoo/odoo#143307
The issue is that "load older" was called every time the thread was made
visible, in particular after chat window unfold.
The load more button will naturally be visible when first loading a
thread, it only makes sense to check its final visibility and not
intermediate steps.
But there was a bug where the loading mechanism was relying on the
initial "load older" to fetch messages, because the messaging menu
preview was incorrectly setting the thread as already loaded, when it
just fetched the last message.
Moreover, the "last message" displayed in the preview was not correctly
computed, and it could end up being the last "currently fetched" message
and not the last of all messages (when jumping in the past), and it
could also be a non-persistent message.
runbot-35533
closesodoo/odoo#143129
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
We should only mark account moves as "Peppol ready" if it's a customer invoice/customer credit note.
These are also the only types of account moves we should display when a user wants to filter by "peppol ready" as this means they want to easily select all and send them via peppol in batch.
This commit limits "Peppol Ready" to `out_invoice`, `out_refund`, `out_receipt`.
task-3603416
closesodoo/odoo#142688
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Users need a helpful message for selecting the right EAS and Endpoint numbers.
In Belgium it should always be 0208 according to BOSA,
so we can display a warning message advising them to select that code for Belgian partners.
Part-of: odoo/odoo#142688
Steps to reproduce:
-------------------
- create an invoice without confirm it;
- go to the preview and download it;
Issue:
------
A traceback appears.
Cause:
------
We try to get `ids` field of a non "record" object.
Solution:
---------
Make sure you are in the case of an invoice
that is `posted` to download a pdf.
sentry-4612532780
closesodoo/odoo#141640
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Co-authored-by: adwid <awt@odoo.com>
PR [1] removed the legacy error handler that swallowed promise
rejection errors with anything else than an error (namely, the
"legacyRejectPromiseHandler"). As a consequence, promise rejections
done as "control flow" now lead to error dialogs being displayed.
In particular, it happened on the website (with website_event_track
installed), if the browser doesn't support service workers.
This commit simply leaves the promise pending if the feature is
unavailable.
[1] https://github.com/odoo/odoo/pull/137702closesodoo/odoo#143516
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
Previously, the datetime field read the value for readonly directly in
the attrs when extracting its props when available. This resulted in 2
separate bugs:
- in debug mode, props validation of the datetime picker would fail, as
it expects to receive a boolean for the `range` prop. This was caused
by the fact that required was the raw attribute (a string) instead of
the boolean and ended up being propagated to the `range` prop
- outside of debug mode, the value for required did not cause a crash
but any value for required that was not empty would be interpreted as
truthy, causing the field to always be display itself as though it is
required. In non-range mode, this is invisible, but in range mode, it
would always show the second datetime input and the arrow between the
beginning and end date, even with required being 0/False, or a python
expression that may evaluate to false
This commit fixes that by instead reading the value for required from
the dynamic infos provided to `extractProps`, which will always be a
boolean and contain the value of the evaluated expression when
appropriate.
closesodoo/odoo#143509
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
There's currently no way to move a dashboard from a section to another
You have to start again from a blank dashboard in the other group.
closesodoo/odoo#143505
Task: 3592986
X-original-commit: f7ba25afd5f1332b21a3d1631020ad9cd4b116fc
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
When users edit an outbound/inbound payment method line of their bank
journal and at the same time remove another payment method line,
the edited line changes back to its initial state (without the change).
It was caused by a complicated way to know which payment
method lines are available for this journal. This non-stored compute
field is recomputed for each change made on the inbound/outbound
payment method lines. It means that the function deals with the
origin record instead of the record itself.
During the search for this fix, we found out that everything works
fine if we remove the column_invisible on this computed field. In
that case, we did not have so as many calls to the compute function
to get the values. It's obviously not a solution and that's
why after some investigation, we decided to use the _origin id
when we get the outbound/inbound_payment_method_line in the
_compute_available_payment_method_ids function.
Thanks to @h4818 for his help during the process.
opw-3597536
closesodoo/odoo#143492
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Co-authored-by: Habib Ayob (ayh) <ayh@odoo.com>
The language was added at dccc8f39d0
419.png as odoo thinks it's a country...
closesodoo/odoo#143439
X-original-commit: 3bb58958c8f5f98da21bdac411bd226d03e1591b
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
When performing a manual stock revaluation, the value difference is distributed
equally among the available stock. This method breaks down however in case of a
devaluation where some items in stock are already valued less than the unit
cost difference: this results in a negative value.
This commit will prevent such devaluations by raising a UserError whenever the
remaining value of a stock.valuation.layer becomes negative. Additionally, after
a revaluation, the standard_price field will now also be updated for fifo valued
products.
opw-3340298
closesodoo/odoo#143437
X-original-commit: a6db4b48f1d32f1020ee3ad242c77211aa10b3b2
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
- Open a record with the chatter (a task for instance);
- Zoom your browser until the chatter is inline with the task (as it is
the case on mobile)
- Write a big message.
Before this commit, the composer takes all the allowed place on the
screen, and we cannot see or scroll-down to the older messages.
Now, the behavior is the same as is done in mobile, the composer stays
sticky, but it will not take all the allowed place, and leave place to
see and scroll-down the older messages.
opw-3593032
closesodoo/odoo#143427
X-original-commit: 26e8c0a74b9f0adb728c1d76ec7f45ec12623f6c
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
- Since dd21c708cc08d484530bc7c8433ebbb79f59323a, the opening cash difference is not posted in the suspense account. This commit fixes that.
- Removes the error preventing the deletion of cash difference journal entries.
task-id: 3460173
closesodoo/odoo#139975
X-original-commit: 52681b588c8353721f0b3d40f1b013bf0fc23904
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Purpose
========
Update demo data to better show what Appointment can do.
Specification
==============
Changing the capacity of some tables.
Tables 1-4 => from 4 to 2.
Tables 9-11 => from 4 to 6.
Task-3496910
closesodoo/odoo#137673
Related: odoo/enterprise#48438
Signed-off-by: Jérémy Hennecart (jeh) <jeh@odoo.com>
Issue:
When user add sub task then first field is focused.
Fixed:
In this commit, we have made the title the default focus so that the user does not
have to click manually and time will also be saved.
Steps:
- Install project app
- Active Task Dependencies
- Create task and add subtask
task-3471102
closesodoo/odoo#143251
X-original-commit: 487a62a249e783ca15f95675a6cf43322b61d569
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
In this commit, we fix the last step of the PosSettleOrderNotGroupable tour
which is deterministically failing in runbot.
closesodoo/odoo#143229
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Josse Colpaert