Before this commit and since PR [1], the default "checked" value set on
checkboxes field on the form snippet were lost once the page is saved.
This is because [1] changed the rendering engine of qweb templates from
our own qweb js rendering code to owl templates rendering.
By doing so, `t-att-checked="'checked'"` would toggle the "internal"
checkbox checked value but would not add the checked attribute on the
element.
It's a deliberate choice made in owl. As the checked attributed does not
mean the same as the internal checked value, it makes sense.
Indeed, the checked attribute is about the default value of the checkbox
while the checked internal value is about the current checked state of
the checkbox.
In React, for instance, the same behavior can be seen. And if one wants
to really set the checked attribute, they got to go with
`defaultChecked`.
Same apply with `value`.
Maybe owl will implement the same `defaultXXX` behavior in the future as
it's something that was already discussed on their side.
Step to reproduce:
- Drag & drop a form in the website builder
- Add a new custom field and select "Multiple Checkboxes" type
- Set one of the checkbox checked by default
- It is visually checked, but the attribute is not set
- Save the page
-> The checkbox is back to unset state since the attribute was not set
[1]: https://github.com/odoo/odoo/pull/130467
opw-3607795
closesodoo/odoo#146328
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit add a new delay_type that will add to the date the nb_days then go
the end of the month and finally add a new field called days_next_month.
This field is a Char because we want the field to be of size 2. Also, we added a
constraint that this field must be numeric and between 0 and 31.
Ex of use with Invoice date the 25/11/2023, if we have a payment term with 90
for the nb_days and 10 for the days_next_month:
+90 days = 23/02/2024
End of month = 29/02/2024
+10 days = 10/03/2024
(Also, there is a special case handling when the day of the month is 29, 30 or
31 to avoid exceeding the next month's end. For instance, with a payment term of
30 days end of month and using the 31st of a month, prevent calculation from
moving beyond the end of the next month (e.g., early March instead of end
February)
closesodoo/odoo#143758
Task: 3609320
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
__Current behavior before commit:__
`_compute_meeting` computes the meetings linked to the children of the
partners in `self`. To do so, it first retrieves all children partners
of `self`, then it loops through all of them to apply the meetings to
the parents.
This way of doing is inefficient because it is useless to iterate over
the children that don't have any meetings.
__Description of the fix:__
Loop only through the partners that have a meetings instead of all
children partners.
Improve `test_meeting_count` to test the case where only the child
partner has a meeting but the parent has initially none. This test
improvement is a forward port of [#144575][1].
__Benchmark:__
| len(all_partners) | w/o fix | with fix |
| ----------------- | ------- | -------- |
| 1k | 32 ms | 14 ms |
| 100k | 1500 ms | 800 ms |
opw-3511371
[1]: https://github.com/odoo/odoo/pull/144575closesodoo/odoo#146381
X-original-commit: e35949cdd09b4312a60383b79290008e78768b64
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Julien Launois (jula) <jula@odoo.com>
Description of the issue/feature this PR addresses:
Within the project task form view, in the timesheet notebook, the "Remaining
Hours on SO" label becomes misaligned when the planned hours are set to 0.
Fix:
To ensure proper alignment, add a condition for the label.
task:3468392
closesodoo/odoo#146334
X-original-commit: 3f35ccf7bdd9c0cb988f0207427ec8d3acccecd6
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Steps to reproduce:
- Add a "Text-Image" on the website.
- Replace the image by one of your own.
- Save.
- With the html editor, remove the `mimetype` attribute, the
`data-original-src` attribute and change the `src` of the picture into
the corresponding protocol-relative one. The `src` then looks like
"//domain/web/image/...".
- Save the modifications of the html editor.
- Enter in edit mode.
- Click on the image.
-> It is now impossible to change options such as `Filter`, `Width` and
`Quality`.
Because the `data-original-src` attribute was removed from the image,
the system tries to add it back thanks to the `loadImageInfo()` logic.
Because the `src` attribute of the image is now a protocol relative url,
`new URL(src)` will raise an error and the logic will use this url as
argument for the `/web_editor/get_image_info` route. Because the url
given in argument of the rpc call is not the relative one, the system
fails to find the original attachment. The `mimetype` attribute is
therefore not added back on the image, leading to the impossibility to
change some options.
To solve the problem, this commit modifies a bit [this commit]. In order
to be robust to absolute, relative and protocol relative URLs, an URL
object is first created from the image src. The relative URL
(`.pathname`) of the URL object is then used to retrieve the original
attachment linked to the image.
Let's synthesize the different `relativeSrc` obtained with different
image src. In the following examples, "https://test.com/blog/travel-1"
will be used as `img.ownerDocument.defaultView.location.href`.
(the complete URL of the document in which the image is located).
- `src` is an absolute URL (e.g.
"https://test.com/web/image/697-d0f2aaf8/shoes.jpg"). In this case,
`relativeSrc` = "/web/image/697-d0f2aaf8/shoes.jpg".
- `src` is a relative URL that begins with a slash (e.g.
"/web/image/697-d0f2aaf8/shoes.jpg"). This URL represents an absolute
path starting from the root of the domain. In this case, `relativeSrc` =
"/web/image/697-d0f2aaf8/shoes.jpg".
- `src` is a relative URL that does not begin with a slash (e.g.
"web/image/697-d0f2aaf8/shoes.jpg"). The interpretation of this URL
depends on the current location. In this case, `relativeSrc` =
"/blog/web/image/697-d0f2aaf8/shoes.jpg".
- `src` is a protocol relative URL (e.g.
"//test.com/web/image/697-d0f2aaf8/shoes.jpg"); there is only the
protocol missing. In this case, `relativeSrc` =
"/web/image/697-d0f2aaf8/shoes.jpg".
This solution takes the advantage of the second argument of the `URL()`
constructor which is used if the first parameter is a relative or
protocol relative URL and which is ignored if the first parameter is an
absolute URL.
This commit does not only modify [this commit] to handle more types of
URLs but also:
- To avoid having to use `.split()`. Indeed, `.pathname` does not
include query parameters.
- To avoid having to consider an error raised by `new URL()` as a normal
flow. Indeed, in [this commit], an error would be intercepted by the
`catch` if `src` was a relative URL. This was a legitimate flow. The
problem was that other unwanted types of src (for example protocol
relative URL) were also raising errors but were silently ignored (as
intercepted in the `catch`).
[this commit]: https://github.com/odoo/odoo/commit/89c14783846288a2de53f6258a93440e02550b13
task-3623731
closesodoo/odoo#146238
X-original-commit: 96324fe8443647a078756c98f9629af274ff38a5
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Colin Louis (loco) <loco@odoo.com>
When a line with a factor_percent of -100 is applied in the tax,
it should be subtracted from the ImporteTotal.
This way, we might think that the total of the invoice should do,
but we need the amount before application of the withholdings.
And in the case of DUA it should be the sum of base and tax.
Doing this, we realized that we do not have any tests for
vendor bills and their refunds for the intra-community case, so
we added one for vendor bill and one for vendor refund. (there
is no -100 line for sale)
In the meantime, we added docstrings on the existing tests
and realized that the sale of intra-community services, it should
be no sujeto por reglas de localizacion instead of sujeto.
(because as well with the fiscal position, the delivery address counts)
We also saw that for intra-community, the clave regimen depended
on the tags on the amls but the refund repartition lines were not mapped on the
tax report line with Intra-community but in a separate refunds section
(mod303), so we fixed by checking all tags on the tax from all the
repartition lines.
task 3603788
closesodoo/odoo#143204
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
To reproduce
============
- Create a meeting activity from any document (for example CRM opportunity) with a calendar.
- It will create a meeting in the calendar.
- Now, mark as done the activity created and it will delete the meeting from the calendar too.
revert of https://github.com/odoo/odoo/pull/144526
opw-3626773
closesodoo/odoo#146421
X-original-commit: 0b183299a8ef7361d28d9d2b49cc56b74bfb2b46
Signed-off-by: Abdelouahab Laaroussi (abla) <abla@odoo.com>
Steps to reproduce:
- Install Accounting and l10n_sa_edi
- Create a retention tax: (e.g. "Retention Tax 10%")
* Amount: [a negative amount] (e.g. -10.00%)
* Is Retention: [checked] (in "Advanced Options" tab)
- Create an invoice with the following invoice line:
* Product: [any]
* Price: 1000
* Taxes: "Sales Tax 15%" and "Retention Tax 10%"
- Confirm the invoice
- Print the invoice
=> On the invoice, there is a "VAT Amount" field that should show
the amount coming from the taxes that are not Retention taxes as it
is done in the EDI invoice (XML).
However, the Retention tax is subtracted.
In our example:
- Tax amount for "Sales Tax 15%" is 150.00
- Tax amount for "Retention Tax 10%" is -100.00
=> The "VAT Amount" field of the invoice line is 50.00.
It should be 150.00 instead.
Solution:
Compute the "VAT Amount" field as it is done in the EDI invoice.
opw-3568831
closesodoo/odoo#146394
X-original-commit: b50d20e9fc631d7aa2e64cf6749be1630354fd69
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Anh Thao Pham (pta) <pta@odoo.com>
Steps to reproduce:
- Install Accounting, Sales & Purchase
- Go to "Settings / Users & Companies / Companies"
- Create a branch company (e.g. Branch Company) for a company (e.g. YourCompany)
- Switch to Branch Company
- Go to Sales (or Purchase)
- Create a SO (or PO)
- Add a SO line (or PO line) and try to select a tax
=> Taxes from the parent company are not available in Sales and Purchase
as they are in Accounting
opw-3604981
opw-3636972
closesodoo/odoo#146384
X-original-commit: ddc653758c2dd6af74e21f5fbd07ab679ffb3e73
Signed-off-by: Anh Thao Pham (pta) <pta@odoo.com>
Summary
-------
Currently, the 'Total amount of invoice in letters' setting doesn't do
anything on GCC invoices.
Steps to reproduce
------------------
* install `l10n_sa`
* enable the Arabic language
* in the settings, enable 'Total amount of invoice in letters'
* create and print an invoice
You should see that the amount in words in not displayed.
Note:
Currently, currency labels are not translatable. Since this isn't
something that can be changed in stable version, it was decided to not
include them in the Arabic amount in words.
opw-3501112
opw-3485691
closesodoo/odoo#146364
X-original-commit: 1fb28f229c701ae1261dc502ef345ffda162f994
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>
Before this commit, the sending webhook did not work well naturally
with the receiving end.
After this commit, it does since default values on base_automation have been adapted.
closesodoo/odoo#142710
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Set a webhook that executes a ir.actions.server of type python code.
Before this commit, the code had no access to any request's parameters. This was a limitation
in the basic flows that the feature is supposed to support.
After this commit, we pass in the context a key "payload" that contains a copy of the request parameters.
task-id-3599629
Part-of: odoo/odoo#142710
Steps to reproduce:
- Open Project
- Go to project for which sale order item is created
- By clicking on three dots, go to Project Updates
- In right side panel, milestone section, there is no space between milestone
name and the SOL
Issue:
- This lack of spacing between milestone name and SOL makes it difficult for
users to read and understand milestone information.
Cause:
- The project.update right-side panel was displaying milestone names and SOL
without a space, causing readability issues for users.
Solution:
- added a space between the milestone name and SOL.
task-3545942
closesodoo/odoo#146360
X-original-commit: 6341fabafd225e2ecf8037f58e5312ce391003f0
Related: odoo/enterprise#52816
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
[Commit 1] made sure the history worked when resizing elements by
calling `odooEditor.automaticStepUnactive()`, but applied its
counterpart `automaticStepActive()` only at the very end of the action,
leaving some `return` statements on the way that could break the flow.
This commit calls `automaticStepActive` just before leaving the listener
and moves `automaticStepUnactive` just before the first DOM
modification. It's both more logical and avoids returns pitfalls.
Note: `automaticStepActive()` makes sure modifications made on the DOM
through the browser's developer tools are tracked and can be reversed
with the undo button. Not reactivating it in time means some flows could
be broken (until another method reactivates it).
[Commit 1]: https://github.com/odoo/odoo/commit/423f4bd2a6cc47e69699d2437eaa5acda94bb98d
Related to task-3576046
closesodoo/odoo#146249
X-original-commit: b99cc41e4352d3ff9bffe7b0a5436edbef0ab01b
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Robin Lejeune (role) <role@odoo.com>
Before this commit and since [1] when the website builder was moved from
the "frontend" to the "backend" of Odoo in Odoo 16, the option to enable
URL redirect when updating a page URL was "compressed":
- The toggle/switch element has not enough room to be displayed entirely
if there were too many dependencies
- The toggle/switch label was split in multiple lines, words could even
be split in 2.
Step to reproduce:
- Go to / in the website builder (so the / finds a lot of dependencies)
- Open page property
- Change the URL field, you see the redirect url field appear with the
mentioned issues.
Note:
- In other languages, the switch label could be even longer, splitting
the line makes even more sense
- Removing a class is generally something to be avoided in stable, but
this type of class should not be xpath'd anyway. And given the
template structure, it's unlikely someone would have xpath it as it's
easy to xpath any element without relying on classes.
One solution would have been to add a new class to cancel the first
one but it seems overkill in this case.
[1]: https://github.com/odoo/odoo/commit/2ef7e788263b4742a8e0788f47673b7b31da3726closesodoo/odoo#146244
X-original-commit: 8c17c487e6632192874133a2ce4265a0f1eaf6fb
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
When a page is reloaded with the chat bot, it sometimes restarts from
the beginning. This commit ensures the chatbot starts where it left
after a page reload.
closesodoo/odoo#146175
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this commit and since commit [1], it was possible to clone a page
in the page list view.
It shouldn't be the case, cloning a page lead to bad result: a page
with the same URL which is not shown in the page list view because pages
are filtered by URL to remove duplicates.
Cloning a page has always had to be done through the page properties >
"clone page" button. Doing it this way will ask the user for a new page
name (and so a new url). The page will then correctly be listed.
[1]: https://github.com/odoo/odoo/commit/3192051806e0da1276604a31ad818f8768105362
opw-3591738
closesodoo/odoo#146173
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Purpose:
- Changed the default value of 'Show In Preference' (is_public) field from true
to false for preventing the automatic publishing of mailing lists.
Task-3594678
closesodoo/odoo#144699
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
In this pr we remove the blank choice in the self-ordering mode select.
It's unnecessary and throws a validation error on saving settings.
Task 3599144
closesodoo/odoo#142351
Signed-off-by: Robin Heinz (rhe) <rhe@odoo.com>
When the pos was loading only a part of the products, the request should follow those rules order:
- product is a favorite
- product is a service
- product had stock moves soon
- product update
But this request didn't take into account consumables products and if there was no stock move,
the value was null and postgres consider null values first when ordering desc.
Now with that changes, the order is correctly set based on the rules above.
closesodoo/odoo#139981
X-original-commit: 35a9168a53bded7e13451f4b485443c1b419ea21
Signed-off-by: David Monnom (moda) <moda@odoo.com>
Signed-off-by: Adrien Guilliams (adgu) <adgu@odoo.com>
Problem
---------
In most cases, default deferred accounts and journal need to be set up
for localizations. This is normally done in the enterprise report module
for that localization. However, in some cases, the localization does not
have special report formats. In such situation, a localization report
module that sets up very few default values for the data company is
defined. This is way overkill.
Objective
---------
Allow the community company template to have 'unknown fields' defined.
Doing so, allows for the default deferred accounts and journal to be
defined without entreprise module to exists. Currently, this raises an
error.
Solution
---------
In the pre-processing of the chart template values, we skip all the keys
in the company data that are not company fields.
We add a context value which, when True, revert that behavior back to
before this commit and checks that all fields in the company template
are actual company fields (this will be used in the standalone test for
l10n modules).
We also update the standalone test for l10n modules so that:
1. it reports errors in all l10n modules at once.
2. it uses the context value described above and checks that all fields
in the company chart template are correct company field.
closesodoo/odoo#138937
Related: odoo/enterprise#50305
Signed-off-by: William André (wan) <wan@odoo.com>
Currently, if you switch to a right-to-left language and open the POS,
the numpad will look like this:
3 2 1
6 5 4
9 8 7
The numpad should stay the same even in RTL languages:
1 2 3
4 5 6
7 8 9
opw-3623228
closesodoo/odoo#146181
X-original-commit: fb0ece3336f53cfba4e7ef9c59f4acbd292da45a
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>
Issue:
Invoice move lines' quantities reset to 1 on the second page when the
customer is changed after pagination.
Steps to Reproduce:
1. Create an invoice with over 40 move lines (requiring pagination).
2. Navigate to the second page of move lines and observe quantities.
3. Change the Partner (e.g., Azure -> My Company).
4. Save changes.
5. Notice that quantities on the second page are reset to 1.
Solution:
Identified the issue as stemming from the `flush_model` method, which is
called on creation and triggers re-computation. This process calls
the `compute` method for the quantity field, leading to an erroneous
reset of quantities to 1.
Modified the compute method to only reset values to 1 if they are
initially 0 or False, thereby resolving the issue of unwanted quantity
reset during pagination when customer details are updated.
opw-3483851
closesodoo/odoo#146136
X-original-commit: bb08a627528cd7402a16689c420f3013488e9a4d
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Signed-off-by: Mohamed Erradi (moer) <moer@odoo.com>
Previously, when updating and resending a snailmail through the chatter,
it would re-send every snailmail letters in the DB with an error.
This behaviour lead to users mistakenly sending dozens of unwanted
snailmails, expecting to re-send the one they were currently on.
This commit changes that by only sending the relevant letter(s).
closesodoo/odoo#146078
X-original-commit: 43a56e84919604608d12bf3d8528339733fc79d8
Signed-off-by: Louis Baudoux (lba) <lba@odoo.com>
Signed-off-by: Solan Delvenne (sode) <sode@odoo.com>
Before this commit, when many channels were pinned in Discuss,
the messaging menu took a while to open and render all items.
This happens because `fetchPreviews()` and `inbox.fetchNewMessages()`
were inserting data for each thread and message. This meant computed
and sorted fields were called with that many objects.
This commit improves the performances by wrapping all of it in an
update cycle transaction, so that computed and sorted fields are
invoked only once at the end of the update cycle.
With `contacts` installed, populate `medium`:
- Before this commit: 1min.
- With this commit: 2sec. (30x faster)
closesodoo/odoo#145980
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
This commit correctly aligns certain header elements when the CTA button
has a larger vertical padding.
Steps to reproduce the issue:
- Install 'eCommerce' on your website.
- In Website edit mode, click on the 'THEME' tab.
- Adjust the vertical padding of buttons to 25px.
- Click on the header in the page.
- In the 'STYLE' tab, select the 'Menu - Sales 1' header.
- Bug: The 'logo" and the 'menu items' are not aligned with the CTA
button.
- In the 'STYLE' tab, select the 'Menu - Sales 2' header.
- Bug: The 'menu items' are not aligned with the CTA button.
- In the 'STYLE' tab, select the 'Menu - Sales 4' header.
- Bug: Bug: The 'cart' button is not aligned with the CTA button.
task-3478334
closesodoo/odoo#145683
X-original-commit: d2f6710bcaa5cee7e77fc4df902929264ffa4830
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
Before this commit, the default update_path even if the field was
readonly, it weas returned. So, if you try to create an automated
action on the stock.move.line model and try to add an action, the
button return a traceback because the field is readonly.
After this commit, the method that get the default update_path will
also check if the field is not readonly.
Bugfix Task-Id: 3624328
closesodoo/odoo#146166
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
Overflowing search facets do not wrap making them disappear from view
when too long. This can happen when searching a single field for
multiple values (as they are bundled in the same facet).
The problem is fixed by allowing facets to wrap.
Steps to reproduce:
* Open a view with a search (kanban, list, ...)
* Add many, many long terms search for the same field
=> BUG the search overflow outside the search bar
opw-3581553
closesodoo/odoo#146133
X-original-commit: acd476a4ded3ca873e10dc4cc72668efdcb2c629
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
How to reprodruce:
1) Go to product.template view form
2) Open Studio
3) Go to tab 'Purchase' tab
4) Edit list/form view of the seller_ids (supplierinfo)
Before this commit, the domain on product_id of supplierinfo was using
'parent' as if already doing the filter on the view. Because of the complex
domain in the string, a traceback was throw when editing supplierinfo view
with studio on the product.template.
After this commit, the domain on the python side is simpler. The domain for
the view has been moved in the view and changed to not be dependent of the
parent view, but of the context.
Bugfix Task-ID: 3615851
closesodoo/odoo#145586
Signed-off-by: Steve Van Essche <svs@odoo.com>
The aim of this commit is to correct the date of the payment.
Context:
When creating a PoS session and a PoS order on date X
The customer gets its invoice on date Y
the payment date is printed on the invoice
Before this commit:
The payment date will always be the date of the invoice
After this commit:
The payment date will always be the date of the order, the date at which
is was really paid.
Corner case not taken care of in this commit:
Claiming the invoice after the `fiscalyear_lock_date`.
In such a case, the payment date will be set to today (the invoice_date)
again.
This should be really rare as setting that lock date in short time frame
is quite unusual.
closesodoo/odoo#146259
Task-id: 3629054
X-original-commit: 732e43d8a6d4012eafb434952ccb6609f9be8066
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Before this commit, clickall was clicking on an app that redirect to a
tablet mode view. The issue with this is that clickall don't know how to
exit the view, so it was stuck in the view.
This commit adds that view on the blacklist of clickall.
Also, this commit adds an error message when clickall is stuck in a view.
closesodoo/odoo#146216
X-original-commit: 8f365824c9dddacf1b3a40688a30c8498df3d5d4
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, when the user tried to quick create a record in
a grouped kanban view (by clicking on the "+" icon of a column, for
instance), and then clicked on the "Edit" button of the quick
create, if the name_create rpc failed, the webclient switched to
the form view and an error was displayed.
The displayed error was about a destroyed component trying to do an
rpc, namely the kanban controller. This is because it does 2 things
when the name_create failed: it opened the form view in a dialog
and it also switched to the form view. The latter was unwanted:
in case of errors, we don't want to switch to the form view but
rather to quick create from a dialog.
The error was actually caused by a small mistake: we use the
record variable to determine if the quick create succeeded and if
we can switch to the quick created record. However, that same
variable was already set before, for another purpose.
OPW 3620671
closesodoo/odoo#146141
X-original-commit: 01bc79051b22f41eff20d860327ed0e41b572cd4
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, when browsing the "Events" part of website on Safari
(both macOS and iOS/ipadOS), the page could be loaded only once and
returns a "FetchEvent.respondWith received an error: NotSupportedError:
The operation is not supported." error message on afterward, completely
blocking access to everything under the `/event` path.
This error is actually thrown from the ServiceWorker's `fetch` event's
listener, and more specifically, from the storage availablity check.
Since Safari 17.0, the Storage API - and in this case its `estimate()`
function - has been enabled in WebKit's builds for Apple platforms (see
WebKit PR [1]). But even if this feature should be available in Web
Workers (cf. MDN [2] and the spec [3]), it returns a NotSupportedError
error when called from the ServiceWorker on Safari 17.0+ (but works fine
in the global scope).
This commit works around that issue by wrapping this call in a
try/catch, acting as if not supported when an error happens.
Steps to reproduce (on Safari iOS):
- Install website_event_track module
- Navigate to the `/event` page
- Reload the page
=> Browser level error page "FetchEvent.respondWith received an
error..."
Note: due to the browser's engine restriction on iOS/ipadOS, this issue
also affects all browsers on these platforms.
[1]: https://github.com/WebKit/WebKit/pull/10973
[2]: https://developer.mozilla.org/en-US/docs/Web/API/StorageManager/estimate
[3]: https://storage.spec.whatwg.org/#ref-for-dom-storagemanager-estimate
opw-3553880
opw-3570730
opw-3610167
opw-3629039
opw-3547759
closesodoo/odoo#146190
X-original-commit: 45020635a81ce53ee0769ca54ac733528e4110b1
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
Currently, when a peppol document is received, we log a success message regardless of whether the account_move has been created properly or not. This commit changes that to only show the message if everything went well.
A follow up to a fix for opw-3628030
closesodoo/odoo#146236
X-original-commit: d1d35429d6897db7210a98889d6268a4d0d3cbe8
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Aliya Tastemirova (alta) <alta@odoo.com>
Commit [1] removed the `email_from` field from the `project.task` model
but forgot to adapt/delete some field occurences.
One of those is related to the form in the website builder which allows
to create task when the form is sent.
Two errors were detected:
- Non critical:
The field is still passed to the form field whitelisting process.
Since the whitelisting is done in raw SQL, it didn't crash or log
anything even if the column did not exist anymore.
- Critical:
The field was still marked as model required in the form JS registry,
altering the form builder behaviors.
One of those is that when the form input related to this field was
re-created (eg when changing / hovering an option in the right panel),
it would lose it's "name" attribute.
Two possible issues from that point:
1. When a visitor submit the form, the "email_from" field value is not
set anymore in the task description and that information is just
lost. You then have no way to reach back to him.
2. (Minor) The auto-fill behavior of the form was not working anymore
Probably more issues were introduced but only those ones got detected as
of today.
Step to reproduce:
- Drop a website form, choose "Create a Task"
- Focus the default "Email" field
- Hover the mouse on the "eye" icon ("Invisible") next to the Position
attribute. If you inspect the DOM, the input has now lost the `name`
attribute.
- If you save, you will face the issues reported above.
- If you then reopen the editor and focus the email field again, the
tooltip will now say that the "null" field is required.
[1]: https://github.com/odoo/odoo/commit/a424cf481c676a230beeb6102fc67bedf472a882
opw-3626573
closesodoo/odoo#146170
X-original-commit: 6679fddbcaf7d9146ab242e0eed61ee0628f047f
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Description:
Indexes on a Selection field are never used in a `NOT IN` where clause,
as PostgreSQL doesn't have the complementary values (in DB a Selection
field is just a VarChar) to make use of an index on the field.
The ORM currently doesn't invert
`not in <selection>` -> `in <complement of selection>`.
Benchmark:
Positive impact in the project modules all around, specially for long running
projects where the proportion of "done" tasks are >90% of the
project's task. On a populated project with 10k tasks, 200 of those are
open, there were around 10x improvement on the requests linked to
rendering the kanban view of the project. More elaborate benchmarks are
available in the referenced task.
Reference:
task-3576802
closesodoo/odoo#146168
X-original-commit: 403a7c78f06f6b99233e6fc045bde67f0c670702
Related: odoo/enterprise#52708
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
The view set a domain with `share = False` but the model search for
users with group `group_mrp_user`
closesodoo/odoo#146167
X-original-commit: 25386559629c5e7bbd9decb3fb7ca57ab0ccea18
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Lacking a flush to database before the query used to compute
the gap-in-sequence warning, the gap-in-sequence warning
would stay active even when the all-users lock-date was set.
Which is confusing for the user as they can't do anything about it.
This
- adds the required flushes
- adds a tooltip explaining the warning in more details
as it was deemed confusing
- Adds all the moves that took a sequence number in the query
Task-3613058
closesodoo/odoo#146160
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: Julien Alardot (jual) <jual@odoo.com>
This commit fixes a nondeterministic runbot issue during the survey session
management tour suite (that actually contains multiple tours).
It turns out that the first tour is so short that it does not let enough time
to the web framework to correctly initialize everything before it gets killed
(as the tour steps are completed almost instantly).
It's hard to say exactly where the issue comes from, as the error does not
mention anything (we only know that it's a rejected promise):
"""
Error received after termination:
PromiseRejectionEvent(
isTrusted=true,
reason=Event,
type='unhandledrejection',
target=Window,
currentTarget=Window)"
"""
Removing this first tour also removes the nondeterministic issue.
It seems like an acceptable compromise as this tour was not really testing
anything anyway, we now directly start the session from the python code.
(Note: this issue only started occurring in v17).
Task-3637591
closesodoo/odoo#146107
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Current behaviour:
QR code is squished, it's 77x21 px
Expected behaviour:
QR code should be 100x100 px
Steps to reproduce:
1. Go Email Templates
2. Find 'Event: Registration Confirmation'
3. Click on preview
4. QR code is squished
opw-3625701
closesodoo/odoo#145963
Signed-off-by: Jérémy Hennecart (jeh) <jeh@odoo.com>
Current behavior:
When a reward is applied on an order containing different product with
different taxes, the rewarded is divided in multiple lines (one per tax)
This cause issue when calling, the `_updateRewardLines` method.
Because it will consider each line as a full reward, and therefore will
apply the reward multiple times even though the reward is only applied
once.
Steps to reproduce:
- Create a reward with a discount of 5$ in exchange of 100 points
- The reward should give 1 point per 1$ spent
- Create a product with a price of 100$ and a tax of 10%
- Create a product with a price of 100$ and no tax
- Open the POS and add the 2 products to the order
- Select a customer, and click the reward button
- The reward will be applied 2 times (4 reward lines are created)
opw-3583174
closesodoo/odoo#145759
X-original-commit: 8214322a0f06d74005c46d2623972f6eb393cc08
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Robin Engels (roen) <roen@odoo.com>
Steps to Reproduce:
- install service apps and website
- install website related bridge modules
- install quality and related mrp_subcontracting bridge module
- click on website , click on My account
- click on project ,or timesheet,or tasks,or tickets
Issue:
- after clicking,we will notice that breadcrumb indicates 'title' twice
Cause:
- this is because,in mrp_subcontracting , the title for productions is given
without checking the page_name , so that will affect all the titles.
Solution:
- if we gave condition to check the page name for production this issue is
solved.
task-3607053
closesodoo/odoo#144477
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Steps to reproduce
==================
- Go to users
- Open the export dialog
- Expand the Groups field
- Add the Groups > Groups/Access Controls field
- Check the import compatibility option
- Expand the Groups field again
=> `TypeError: this.knownFields[id] is undefined`
Solution
========
The expandedFields were not reset. We also need to update the t-key to
take the compatibility state into account.
opw-3378834
closesodoo/odoo#146116
X-original-commit: d2f52abb8ce1b7e5291e0de7d4ea7788f39115bd
Signed-off-by: Luca Vitali (luvi) <luvi@odoo.com>
Versions:
---------
- 16.0+
Steps to reproduce:
-------------------
1. In Timesheets, add a new line;
2. link it to a Sale Order project;
3. make it non-billable by clearing the Sale Order Item field;
4. select related project in Project / Configuration / Projects;
5. in Invoicing tab, add yourself and a Sales Order Item, then save;
6. go back to Timesheets;
7. check the Sales Order Item field of the timesheet you created.
Issue:
------
Sales Order Item was changed automatically, this shouldn't happen after
a manual change.
Cause:
------
The `so_line_field` widget used the `this.changeOnEmpty` attribute to
check whether `is_so_line_edited` should be set, but this was removed in
1ecdbfcfbf, hence the field will never be
set when clearing the `so_field` value.
Solution:
---------
On a field change, compare the previous ID of `so_line` with the new ID,
and set `is_so_line_edited` to `true` if they're different.
Related:
--------
odoo/enterprise#52544
opw-3547725
closesodoo/odoo#146062
X-original-commit: bc1ad08286be9bb02d111e49fe095879b649449e
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Levi Siuzdak <sile@odoo.com>
Usecase to reproduce:
- Install purchase and mrp
- On a product set both routes manufacture and buy
- Create a BoM for the product and define a seller
- Sell a unit
- Open the replenishment. Buy or manufacture is set as route
- Go to the settings and set the route not sellected to the smallest
sequence
- Delete the orderpoint and open the replenishment menu again.
Expected behavior:
The new route with smallest sequence is selected
Current behavior:
The same rule is selected and the order used by _get_rule and to
compute the lead time is bypass
It happens because both override of the method are at the same level
(super of stock) and are call arbitrary one before the other.
In order to fix it uses rule_ids that was computed before calling the
function and it contains the real rules used to compute the lead time
closesodoo/odoo#146051
X-original-commit: cad38a349c3486cb199ef8079bdd46cffefd5b2e
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Issue:
======
Front camera doesn't open even if we set it in the configuration.
Steps to reproduce the issue:
=============================
- Install attendance
- Go to attendance/ configuration and put front camera in barcode source
- Use mobile : Go to kiosk mode and start scanning
Origin of the issue:
====================
There was a typo in the props values where we assigned `employee` to
`barcodeSource`
opw-3621239
opw-3608019
closesodoo/odoo#145880
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit the clean_assetbundle could unlink invalid
attachment, mostly when generating a no website assetbundle with
a different version than a website one, the website assetbundle will be
deleted.
Generating a new asset bundle attachment /web/assets/439-b4c80c3/1/web.assets_frontend.min.css (id:439)
Generating a new asset bundle attachment /web/assets/440-3723971/web.assets_frontend.min.css (id:440)
Deleting attachments [439] (matching /web/assets/%-%/web.assets_frontend.min.css) because it was replaced with /web/assets/%-3723971/%%%
The issue is that %-%/ will match 439-b4c80c3/1/ and not only
439-b4c80c3/
Note that it looks like this issue existed for a while but was invisible
because before 16.4 clean_attachment was invalidating the ormcache,
hiding the fact that a still valid asset was deleted and regenerated.
The proposed fix replaces the domain with %-_______/. The unique is
always 7 character long. Note that this change was already made in 17.0
when removing the id from the asset url so this doesn't need to be
completely forward-ported.
opw-3558552
closesodoo/odoo#145452
X-original-commit: 2ac466547e01bfd65415a53ae1efc9d45d9299fb
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Romain Derie
