Following this flow on the Media Dialog:
- Type "hell"
- Wait a few ms so that the RPC to search images starts
- Type "o"
- The RPC of before finishes, the o is removed and no new search is done
Before this commit, the search input value of the SearchMedia component
was coming from a "needle" props. This needle prop was a state on the
parent component (FileSelector), set through a debounced handler.
This is not a good design:
- Type "hell": after 1000ms, the debounced handler will be executed with
the value "hell"
- While the handler is executing: type "o"
- When the handler finishes, it has set the needle state value to "hell"
on the parent. This will rerender the SearchMedia with "hell" as a
needle prop, and the "hello" input will be replaced with "hell".
Instead of doing that, the SearchMedia component should have its own
input state, which models the input element.
On that state, we use an effect to call the debounced "search" callback.
This way, the SearchMedia is less dependent on its parent: it only
rerenders when its input element changes.
Additionally, the fetch results are only used if they are the ones from
the last call to `search`.
Dedicated `KeepLast` instances are used for attachments, media library
and unsplash.
task-3060679
closesodoo/odoo#113188
X-original-commit: 08859ca7939454303e34dc39c831ac8f75773c3d
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Co-authored-by: Arthur Detroux <ard@odoo.com>
Co-authored-by: Benoit Socias <bso@odoo.com>
Since we create a google meet link when we create an event, we get an
issue with the appoitments that generate their own videocall links. That
lead to send a Odoo discuss link to the customer, and then set the
google meet link in the sales person calendar.
As the insert of google event is done post commit of the transaction,
and there is no way to generate a google meet link before the creation
of an event, there is no trivial fix to generate the google mette link
at the right moment. We just don't generate the google link when a Odoo
discuss link is already there.
closesodoo/odoo#113192
X-original-commit: 1a1a8e48995cfe37a0c8536bbcfc3341d76499ef
Signed-off-by: Masereel Pierre <pim@odoo.com>
In the sample server, we generate random float values between 0
and 100. The faulty assertion expected the value to be strictly
less than 100, however, it sometimes failed: when Math.random()
generated a value >= 0.99995, it produced 100 as float value.
Runbot error 15206
closesodoo/odoo#113181
X-original-commit: 4abfb9553559080d53bc5a8ba521eec000c56a26
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
The sample server did not create a __range value when grouping by 'date'
This resulted in a traceback as it is expected to at least be false.
This commit computes it properly.
task-3098681
closesodoo/odoo#113163
X-original-commit: cf074f1dc01da39e75aa30e4ac21eafa29d528d9
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, the "create" function of the ORM service didn't
allow to pass multiple records. As a consequence, it was needed to
create records one by one calling the ORM create multiple times or call
create via the method call.
This commit allows to use the create method to create several records at
once.
closesodoo/odoo#111965
Related: odoo/enterprise#37290
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The previous commit has as a side effect to change the value returned by
the create method of the orm service. Here we adapt the code that uses it
and make the test pass.
Part-of: odoo/odoo#111965
Before this commit, the "create" function of the ORM service didn't
allow to pass multiple records. As a consequence, it was needed to
create records one by one calling the ORM create multiple times or call
create via the method call.
This commit allows to use the create method to create several records at
once.
Part-of: odoo/odoo#111965
Before this commit, the reserve and unreserve buttons did not appear
for MOs.
Another bug was also fixed, removed the 0 Inventory on Hand line that appeared
when there are no moves in the report.
closesodoo/odoo#112981
Signed-off-by: Steve Van Essche <svs@odoo.com>
Commit[1] intended to change the color of links in the editor to make them more
visible by making them a slightly lighter color. However, it did so in a way
that also applied to button links, which already had different colors. In the
case of primary buttons, it actually made the links less readable as a result.
This commit excludes buttons from the original css rule so that they keep their
special style while still maintaining the intent of the original commit.
[1]: 47c73c7213
task-3131568
closesodoo/odoo#113141
X-original-commit: a40bca916ac17338d82c52afd7c0eedd96d4a49d
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Current behavior:
When using a language with a comma as decimal separator, the cash in/out
popup wouldn't allow you to enter a "," in the input field
Steps to reproduce:
-Install a language with a comma as decimal separator (e.g. French)
-Open a POS session
-Click on the cash in/out button
-Input doesn't allow you to use comma.
This is not linked to any ticket, I found it while testing the POS.
closesodoo/odoo#113111
X-original-commit: 865513a90713e8486d5bf0c5a547acedab3bd285
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Traceback happens because it doesn't require records and call the
function without row records. The code doesn't handle that case.
Don't try to find unavailabilities in that case and just skip this
part of code
closesodoo/odoo#113104
Signed-off-by: Steve Van Essche <svs@odoo.com>
Before this commit, creating a link through the link tool made two
steps instead of one.
task-3147819
closesodoo/odoo#113135
X-original-commit: d967c21b6abdccd45f3c767925de29e874497dd4
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, when discarding a link in linkDialog, there was a
link and a history step that were created. We now properly come
back to the state of the editor before the linkDialog was opened.
task-3147819
X-original-commit: 79205c8df555d7194d4a8a0ad4f04a9f7dc7f535
Part-of: odoo/odoo#113135
When clicking in a link in the forum, the link dialog was opened.
This is wrong as there the link popover is shown and to open the link
dialog, we must click on the button in the link popover.
task-3147819
X-original-commit: 5c5aa21dffe3691547766cf1f16065ae74c41f07
Part-of: odoo/odoo#113135
For performance reasons, we added a feature that allows to limit
the search_count done when fetching records in list and kanban
views, to display on the right side of the pager [1][2]. However,
the page previous case wasn't correctly handled when we had a
limited count. When doing page, we need to know the total number of
records to compute the offset. Before this commit, we went to the
last page, which wasn't really the last page (because we sent a
wrong offset), which can be misleading for users. With the commit,
we force a search_count when doing page previous on the first page.
[1] 6acfad2651
[2] 699215ec9a71b8c9b6a53fe96e924a400d216729
Task 3162026
closesodoo/odoo#113134
X-original-commit: cefff0dcd5b3b1120b215e6af28d678c7ec34d52
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Since commit [1], we can have list or kanban view with same limit
and count_limit (to save a costly search_count), i.e. have a pager
like "1-80/80+". Before this commit, when reaching the count limit
on page next, we performed the search_count. This was fine before
as the count_limit was hardcoded to 10k, so you basically never did
page next until the limit. However, it's a issue now that the
count_limit can be specified, as in the above example, we don't
want to slow down the loading of the second page records because of
the search_count.
With this commit, we slightly increase the count limit when we
reach it, so for instance doing next when the pager shows 1-80/80+
fetches the records with args offset=80, limit=80, count_limit=160
and the pager then shows 81-160/160+. If the total number of records
is reached, we know the count and display it, for instance, after
another pager next: 161-190/190.
The same logic applies when the pager is manually edited, e.g. when
you write 1-150 in a pager showing 1-80/80+, you'll get 1-150/150+
if there are more than 150 records.
[1] 699215ec9a71b8c9b6a53fe96e924a400d216729
Task 3162026
X-original-commit: d39559274e6de6cdba6972775f9bda8bd2de8fa6
Part-of: odoo/odoo#113134
An IndexError "list index out of range" trace back that occurs in point_of_sale
/RecieptScreen :async _sendReceiptToCustomer was caught by sentry.
order_server_id is undefined because it is not properly sync with the server
step to reproduce:
1. First of all start the session in point_of_sale to produce error we have to
be in offline mode and generate product order.
2. Add customer, select a payment method and validate.
3. After validation send email to customer(failed to send mail.
because we are in offline mode and order_server_id is undefined )
4. Now get back to online mode and again send mail to customer
5. This time an IndexError 'list index out of range' is trace-backed.
So if order_server_id is null then we throw error to user.
sentry-3824163568
closesodoo/odoo#113017
X-original-commit: f7aa70bc0909bea04d6a5c251f966e03ffd44288
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
This commit adapts the translation tests for non-English Numbering
system to rely on the month's numbers instead of names, as the goal of
those tests is to verify that the correct Numbering System has been
applied instead of this specific datetime format.
This is due to Chrome 110+ modifying/fixing month's name translation in
the Intl API, and more specifically the bengalese's test breaking since
this update.
Note: Firefox and Webkit browsers applied similar fixes in their recent
versions.
closesodoo/odoo#113121
X-original-commit: 42b679b9b71bf2b58e0f785c21ef002de6f3ca32
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
The field is updated in SQL but not in cache. Also remove hacks in the
business code to prevent potential issues from this behavior.
closesodoo/odoo#113119
X-original-commit: 8bb660c985c7a1349cae1bf58dc5bf7981bd9058
Signed-off-by: Rémy Voet <ryv@odoo.com>
Signed-off-by: Raphael Collet <rco@odoo.com>
Before this commit, the connection pool works greedily regarding the
number of connections opened. Once a new connection is needed, it is
added to the pool and never closed unless the maximum number of
connections is reached.
We introduce 2 changes. First, we do not cycle on the available
connections anymore. We take the first one available and let it at its
position in the list. It opens the possibility to use
`idle_session_timeout` introduced in PostgreSQL 14.
Moreover, we introduce a garbage collection of the unused connections.
If the connection has been unused for more than `MAX_IDLE_TIMEOUT`
seconds, it is closed and removed from the pool.
This makes easier to overcommit `--db-maxconn` when running in worker
mode. We can set a value which is large enough for the websocket
requirements without the WorkerHttp having a large number of useless
opened connections.
closesodoo/odoo#113110
X-original-commit: 9fcf3de6a9f10d4171bb48feb65fd789db19d4c6
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The field email_from is a computed stored field. Let it compute for
the email_from instead of taking the one from the orginal task
closesodoo/odoo#113107
X-original-commit: 22079d6433d4025f7f92f260bb6f01ba836dcc34
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
The first objective of this commit is to polish the website
configurator:
1) On page 1 of it: - The size of the text is increased.
2) On page 2 of it: - The font size inside dropdown is reduced.
- 30 results are displayed inside dropdown instead
of 15.
3) On page 3 of it: - The size of the text is increased.
3) On page 4: - The cards are refactored.
- The end line is removed.
- The "Build my website" button is moved to the left.
4) On page 5 : - It is now impossible for the user to click on a theme
preview before it is completely loaded.
5) On all pages, the size of the "Skip and start from scratch" button
has been increased.
On the second page of the website configurator, the user has to choose
an industry type. Sometimes, it happens that the user is searching for
an industry that is not known by the server. Before this commit, a
message of type "No result found" appeared and the user had to choose
an other industry among the existing ones. From this commit, the
"No result found" message is replaced by the name of the industry that
the user is writing. To choose its industry type, the user can click on
the displayed industry name or outside of the input area. This last
option calls the `_blurIndustrySelection` function and the written
industry is kept as the final industry choice. If the user chooses an
industry name that is not known by the server then the remaining of the
website configuration is done with the "abbey" industry. Moreover, this
unknown industry name as well as the language used by the user is sent
and stored to the IAP database. The goal of it is to regularly update
the industry list so that it becomes as most complete as possible.
IAP PR : https://github.com/odoo/iap-apps/pull/549
task-3062171
closesodoo/odoo#110187
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit fixes the appearance of the select element in dark mode.
Since the background color is set with transparency, a white background
was set on the options dropdown by desktop browsers, which made the
text difficult to read. By adding a color to the options, we can fix
the appearance without the need to put a color without transparency
on the select elements.
task #3147138closesodoo/odoo#113106
X-original-commit: 194a6506a933665cc47ca96d976a0aa304eb864c
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Luca Vitali <luvi@odoo.com>
Before this PR, we wanted remove the possibility to create account on the fly. However, we thought it would be better to allow people to create and edit an account from the tree view.
closesodoo/odoo#112866
Task-id: 3188348
Signed-off-by: William André (wan) <wan@odoo.com>
For the Knowledge module, we would like to allow the user to fully
customize a graph view and let the user insert the graph they see in an
article. When loading the graph view from an article, the system can not
currently restore the following settings:
- For the bar chart and the line chart: The system will not able to
restore the "sorting order" and the "stack option" set by the user.
- For the line chart: The system will not be able to restore the
"cumulative option" set by the user.
This commit will ensure that these options can be specified from the
context of the view. The context configuration will have a higher
precedence than the configuration stored in the metadata of the model.
When the user will open an article containing a graph view, the graph
view will automatically load the options that have been set by the user
when inserting the view. The user can thus create their own dashboards
by customizing the graphs and inserting them in an article.
task-3056268
closesodoo/odoo#112600
X-original-commit: 458bf22c7e275b7893505bb39c16073a9f63b9ca
Related: odoo/enterprise#37046
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Currently, there are a few mistakes in the standard view props definition:
1. To check the type of each element in an array, the prop definition has
to include an "element" entry. In the standard view props definition, we
included an "elements" entry which will completely be ignored by the
schema validator of owl in debug mode.
2. The "element" entry is only used when the `type` entry of the prop
definition is `Array`. We will therefore simplify the property definition
and remove the "element" entry for the props that are not arrays.
3. The `orderBy` definition of the standard view props mismatch with the
`orderBy` definition of the `WithSearch` component and the search model.
This commit will fix that inconsistency for all those components and
update the tests and the JSDoc accordingly. It will then be possible to
set the `orderBy` value from the props of the `View` component without
getting an error in debug mode.
task-3056268
X-original-commit: 4911e6cd366eadc60923940364274b30372e1584
Part-of: odoo/odoo#112600
Before this commit:
If we do a payment in COP (Colombian currency) with a 2 decimal price,
For example: $ 1.23
The signature generated by Odoo to PayULatam will be wrong.
This will lead to an Internal Server Error caused by the `ValidationError`:
`PayU Latam: Invalid sign: received %(sign)s, computed %(check)s.`
Note that the issue does not happen on version 14.
By cross comparing with the version 14, the issue don't happen there
as the signature sent by Odoo at the beginning of the transaction is
different.
For some unknown reason the code was changed in version 15 to round it to the
first decimal and this looks to be the cause of the issue.
So, in fact the signature that Odoo send at the beginning of the transaction
looks to be wrong and this ends up modifying the signature that should be
generated on the return of the transaction
Version 14 code to compare with:
https://github.com/odoo/odoo/blob/bbb987edff769a825f7617d24314ec7d79e29c40/addons/payment_payulatam/models/payment.py#L41
After this commit
No internal server error and the transaction is validated correctly
opw-3018628
closesodoo/odoo#113059
X-original-commit: 106560e211fb02cedc6dd640effee2d97fb590f0
Signed-off-by: Loan (LSE) <lse@odoo.com>
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Steps to reproduce the bug:
- Enable “multi routes” and “wave transfer in the settings
- Go to warehouse:
- Incoming shipments:
- Select 3 steps
- Create two storable products “P1” and “P2”:
- update their qty
- Create a purchase order:
- Add “P1” and “P2”
- Confirm
- Go to the picking:
- Set qty done only for “P1”
- Validate the picking and create a backorder
- Go to inventory > Operations > Transfers:
- Select the internal transfer from input to quality control
- Action > Add to wave
- A new wave transfer > select the move for “P1”
- Add to wave
Problem:
The operation type is not set on the wave transfer
opw-3112142
closesodoo/odoo#113054
X-original-commit: daed921acacd22f45d95357e131ea11654d73766
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Before this commit, name_get of the res.partner model could return
the partner's name + its address but with empty lines if some address
elements were not set.
Now, these empty line are removed which makes the address cleaner.
closesodoo/odoo#113039
Task: 2759019
X-original-commit: c3745be816b1bf9ecd38184307452f93326ef36f
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Following the introduction of field invoice_filter_type_domain in rev
bc131c0cfb, the override using values in
the context is no longer necessary.
closesodoo/odoo#113093
Signed-off-by: William André (wan) <wan@odoo.com>
For performance reasons, the grouped kanban view automatically
folds groups when they are to many, s.t. at most 10 groups are
open by default (because for each one of them, we must perform
a web_search_read rpc to fetch their records) [1].
However, during the convertion to owl, we broke half of this logic.
The qunit test introduced by [1] simulates a read_group that only
sets the __fold key to true in folded groups, but doesn't define it
in other groups. This test passed. But the logic in the model
didn't correctly handle the case where the __fold key was given for
all groups, even when its value was set to false. This happens for
instance in the project task kanban view.
This commit fixes the issue.
[1] https://github.com/odoo/odoo/commit/fa4c650b01dc184041c61d9d52299b0b740a83bd
Task 3191948
closesodoo/odoo#113061
X-original-commit: dd71662cc994fb8716cae63944b4df9d4201dcdc
Signed-off-by: Georis François (fge) <fge@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Using the web_editor html field in the Record component causes crashes.
Why does this happen?
The fields used in the Record component do not always have modifiers.
Solution:
Use the isReadonly function of the record to know if the field is
readonly or not.
closesodoo/odoo#113072
X-original-commit: 5354321877b65d577c419255ce43806f648e1708
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, in a form dialog view, clicking on an action button
in the header does not save the record being edited. The record is reset
in case a new record is created.
How to reproduce:
- Go to a form view with a non-editable m2m
- Click on add a line
- Click on Create
- Edit the new record
- Click on an action button (the arch must contain a <button> in the <header>)
Before this commit:
The record is reset. All encoded data is lost.
After this commit:
The record is created in db and we keep all the encoded data.
closesodoo/odoo#113063
Taskid: 3165983
X-original-commit: 52fdfe0b26941718bf1532e517a51de38cacfdbc
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps to reproduce the bug:
- Drop a "Table of Content" snippet inside a page.
- Drop a "Facebook" snippet inside the "Table of Content".
-> The page is blocked.
This may happen with other snippets than the facebook one (e.g. the
image gallery or the countdown).
A mechanism that interests us here is the mutation observer. Up to this
commit its goal was to regenerate the navbar of the TOC when its DOM
content changed. In practice, since [1], a "widgets_start_request"
message was triggered up each time there was a change of the TOC
content. In the case of the Facebook snippet, this behavior led to an
infinite loop. Indeed, when the Facebook snippet was dropped inside a
TOC, its content changed so a "widgets_start_request" was triggered up.
This message led to the execution of the start function of the TOC but
also of the start function of the Facebook snippet. Because there is a
change of the DOM in this last function, the mutation observer
triggered up a "widgets_start_request" message again that caused the
program to loop forever.
The goal of this commit is to regenerate the content of the navbar only
when its content changes. To do so, the content of the navbar before
the change of the DOM is compared with its content after the change of
the DOM. If those two contents are different, it means that the navbar
should be updated. Thanks to this commit, it is now possible to add
dynamic snippets such as "Facebook" or "Countdown" inside the TOC.
With this in hands, another bug appeared:
- Drop a "Table of Content" snippet inside a page.
- Drop a "Text-Image" snippet on the page but not inside the TOC.
- Drop a "Countdown" snippet inside the "Text-Image".
- Drag the entire "Text-Image" snippet with "Countdown" and drop it
inside the TOC.
-> The page is blocked.
This bug comes from the fact that the drop of a snippet that stands on
the page inside an other snippet leads to the destroy and the restart
of the option of the outer snippet. However, in our case, the mutation
observer was still listening to DOM changes even after the destroy of
the snippet option. This led to parasite function call. This bug is
fixed by disconnecting the mutation observer when the option is
destroyed. Note that this is done in [2] as this was a problem in older
versions as well.
[1]: https://github.com/odoo/odoo/commit/a05f782871c61b2d58ca2fd4277cb7aed65a301d
[2]: https://github.com/odoo/odoo/pull/112960
task-3122249
opw-3164969
opw-3173006
closesodoo/odoo#113070
X-original-commit: 9139b27ee9216f4b6111d0596f101d4927b493b2
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
A DOM observer is initialized at the start of the table of content
(TOC) snippet options but is never disconnected. This could lead to
memory leak. The goal of this commit is to disconnect this observer and
stop intercepting the changes of the DOM at the destroy of the snippet
option.
Related PR: https://github.com/odoo/odoo/pull/110860closesodoo/odoo#113075
X-original-commit: 3787599479d2f1e951bca6622c7049b62d631795
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
In the EAS list, the United Kingdom code is set to 'UK' while in Odoo,
it should be 'GB'. Because of that, the UBL Bis 3 format doesn't appear
in the journals for GB companies.
opw-3169038
closesodoo/odoo#113069
X-original-commit: 82591bb59edee81eca0db21bc44280b1c231ae0e
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Signed-off-by: Julien Van Roy <juvr@odoo.com>
Positive Lookbehind regex syntax is currently not supported yet by
Webkit, and thus Safari (both on macOS and iOS) resulting into a crash
as the syntax is not recognized.
This issue affects both frontend and backend.
This commit fixes it by reimplementing the feature without using this
syntax.
closesodoo/odoo#112985
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Forward-port of #94947 for 16.0+
closesodoo/odoo#112935
X-original-commit: ee3404603af8a38e21b922c39aa36a6b1e17b44d
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
This update conatins the following commit:
- [IMP] devtools: provide access to Fiber and RootFiber
- [FIX] props validation: do not subscribe to props keys
- [FIX] reactivity: only show key in subscription if observed by callback
- [FIX] components: stop rendering stale t-component when delayed
More details at: https://github.com/odoo/owl/releases/tag/v2.0.6closesodoo/odoo#113041
X-original-commit: fd67ca5d2aaa9683ac1e4667e76fc4230d5d62c6
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
To reproduce
=============
- on settings upload a custom background on document layout and save it
- open document layout again and try to download the image -> Traceback
Problem
=======
when calling download method we will ask server for a record with `id=false`
which gives an error
Solution
========
download button shouldn't be visible when `record.resId == false`
opw-3138230
closesodoo/odoo#113029
X-original-commit: 2e2cdee563dd645cabe2d361489d6eb17b174a33
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, the bus service test "tabs share message from a
channel" was sometimes failing. This is due to the fact that it was
only waiting a `nextTick` to receive the message but the message is
not guaranteed to arrive within a tick. Indeed, the message is first
sent from the worker `MessagePort` via `postMessage` then triggered
on the event bus via `dispatchEvent`.
closesodoo/odoo#113008
X-original-commit: a8d25a89a9fbdb9d51926df2c33c1f4b5eba9b3f
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Stockbauer Matthieu (tsm) <tsm@odoo.com>
Commit [1] removed the protection around the call to setDirty because setDirty
is always defined when the field is initialized through the standard field.js
mechanism. However, in todo_list.js in hr_payroll, the html field is called
without going through that mechanism, resulting in the prop being missing and the
call to fail with a traceback.
This could be fixed by adding the missing prop to todo_list.js, but other people
are likely to do the same mistake in the future so adding a default of our own is
probably better to avoid future similar bugs.
[1]: https://github.com/odoo/odoo/commit/f56e3bca2456f04616982a9a0e77b8d4c5a0abffclosesodoo/odoo#112994
X-original-commit: a6043b3aa290d6cecaabc02995e490f44cbd6ce2
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The default font size of the frontend is 16 so the `default` option
in the font size dropdown was supposed to be enough for this use case.
However, this is not true in the context of website_blog where the
default font size of blog content is not 16. This is not a problem
because if the user does not like the default blog font size then
they can change it using the font dropdown... except they have no
way to select 16 for a size and `default` doesn't mean 16 in blog.
This commit adds an explicit entry for 16 in the font size dropdown.
opw-3110711
closesodoo/odoo#113011
X-original-commit: a35679d5a30e3931216c65ff4ea896e507ba4cf1
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
With Rounding Method set to 'Round Globally'
Create a Quotation with 2 lines:
- Price 6.7, Tax 15%
- Price 6.7, Tax 15%
Total is 15.41, Tax amount 2.01
When sending the quotation via email or in list view the amount total
shown is 15.42.
This occurs because:
- order total is computed as sum of the lines `price_total` field,
which, defined as Monetary, store already rounded values
- line total is computed via `_compute_taxes`, where
tax amount is always rounded per line
opw-3113851
closesodoo/odoo#113026
X-original-commit: c677f45dcb050ce7e6f755b71e56c9b9120bf613
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
To reproduce the issue:
- Website > Add menu items to activate the "+" dropdown.
- Edit mode > The top menu disappears.
On `_activateContenteditable()`, The `initAutoMoreMenu` > `_adapt()`
mutations (changes to move the overflowing menu items to a "+" dropdown)
are recorded and rollbacked by the editor, leading to reset the top menu
to the step before removing the `.o_menu_loading` class.
Recording the `initAutoMoreMenu` mutations leads to some other issues:
On edit mode (without overflowing items):
- Website > Edit mode > The editor starts (before any updates) with an
extra "history step".
- Undo > The top menu disappears.
On edit mode (with "Mega Menu" items):
- Website > Edit mode > Edit text in a "Mega Menu" item > The top menu
disappears.
The goal of this commit is to fix this behaviour using the
`renderingClasses` filter (added in [1]) to prevent the `o_menu_loading`
class from being taken into account in the `filterMutationRecords()`.
[1]: The https://github.com/odoo/odoo/commit/1c25ddb42393b136cac2a0ee0b9b7280fd803e7d
opw-3146873
closesodoo/odoo#113016
X-original-commit: 96c9ebd26aabc3f99acf5d586746b05db7cf4953
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
When using the composer in batch and comment mode, the first record of the
batch was used to find the language for notifications instead of the one
linked to the message.
Previously to odoo/odoo#99482 batch comment mode was not supported and there
were always only a singleton as record ids. Now that it is supported we have
to be more careful when dealing with IDs.
To solve this issue we check the message res_id which effectively contains
the correct record ID.
Oversight of odoo/odoo#99482
Task-3035101 (Mail: Support batch-posting from composer)
closesodoo/odoo#113015
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
