Prior to this commit, the event handlers that prevents the default
behaviors of a click was bound onto the $editable after the wysiwyg
editor had started.
This meant that during a very short period, the element could have the
"editor_enable" class but would not prevent clicks on the document
from triggering a default behavior.
This issue is not as important in versions prior to 16.0, because most
of the clicks on link would trigger navigation within the page,
canceling edit mode. If a traceback had appeared, it would be removed
quickly after, as the page was unloaded.
However, in 16.0, if the iframe leaves its current page, it can crash
the editor which now resides outside the page we are currently
editing.
Furthermore, the test introduced in [1] highlights the problem, as it
clicks on a link directly after checking if "editor_enable" is added to
the body within the iframe. This created a race condition, which means
the test crashed often.
This commit fixes the issue by using the click handler of the
website_preview to prevent the default behavior while in edit mode.
[1]: https://github.com/odoo/odoo/commit/050378dd8599b907ad429d4d1812602b557d0f73
runbot-18660
closesodoo/odoo#115119
X-original-commit: f9e51a8ab1cc469bd3dd4dba21856597d5e0f902
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Steps to reproduce:
- Install Project, Timesheets.
- Create a new porject with allocated hours set to 40 hours (5 days).
- Taking into account that our company have a 8-hour/day work schedule
(40 hours/week).
- We go then to the timesheet app and we add a line for the project
created with 8 hours as hours spent.
- Now we got to the timesheet configuration and we change the uom to
days.
- We go back to the timesheet app and we see the result, we can also
try to add just 1 day.
Issue:
The days are not properly computed, only when we are in hours are being
computed properly. But when we change the uom to days, the computation
that we see in the list will still be wrong.
Solution:
We really take into account which uom are we working with so we
compute the time properly depending on the uom.
opw-3138053
closesodoo/odoo#115049
X-original-commit: a31a1b6aff4db0415dc9c44bae33901f4833aba1
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Steps to reproduce:
- select a different company from the main one
- under settings/discuss enable External Email Servers
- set up an alias domain
- create an SO and send it by email
(you can catch the sent email using mailhog)
- reply to that email
(you can use the support-tools[1] and set In-Reply-To: "previous message_id")
Bug:
the reply_to field of incoming message defaults to the first company
Fix:
set the reply_to field to the company asociated to the record
(there's already a fallback to self.env.company in
"_notify_get_reply_to_formatted_email")
opw-3060214
[1]: https://github.com/odoo/support-tools/tree/master/scripts/mailclosesodoo/odoo#115090
X-original-commit: d86e57404d540762fa51afeabeddd3a0fc45d4d5
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
*=hr_timesheet,project,sale_project,sale_timesheet
Currently, the configuration of the recurrence is quite complete
and allows a lot of flexibility, but it is costly
in terms of implementation as it requires a lot of fields.
The goal of this task is thus to simplify this implementation.
In addition, a lot of people are complaining
that tasks are only generated when the recurrence date is reached,
as it doesn't allow to anticipate the planning of field service tasks.
In this task, we are thus going to immediately generate a new task
once the previous one is marked as done.
Concretely, we:
- describe a recurrence in terms of
"once every n day/week/month/year for ever/until a date"
and delete all fields that don't fit into it.
- remove the cron. The new occurrence is created when
marking the last task as done, and copied from the latter.
Deleting the last task deletes the recurrence.
The recurrence fields stay useful, as they form a delta t
that will be added to deadline/planned dates fields to get the new
values.
- use an boolean icon button to activate recurrence,
and place it at the end of deadline field's line.
The recurrence fields appear on the next line.
- delete in the form: the div explaining when the next tasks will be
created and the header to choose how to save the changes in the
recurrence.
task-3084945
closesodoo/odoo#112764
Related: odoo/upgrade#4343
Related: odoo/enterprise#37114
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
When trying to invoice undelivered quantities the error message
was somewhat misleading: it indicates as a possible solution a
Stock app feature even when Stock is not installed.
After this commit the message will be more appropriated.
opw - 3206001
closesodoo/odoo#115033
X-original-commit: a6ae8fae9f0db559880e04caa8446e57f7733c85
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Horacio Tellez Perez (hote) <hote@odoo.com>
Since [the merge of the frontend into the backend] and more precisely
since [this commit], clicks on some elements makes the user switch from
the backend view to the frontend view.
Steps to reproduce (just an example):
- Go to /blog from the backend (/@/blog)
- Click on a tag (eg: adventure)
=> users are redirected to the frontend view, we do not want that. This
commit makes the user stay in the backend. For some scenarios (like the
one above), we create a fake form and submit it. The forms have a target
attribute that specifies where the form response should be displayed.
This commit set back the default value for the target attribute when a
user clicks on a blog tag, a course tag, the pager, ... so that the
response is displayed in the current context (the iframe when the user
is in the backend).
Note that [this commit] introduced the target attribute change to fix
two issues:
1. The opening of the payment gateways in the iframe.
2. The create page from a 404 page in the backend.
After [this other commit] has been merged, to prevent the first issue so
here we just remove the target attribute change except for the case of
the second issue.
[the merge of the frontend into the backend]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
[this commit]: https://github.com/odoo/odoo/commit/2d44f2792dec0b2f205475a22dbedc97e9c54a64
[this other commit]: https://github.com/odoo/odoo/commit/3a32b9e1efa6277b345dc9239334680651690df7
task-3054970
closesodoo/odoo#114056
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Steps to reproduce the bug:
- Create a PO:
- Add a product
- Add a note or section
- Go To Alternatives:
- Click on “Create Alternative”
- Add another vendor
- Try to validate
Problem:
An error is triggered: “The operation cannot be completed: Description
(name) is mandatory”
The “display_type” and “name” fields must be copied in the vals to
create a `purchase.order.line`
opw-3164863
closesodoo/odoo#115070
X-original-commit: 66f806399d173f53b61db80b81d06a93421c75a3
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Update the UK tax names in accordance with the "taxonomy"
format (task-id 3052677).
EU Taxes have been changed to better reflect their current use (in
Northern Ireland only), and made inactive by default.
closesodoo/odoo#113363
Task-id: 3196842
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
This commit is to convert the "stock_report_generic" client action into owl.
closesodoo/odoo#112064
Taskid: 3175084
Related: odoo/upgrade#4309
Signed-off-by: Steve Van Essche <svs@odoo.com>
Before this commit:
=====================
KeyError 'selection_values' that occur in base_import/_handle_fallback_values()
while importing a data file. If any field(s) is many2one or many2many and we
tried to import the value of that field(s) that is not created in the database.
In that case when we set the 'Prevent Import' option.
It will raise an error like KeyError: 'selection_values'.
After this commit:
=====================
Solved the issue when there is a many2one or many2many field(s) and the import
value of that field(s) which is not available in the database. also, the method
is only for the 'selection' field and 'boolean' field so the code works when
there is a selection field and their selection_values only.
sentry - 3958065223
closesodoo/odoo#115056
X-original-commit: 0ef930cd7598bd15227ff025d2662d4331f8e45b
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
To compute the analytic amounts, we used the user company currency
to know the precision to use to round, for the comparison.
We should instead use the line's currency for the amounts, and the
decimal precision for the distribution.
closesodoo/odoo#114997
X-original-commit: a94517702c47aa9259c0cbea9b4763ab7501176f
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
When the invoice is a New record and thus, not yet stored inside the database, the totals like amount_untaxed/amount_tax/amount_total are set to 0.0 because line_ids is empty.
About the lines, balance/amount_currency are also set to 0.0.
This means we can not rely to any of these fields in any case when computing the values for a New record.
To reproduce, configure the early payment discount computation to "Always upon invoice", create a new invoice and set the demo terms 30 Net 2/7.
For a customer invoice, the tax amount will not be correct until the save.
For a vendor bill, the tax amount will be erased by the quick edit mode and the correct value will never be set.
closesodoo/odoo#114994
X-original-commit: a34033524f6e1a2f46ce2e14368389ecddc3c840
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Laurent Smet <las@odoo.com>
Current behaviour:
Down payments are taking into account in the project profitability in
the section "Other Cost". When invoicing fully an SO, the total sum
in profitability is the sum of the invoiced amount on the SO + the
down payment.
Expected behaviour:
Down payments should not be present in the project profitability, to
avoid incorrect sums.
Steps to reproduce:
- Install Sales, Accounting, Timesheets
- Activate Analytics in the Settings
- Set a Service Product that is invoiced based on fixed price
- Make sure that it generates a Project + Task
- Create a Quotation, confirm the SO with that product
- Create a down payment for 50% of the SO
- Confirm that invoice
- Create another invoice for the SO for the rest of the SO and
confirm it
- Go to the project's profitability tab for the SO, you can see that
we have the value of the SO + the amount of the down payment,
leading to an incorrect sum, in the section Invoiced.
Reason for the problem:
When taking the invoices for the profitability of the project, since
a down payment is another `sale.order.line`, we handle it in the
method `_get_revenues_items_from_invoices`, and there we are taking
into account the down payments.
Fix:
Elaborate the domain used to fetch the invoices in
`_get_revenues_items_from_invoices_domain` to not take those that
are down payments.
Affected versions:
- 16.0
- saas-16.1
- master
opw-3195016
closesodoo/odoo#115050
X-original-commit: ae151ec16a0054420f5c2827a1924c87e5b672ba
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
This could prevent the user deletion if linked to a record of this
type, like a auth_totp.device which inherits from this model.
Part-of: odoo/odoo#114656
Purpose
=======
Currently the on_delete='restrict' implicit constraint prevents
the user deletion in case it's linked to a forum post vote.
Set the on_delete attribute to 'cascade' as the record is not
really a critical data.
Taskid: 3222941
Part-of: odoo/odoo#114656
Purpose
=======
Currently the on_delete='restrict' implicit constraint prevents
the user deletion in case it's linked to a personal calendar filter
record.
Set the on_delete attribute to 'cascade' as the record is not
of any usage without the user anyway.
Taskid: 3222941
Part-of: odoo/odoo#114656
Purpose
=======
Currently the on_delete='restrict' implicit constraint prevents
the user deletion in case it's linked to a mail.activity record.
Set the on_delete attribute to 'cascade' as the record is not
of any usage without the user anyway.
Taskid: 3222941
Part-of: odoo/odoo#114656
Purpose
=======
Improve the portal user deletion by preventing timeouts and
avoiding several rollbacks causes.
Specifications
==============
- Move the portal users deletions from autovacuum to its own cron.
On big databases such as odoo.com, deleting a res.users takes
more than 1 minute. Move the whole process into its own scheduled
tasks.
- Commit the deletion at each user. As said previously the deletion
can be expensive, so commit what has been done to avoid having to
delete the same user again in case of rollbacks or timeout.
- Delete the user and the partner separately. If the partner is used
in a sales order for instance, the unlink is possible for the user
and not the parner. It allows to unlink the user and keep the
partner in case it cannot be deleted.
- Re-call the cron into another transaction in case there are too many
users to delete, instead of waiting next call, that is supposed
to occur the day after.
Taskid: 3222941
Part-of: odoo/odoo#114656
This commit fixes the same problem as the commit #113284
The previous commits partially fixed the solution, but the target can
still disappear between the moment where the `popover_service` adds the
popover and the moment where the setup of `PopoverController` is called.
The solution of this commit is the last defence against the undefined
target, #113284 will be kept as it prevent some owl computation if the
target is undefined at this state.
closesodoo/odoo#115032
X-original-commit: f6c309e595bf76d8ed8bb8c19228795572a8760c
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Dardenne Florent (dafl) <dafl@odoo.com>
The 'To do' picking filter made no sense as it used to check the pickings
that are not assigned or assigned to the user.
The new behavior corrects it by checking if the previously selected pickings
are not in a 'done' or 'cancel' state.
task id : 3087740
closesodoo/odoo#111648
Signed-off-by: Steve Van Essche <svs@odoo.com>
Kit were not reconcile because the `_stock_account_anglo_saxon_reconcile_valuation`
method try to match `account.move.line` and `stock.move` base on the
product field. However in kit case, the moves are exploded in mutliple
moves containing the kit's components. Due to that the matching is not
made.
To fix this issue we use the `purchase.order.line` that is share between
the `stock.move` and `account.move.line` to retrieve them.
closesodoo/odoo#114987
X-original-commit: f594c837c8a347abb48015d4e9bb0d5109228539
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
-Create 3 products with different costing methods: AVCO, FIFO, Standard
-Create a PO for the 3 items (same quantity and unit price in every line)
-Receive
-Create Vendor Bill
-Check Journal items.
You will notice that the AVCO product is marked as partially matched. Please keep
in mind that this only happens when the 3 costings are used and the unit price
is the same.
It happes because `_get_all_related_aml` returns all the
`account.move.line` for the journal entry and invoice.
But not only for the current product. So if they share the same
price unit then it could reconcile lines for different products.
X-original-commit: 23ccf2c1bde84f03aaaedb206e37a35de701da5e
Part-of: odoo/odoo#114987
When we set a cookie value (i.e. 'frontend_lang') on backend which can contain "invalid" character like @ (i.e. Serbian lang code: sr@latin) that cookie value will be double-quoted by werkzeug, so our example cookie will end up like: frontend_lang="sr@latin" instead of what's expected on the front-end: frontend_lang=sr@latin.On the front-end side we need to remove that additional double-quote before returning the actual cookie value.
closesodoo/odoo#114565
X-original-commit: 2631c8a39ccb03f5a0f142e479e3264f8885c5d2
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
When computing flag_image_url field on res.lang model an invalid url is generated due to the peculiar format for serbian lang code sr@latin which has "@" sign instead of expected "_" sign and thus the unexisting url is computed, so we are forced to populate binary field flag_image instead.
X-original-commit: 85db3773ba475a143a99126c6c24b404bdd39d0b
Part-of: odoo/odoo#114565
In Serbia there are two language codes and those are `sr_RS` (Cyrillic) and `sr@latin` (Latin). Inside of the `web/static/lib/moment/locale` folder, the two langs are registered as `sr-cyrl.js` and `sr.js` respectively. The `load_locale` controller wasn't loading the right langs for neither case.
X-original-commit: 65d5ab801f22b42a0f94fe4b86f68ace451ea184
Part-of: odoo/odoo#114565
The `date` widget, when used with a datetime value, doesn't offset the
value relative to the session timezone. This can lead to strange issue
like this following one
date1 = 12/03/2023 05:34:12
date2 = 12/03/2023 18:34:12
in the deliveryslip report, the datetime are casted as date, they become
date1 = 12/03/2023
date2 = 13/03/2023
closesodoo/odoo#114983
Opw: 3199862
X-original-commit: b6757daac6272092c37024ac2bdd49747177d2bc
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
*: web_tour, website_blog
Since [1] when the search box autocomplete was introduced, the URL
parameters are implicitly included into the RPC that fetches the
autocompletion results.
Those parameters were not correctly unescaped before being sent to the
RPC call.
Because of this, a timestamp such as "2023-01-01 23:00:00" was sent as
"2023-01-01+23%3A00%3A00" to the server. If that string reached the SQL
layer, the "+" was interpreted as defining a timezone.
This commit unescapes the URL parameters before using them in the RPC.
Note that javascript's `decodeURIComponent` does not handle the '+'
encoding of spaces inside URL parameters.
For testing purpose, the following updates were needed to make it
possible to select the `<option>` within the Archive month `<select>`:
- because the `option`s are in a tree, the tool was adapted to take all
`option`s into consideration instead of only the direct children of the
`select`.
- because the `option` text is dynamically created from the date of the
test execution, the tool was adapted to allow targeting an `option`
based on its index by specifying the tour step's `run` as
`'text index N'`, `N` being the index of the `option`.
Steps to reproduce:
- Enable the sidebar of the `/blog` page.
- Select a month in the sidebar.
- Type something in the search box.
=> Did show an error popup while obtaining the autocompletion records.
[1]: https://github.com/odoo/odoo/commit/7559626c54e34b41e1549e28276a650accec6986
task-3213916
closesodoo/odoo#114913
X-original-commit: 115fc399461c37b57127684cf5c28f05443fbb54
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
During revision 415525cecc
the code comparing the connections without password has been
dropped, for an unknown reason.
Because of the above, and the fact psycopg2 alter the password
with 'xxx' for security reasons, the connections recycling was
no longer working as expected, and was recycling less connections.
closesodoo/odoo#37005
Signed-off-by: Rémy Voet <ryv@odoo.com>
If an invoice is send to the Tax Agency, we should block the fact
that the user can delete it. In that case, we can have issues when
the tax agency sends back notifications.
Task link: https://www.odoo.com/web#id=3192962&model=project.task
Task-3192962
closesodoo/odoo#114872
X-original-commit: c11a512af4e467068c6b228bf55225e5e43d7811
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
This reviews [1] which solved the problem in most cases (hopefully) but
not in all cases. Animated elements which overflow the screen on the
right made an horizontal scrollbar appear on iPhone <= 8 using Safari,
even when they were not animating yet.
This was due to Safari ignoring the `transform: none` rule on inactive
elements, preferring to consider the animation transform. As a fix, we
forced no possible overflow of the page when we saw this safari bug on
the first animated element.
The problem here... is that this Safari bug does not occur in every
situation. For example, if the animated element is inside a column which
is marked as hidden in mobile, Safari actually understands the no
transform rule. So if the first animated element was in such a situation
but another element in the page had the safari bug... the problem was
there again.
As a fix, we now check all animated elements for the Safari bug, instead
of only the first one. That should do the trick.
This commit also reviews the comment: the problem is not confined to
old iPhones. This was reproduced on the latest iPhone with latest iOS
and up-to-date Safari.
opw-3204613
opw-3201937
Related to opw-3165651
[1]: https://github.com/odoo/odoo/commit/c1447835786e04f342342540c09e46d1226d5fc0closesodoo/odoo#114999
X-original-commit: 8fe2d91e05e85ae2e50f1066214d0af5796e5296
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Issue: when use t-if to display text and use mutli line, the white-space
are removed.
```
<div>
<t t-out="nb"/>
<t t-if="nb == 0 or nb == 1">product</t>
<t t-else="">products</t>
</div>
```
is rendered:
```
<div>
3products
</div>
```
closesodoo/odoo#114986
X-original-commit: 3150a3769ff4d762c0e52dab31a70b59292c1bcc
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit fixes the behavior of the FileInput component. Since the html
element of type input doesn't trigger its onChange when a file with the
same name is given twice to the input, we must first clear the input value,
which will cause the input to handle the file even if the input already
contains this file.
Even if that seems unnecessary, this is an easy way to fix issues in the
base_import action were data are not send back to the server when re-uploading
the same file to let the server process the data.
A test has been added to assert that the onUpload is effectively called twice
when uploading a file, even if it's the same exact file.
closesodoo/odoo#114978
X-original-commit: d4a23c521d0e15f893d74e3530bc68ef19641f48
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Signed-off-by: Luca Vitali <luvi@odoo.com>
When using the 'toggleDeviceVisibility' option, we can see that there is
a mismatch between the screen breakpoint at which the elements are
displayed like in mobile view (=> under 992px or `lg`) and the one that
is impacted by the 'Hide/Show' option (=> at 768px or `md`). This is
a problem because between these two breakpoints, the display is like in
mobile view but is not considered as such and so, hiding/showing an
element in the mobile/desktop view (for example, if it does not look
good in one of them) has no effect until the screen reaches 768px.
This commit increases the screen breakpoint at which the 'toggleDevice-
Visibility' option is applied, that is, at 992px instead of 768px, in
order to be consistent with the display.
task-3110770
closesodoo/odoo#114977
X-original-commit: b062b280fdadcde857fff4f7a57876da50542cb3
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Signed-off-by: Bojabza Soukéina (sobo) <sobo@odoo.com>
In order to make the model reactive, it must not be an EventBus. An EventBus cannot be reactive. So we will add a key bus to the model that will always trigger all events that were triggered on the model before.
Part of task 3179751
closesodoo/odoo#114975
Related: odoo/enterprise#38032
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps to reproduce:
- Install stock
- Config > Shipping > enable Signature on delivery orders
- Create delivery order > Validate
- Switch to mobile view
- Action > Sign
Issue:
We get a traceback: `Uncaught Promise > Component is destroyed`.
This happens because the signature widget is destroyed when the Action
dropdown is folded.
Solution:
Use the orm service in `this.env.services` to perform the `write`.
We have to also update the view in order to see the new delivery slip.
opw-3133731
closesodoo/odoo#114954
X-original-commit: ad555010ea668324aeee21f8aabd41fe352eb0f5
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Stefan-Calin Crainiciuc (stcc) <stcc@odoo.com>
Currently the below use-cases are hardly supportable, though quite common:
Retail: Sell product in one shop and return it in another one
Restaurant: Managing payment when having multiple checkout desks,
and multiple waiters (only taking orders)
This because currently:
PoS orders are only known by the cashier desk (pos.config) they were created from
One floor map can only be linked to one cashier desk at a time
More over, with the Self-Service coming along the way
(where kiosk orders must be accessible from a cashier desk),
this need must be supported.
For restaurant, floor plans can be linked to multiple cashier desks,
ongoing orders are shared between trusted PoS config
(through floor plans for restaurant and according to
the setting "Trusted PoS config" for the retails),
and past orders can be accessible from any desks within a same DB.
closesodoo/odoo#109216
Related: odoo/upgrade#4393
Related: odoo/enterprise#37955
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
State `done` means *Locked*, which means that most of the fields should not be
editable.
However, the behavior for the field `warehouse_id` was changed during refactoring in
https://github.com/odoo/odoo/commit/f9f68adb2cdfdfd16bc24c82acae015ddfb9b83a
This commit restores Odoo 15 behavior in Odoo 16+
opw-3204896
closesodoo/odoo#114973
X-original-commit: 9efc8190565db160615f8a3e92f2e7f89edfca8b
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Remove the existing t-if on m2o_avatar_user/m2m_avatar_user widget
on user_id field in"project.project.kanban" view to allow quick-assign.
closesodoo/odoo#114400
Task-id: 3121207
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Prakash Prajapati