Issue:
When using the command palette to assign an user to a task, a
"spinning wheel" animation may show up even when everything seems to
have been loaded.
Steps to reproduce:
- Install Project
- For testing, add a `time.sleep(5)` in the
`_name_search` of `'res.users'` to simulate a slow `name_search`
(instead of populating).
- Open your browser's networking tab.
- Open a form view of a task, press Ctrl+K, Alt+I
- Start typing an user name
- Notice that all `name_search` requests are being processed, even
if only the results of the last one are used. You may also notice
the loading animation on the client.
Cause:
When using the cmd palette, when typing an user name, we are
sending RPC requests to the `name_search` of the `'res.users'` model.
The issue is that the requests are not aborted when it is
superseded by a new search value. This can lead to issues in a
large database where short search strings matches too many records,
therefor is generally slow. This can confuse the end user, as a
"spinning wheel" can show up, but the result are already present
(because a subsequent request gave back results faster than
the previous request, which is often the case because a more
elaborate search value matches less records, therefor is faster for
the DB to process). This use case also hogs workers uselessly for
results that are going to be ignored.
Fix:
Store the last running RPC and abort it when making a subsequent
call to it with new search values and the request hadn't complete.
Affected versions:
16.0 up to master = saas-17.1
Reference:
task-3532458
closesodoo/odoo#144900
X-original-commit: 2391d7ffc3dfe760c1ba75b7b2cbbedebff5f347
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
Before this commit, when the link dialog was opened in order to edit an
existing link, the label shown in the preview section was the link's
URL instead of its label.
This happened because `_adaptPreview` (called by `start` -> `_setUrl` ->
`_onURLInput`) was called before the label input field was set (and an
empty value defaults to the link's URL).
task-3563608
closesodoo/odoo#144884
X-original-commit: 6540d5feac2fd8f4a9650288e10e3c264101fa8a
Signed-off-by: Nicolas Bayet (nby) <nby@odoo.com>
Signed-off-by: Rodolpho Cammarosano de Lima (rcdl) <rcdl@odoo.com>
Before this commit:
The table menu is appended directly to the body, causing issues when scrolling.
This results in the table menu toggler scrolling through the navbar, and the
position of the table menu toggler does not update on during scrolling.
After this commit:
The table UI and the editor are siblings, it eliminate's any z-index
issues. Additionally, the position of the table menu toggler is updated during
scroll.
task-3429097
closesodoo/odoo#144863
X-original-commit: f88d190a0de6328cd8dc8872be07c51f76935c3a
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Before this commit:
When tableUiMenu is visible and we try to delete the table then tableUiMenu
stuck after table deletion.
After this commit:
Now after table deletion tableUiMenu also hide.
task-3429097
X-original-commit: 951dc35e17dfa9fbbb8906afbec82216c63e7d11
Part-of: odoo/odoo#144863
Before this commit:
If you select more than one trigger field on base.automation:
File "/home/odoo/src/odoo/17.0/addons/base_automation/models/base_automation.py", line 302, in _compute_trg_field_ref__model_and_display_names
relation = automation.trigger_field_ids.relation
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1146, in __get__
record.ensure_one()
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 5819, in ensure_one
raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: ir.model.fields(<NewId origin=3241>, <NewId origin=3238>)
After this commit:
trg_field_ref_model_name and trg_field_ref_display_name are only used for the
base_automation_trigger_reference widget, which is only used when trigger in
['on_stage_set', 'on_tag_set']. We only need to compute them in this case,
and there will be no errors since they use only one trigger field.
opw-3607314
closesodoo/odoo#144810
Signed-off-by: Florent Dardenne (dafl) <dafl@odoo.com>
In the past, it was possible to drop elements in non-editable areas.
Commit [1] fixed the issue but then commit [2] added a solution to be
able to edit a media element that is in a `o_not_editable` environment.
Unfortunately, the solution makes it possible to drop elements next to
the `o_editable_media` elements ignoring the editable context (ignoring
the first fix).
Steps to reproduce the issue:
- Enter website edit mode
- Drop a Team block in a page
- Click on the Team block
=> The user is able to drop a "Text highlight" block next to the team
member pictures.
This commit
- reverts the commit [1] because in the meantime, the commit [3] fixed
the issue.
- fixes the Team block issue.
- fixes the filterFunc for the drop-in.
- adds a test to ensure the issue doesn't come back.
[1]: https://github.com/odoo/odoo/commit/67924648676b37898aedd86bc32868299aee542c
[2]: https://github.com/odoo/odoo/commit/580f1b77ce0b96b7efbf83a0ccdf6979bbf0e904
[3]: https://github.com/odoo/odoo/commit/ae7452f18dbd6ed56dbf883ae8495382b336aa78
opw-3536227
closesodoo/odoo#144806
X-original-commit: 9b4c2498b8fa2bc0aca604b6256e6c805b9b4c10
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
The `noCheck` param of the `_computeSelectorFunctions` function should
permit to ignore the (not)editable environment. However, since
[this first commit] the `o_editable_media` class alter the behavior
despite the `noCheck` param which is not what we want. Even worse,
[this second commit] check the `o_not_editable` class and the
contenteditable attribute despite the `noCheck` param. This commit fixes
that by restoring the original behavior of the `noCheck` param.
[this first commit]: https://github.com/odoo/odoo/commit/580f1b77ce0b96b7efbf83a0ccdf6979bbf0e904
[this second commit]: https://github.com/odoo/odoo/commit/56e75ed063b0ae98b9824c0ba00633e529701242
Related to opw-3536227
X-original-commit: 19b269fb2cf7d2abc99d321ef98a1d9d19074e78
Part-of: odoo/odoo#144806
In v17.0, the test TestUiPublisher.test_course_publisher_elearning_manager of
website_slides fails randomly at the step: "eLearning: check uploaded pdf
presence and perform comparison" with the error: "Cannot read properties of
null (reading 'getAttribute')"
How to reproduce it ?
Locally, TestUiPublisher.test_course_publisher_elearning_manager of
website_slides runs without errors but when executing it in the browser we
get the same error as the runbot systematically:
– Install website_slides
– Go to shell mode and execute the setup of the test
– (Backup DB if you want to run the test multiple time)
– Launch in normal mode and connect with demo user
– Go to URL: /web?debug=assets%2Ctests
– Type “odoo.startTour('course_publisher_standard');” in the console
– An error happens at step “eLearning: check uploaded pdf presence and
perform comparison”: Cannot read properties of null (reading 'getAttribute')
(to avoid to wait too long, you can shorten the test by keeping mostly
“addPdfToSection”)
The problem occurs because the rendering of the iframe o_wslides_iframe_viewer
is not always completed when the check is triggered.
We solve this problem by waiting for the rendering to finish before performing
the test (using "await contains"). For safety, we do the same for another check
as this might cause a similar problem in the future.
Although the test has been introduced in 16.2 (see odoo/odoo#117293) but the
error happens only in 17.0 (tested only in 16.4 the way described above), we
publish only the correction in 17.0 and further to avoid different correction
in various version.
Task-3623736
closesodoo/odoo#144719
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
This commit fixes small issues when there is not selectedLine in some cases.
We also add the price_without_discount for the printing because of some localisation issues.
closesodoo/odoo#144323
Related: odoo/enterprise#51768
Signed-off-by: rhe-odoo <rhe@odoo.com>
Signed-off-by: Adrien Guilliams (adgu) <adgu@odoo.com>
When dragging a snippet inside an iframe, after the snippet has been
dropped, all events are still being captured by the iframe.
This leads to option previews not being displayed and the user having
to click outside the iframe to be able to interact with the options.
This seems to be a bug in Firefox related to how it handles
pointerevents. This does not happen when the events are "mousedown" and
"mouseup" instead of "pointerdown" and "pointerup".
So this commit checks if we're on firefox desktop and if its the case,
uses mousedown and mouseup.
Steps to reproduce:
- On Firefox, go to the Website App and drop a banner snippet
- Click on one of the images in the snippet
- Drag the image
- Hover over the options
=> The options are not previewed
task-3607685
closesodoo/odoo#143343
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
In [1], jQueryUI drag and drop was removed and replace by an in-house
solution.
This version introduced a difficulty when dragging and dropping content
when the dropzones are overlapping. This commit tries to mitigate that
by always choosing the dropzone that is the closest to the helper
element displayed when dragging.
[1]: https://github.com/odoo/odoo/commit/7594d71ca8610d5947e80f325ccb57abc23c2c76
task-3577109
closesodoo/odoo#143167
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
*: im_livechat.
Since 17.0, the new message separator is displayed for guests. The
`set_last_seen_message` rpc is also triggered in order to save this
information on the server side. However, the `_channel_seen` method
does not handle guests as it should.
As a consequence, the new message separator is always displayed and
the rpc call is always done when a guest loads the public page.
This PR enable guest support for this feature. Not that for live chat
channels, visitors cannot access the operators seen infos.
task-3603603
closesodoo/odoo#142546
Related: odoo/enterprise#52118
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Simplify the workflow in Spanish PoS regarding simplified invoices.
- Setup a default journal for simplified invoices.
- Label of Simple Invoice Journal was displayed even on non-spanish companies.
- Adds an error if you try to create an order without invoice when the amount is too high.
- Enforce our conventions on the compute names and file format.
- Add translation files.
closesodoo/odoo#142345
Task-id: 3598884
Signed-off-by: Josse Colpaert <jco@odoo.com>
This commit allows the navigation inside the Control Panel to fill all
the container height.
Prior to this commit, the navigation arrows inside the control panel
were not taking the whole height of the container, which would cause a
weird visual render where everything would have exactly the same height
except these elements.
To fix the issue, we adapt some of the flex properties used in the
layout, ensuring everything is well aligned.
task-3580216
closesodoo/odoo#140670
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Steps to reproduce:
1. Create a BoM with a component of 1 quantity
2. Create a manufacturing order with this BoM
3. Set the quantity to produce to 5 and confirm
4. Set the producing quantity to 3.1
5. Set the quantity done for the raw material to 3.09
6. Mark the MO as done and create a backorder
7. Click 'Unreserve' on the backorder
8. 'It is not possible to unreserve more products of ...'
Before this commit:
`_compute_quantity` is called with the default rounding method,
rounding quantity UP, which introduces reservation inconsistencies.
After this commit:
`_compute_quantity` rounds with the HALF-UP method, preventing
rounding errors.
Also, use the correct UoM in float comparisons.
opw-3601737
closesodoo/odoo#144620
X-original-commit: f6c15e131e253c3780ce6daa53b0cf27f60fa464
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Signed-off-by: Walravens Mathieu (wama) <wama@odoo.com>
When trying to prepare account move line, we are unexpectedly browsing a record instead of the record's ID. This causes
psycopg2.ProgrammingError: can't adapt type 'stock.valuation.layer'
Step to reproduce:
1. Set up product
storable
Average cost
Automated Inventory Valuation
set a standard price e.g $27
2. Create a purchase order for 1 unit in another currency E.g Eur
3. Confirm the purchase order and validate the transfer.
4. Go on the transfer and create a return. Change the return quantity to be more than what received E.g 100
5. Process the return.
6. Go back to the purchase order and create a vendor bill
7. Now try to create a new purchase order and receive the item.
Fix:
pass in vacuum_svl.id instead of just vacuum_svl into _prepare_account_move_line
opw-3555146
closesodoo/odoo#142798
X-original-commit: a5cdbbc3c0a8b617cb6efe151621ad06216e812c
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Controller /groups/<model(mail.group):group> is already in the sitemap,
so it is useless to list all messages. It will explode the sitemap, for
pages that don't need to be really indexed. What we want is the thread,
not one page by message.
And since no domain was set on domainConverter, the most of urls are
just 404. e.g. groupA with msg1/msg2 and groupB by with msg3/msg4 will
generate:
groupA/msg1
groupA/msg2
groupA/msg3
groupA/msg4
groupB/msg1
groupB/msg2
groupB/msg3
groupB/msg4
instead of
groupA/msg1
groupA/msg2
groupB/msg3
groupB/msg4
If we really wanted to index this route, then the domainConverter would
have to be:
```py
'''/groups/<model("mail.group"):group>/<model("mail.group.message", "[('mail_group_id', '=', group.id)]"):message>''',
```
On our production, it removes around 90K entries in the sitemap ~40%
closesodoo/odoo#144938
X-original-commit: 2c90dca02357377301e788d16bbd05d37bd09785
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps:
- Create a ticket with a customer ( it will the email)
- Answer to the mail with Outlook Desktop( a multiple lines break)
- Look at the response in the discuss frame.
Issue:
In the frame there is much more lines break than in the original mail
Cause:
The format of outlook desktop mail before sanitizing looks like this
```
<div class="WordSection1">
<p class="MsoNormal">Test<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Two break lines<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
```
So when parsing it transforms the ``<o:p></o:p>`` in ``<p></p>``
which adds more lines break when displayed.
Solution:
Remove empty ``<o:...>`` and ``</o:...>`` tags which are specific to outlook desktop before.
opw-3089550
closesodoo/odoo#144931
X-original-commit: a3e9db87277771c9801f24a5f52aa73b98a0d879
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Reproduction:
1. Install note
2. Open an existing note and open it again in another tab
3. When you click in one tab, the cursor position in the other one is
always one step behind
Fix: separate the logic between collaboration and appliedCustomSelection
and revert the calling of getCurrentCollaborativeSelection to the place
after _computeHistorySelection
Task-3221119
closesodoo/odoo#144929
X-original-commit: 854ef7df4db577d010bed9a3561c57b3700447d8
Signed-off-by: Nicolas Bayet (nby) <nby@odoo.com>
Steps to reproduce:
- Open Sales App
- Go to any quotation
- Go to the products lines and change the name of the product to be long
- Save the product and go back to the quotation
- Now click on Other information, and then click again in Order Lines.
Note this only happens in Safari, the behavior for other browsers like
Chrome or Firefox is correct. The problem is that word-break property it
seems to not be supported properly by safari. In this case we can use
the word-wrap property instead, with the same value break-word.
opw-3513128
closesodoo/odoo#144893
X-original-commit: 6a72984a0461b60c3f1863c4be28d780bec847c7
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Signed-off-by: Maruan Aguerdouh Mohtar (magm) <magm@odoo.com>
Steps to reproduce:
-------------------
- create a promotion program with the type "Discount code";
- add a rule to trigger the promotion with the code "12345";
- add two rewards;
- go to ecommerce and create a cart;
- apply the promo code.
Issue:
------
It is not possible to claim a reward.
Cause:
------
When we apply the code "12345", we call the `pricelist` method,
which will try to apply the code.
If it's not a coupon and it's not nominative, we create a loyalty card (a coupon)
with a default code (for example: "044d-3364-42d0").
This previously created loyalty card is linked to the current sale order,
which is only fair since we don't want to be able to apply it a second time.
The two rewards are linked to the same coupon and therefore have the same code
(which is right because we can apply only one of these rewards).
This problem doesn't occur with a single reward, because when only one reward is detected,
we automatically apply it when we call the `pricelist` method.
In the case of two rewards, it is possible to select the reward.
This will trigger the `claim_reward` method.
In this method, if we use a coupon with a code (which is the case here, "044d-3364-42d0"),
we call the `pricelist` method with this code.
This will trigger an error, as the code is already in use
with the loyalty card linked to the sale order.
Solution:
---------
When claiming a reward generated by a program of the `promo_code` type,
i.e. in the case of more than a rewards,
don't call the `pricelist` method (which triggers an error due to the code) but `_apply_reward`.
This will apply the reward to the sale order.
A redirect will be use which will remove all "claimable and showable rewards" from this program.
If we want to re-trigger it via code "12345", this will no longer be possible.
Note:
-----
Modification of the view to distinguish between coupons and "Discount Code" programs.
The current display suggests that rewards are coupons (with the same code) that we use,
whereas they are rewards that we can claim.
Furthermore, there's no description of the rewards.
opw-3520137
closesodoo/odoo#144349
X-original-commit: d56b46ccb6c736856af3dd62df8c2c8b99a8eaa5
Signed-off-by: Thomas Lefebvre (thle) <thle@odoo.com>
Steps to reproduce:
1. In the general settings, add the Arabic(العربية) language
2. Install the POS (point of sales) module
3. Go to the administrator's profile and change Preferences > Languages to Arabic(العربية)
4. Open a new shop/pos session
5. Add any product
6. Click on payment(دفعة) button
7. Choose the cash option under the payment method (طريقة الدفع)
8. Select a client (العميل)
9. Click on validate (تصديق)
10. Notice how the items format is incorrect, the quantity and price flipped and unreadable.
Investigation
- when switching to Arabic (an right to left language), the direction of the order line (price and quantity) was still ltr so the price and the quantity were flipped
opw-3580386
closesodoo/odoo#144754
Signed-off-by: Adrien Guilliams (adgu) <adgu@odoo.com>
Signed-off-by: Ali Hassan Youssef (alhy) <alhy@odoo.com>
is_published has been renamed in website_published in e3d2b01 but not in
_track_subtype().
steps to reproduce:
- add a follower to an event, select the two event subtypes on this follower
- check this event on the website and publish/unpublish it
- check chatter, tracking values have been created
- no message have been sent
before this commit:
- subtypes mt_event_published and mt_event_unpublished are not used
after this commit:
- a message is sent when an event is (un)published
opw-3582596
closesodoo/odoo#144912
X-original-commit: 1b94aca1bd00d136e05f2fd2cbbd4691940eea19
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Nicolas Danhier (nda) <nda@odoo.com>
Problem
--------
In ver 16, field payment_state of model hr_expense_sheet uses
_fields[] to get item selection field payment_state of account_move.
This causes the file translation of this module to not accept
the description item of field payment_state
closesodoo/odoo#144861
X-original-commit: 26b16620eeb29dcf73956a5f437c3747bb390854
Signed-off-by: William André (wan) <wan@odoo.com>
Before this commit, when a record is in draft, the chatter message
"Creating a new record..." shown no author.
The intended showing is to display current user as author of this
message. Persona model requires `id` and `type`, the latter to
determine whether the persona is a guest or partner. Only the
id of current user was provided, so it was not enough to determine
the appropriate `Persona`.
closesodoo/odoo#144864
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Steps to reproduce:
- Get the eLearning App.
- Go to an existing course or create a new one.
- Add a new content of type article.
- Go to website preview and to edit this slide.
- Write plain text inside the box of content.
- Go to Fullscreen.
The issue is that we are using `.append()` and this expects that we pass
it an html or a jquery object which is not the case when we just type
plain text inside it, so using `.html()` will allow us to render any
content as HTML.
opw-3265113
closesodoo/odoo#144818
X-original-commit: 34b78a6619888ebbc6e67b5c474260453a7ed84b
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The issue is not easy to reproduce, so the fix is not a guaranteed one.
Estimation: the click on the "send message" buttons happens too early,
and it is either doing nothing, or being immediately reset by another
action that happens at page load.
Adding a little bit of extra delay (in particular waiting for messages
to be loaded) might resolve the issue.
Also back-port code allowing to use contains in tours.
runbot-27847
closesodoo/odoo#144435
X-original-commit: 3b261b6856e935f8fe9d4e23cfddc09df8ff7fdf
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
In order to be published on the chrome extension store, an extension
must provide at least one screenshot and a 128x128 icon.
Until now, the extension assets only contained a 100x100 icon that was
used as 128 and did not contain any screenshot.
In order to ease updates on the chrome extension store, this commit
updates the two icons used by this extension to match the expected
dimensions and adds the required screenshot.
At the same time, this commit updates the extension readme to warn
about ChromeOS limitations (ChromeOS does not support global
commands).
follow-up of task-3612720
closesodoo/odoo#144828
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
Steps:
- Go to website -> courses.
- Make a search.
Issue:
Whatever there are records found or not, on the search button we see "(0) found".
Reason:
In the method responsible of search ``slides_channel_all_values()`` we don't pass ``search_count``
to the dict to be rendered.
opw-3544856
closesodoo/odoo#144781
X-original-commit: c6afb4441c6d416258634ae9c09353e336f50dcc
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce :
- install field service module
- install industry_fsm_report bridge module
- click on configuration
- click on worksheet template
- try to delete more than one record
Issue:
- error while deleting more than one record
Cause:
- because ,this issue is from base while deleting the model id's
Solution:
- if we write condition for filtering manual models and calling prepare_update()
method and then non manual models ,then the issue will be solved
task-3607053
closesodoo/odoo#144761
X-original-commit: 0d9d7e5fd944e3ef6e1c53d63a6aec61da51cbf5
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
The delay translation feature [1], when the website main language is not
English, is not working alongside the HTML Editor.
There seems to be multiple bugs, both in Odoo 16 and Odoo 17 following
jsonb and then delay translation.
A full investigation will need to be done (and tests written for it) for
all possible flows:
1. English DB + Website FR (only)
2. English DB + Website FR (main lang) + Website EN (translated version)
3. French DB + French Website (English is not even enabled on DB)
4. French DB + English website
5. Case 3. + Website EN (translated version)
6. Case 4. + Website FR (translated version)
Also, for each of those flows:
- both the website builder and the HTML Editor need to behaves correctly
(at least not wipe user content).
- both the Odoo records (xml views eg) and user records (new website
page eg) need to behaves correctly.
This commit, for now, disables the delay translation to restore what we
have in Odoo 16.
The whole investigation, fixes and tests will be done after this commit
in both Odoo 16 and Odoo 17.
Step to reproduce (one of the flow, which is problematic for one of our
big client to go in production):
- Have DB and admin in English
- Have FR only on the website
- Enter edit mode on a page (website builder)
- Drag & drop a snippet and save
- Open HTML Editor, add a blank line
- The page content is gone, user lost its page
------- Technical Details about above case ------------
In Odoo 16, before delay translation, in such a setup (FR only on
website), when modifying the html editor, it would have the same effect
as modifying the page content in the builder, because the English
version (not used because website only use the fr translation) would
also receive the website builder changes, both EN and FR would actually
be sync'd in DB.
For this particular case, it kind of worked, but probably not for other
cases like adding english as translation lang on the website where this
lang sync would not make sense.
This "urgent" fix/feature disabling is done because people are unable to
create or maintain website when they use the HTML Editor. Worst, they
lose all their work again and again.
Indeed, it's not yet sure how but module update also wipe user changes
in such configuration in Odoo 17.
All this is based on feedback of our "PS tech" which is unable to go in
production because of those bugs.
-------------------------------------------------------
Related to PR [2] which is the Odoo 17 forward port of commit [3]
introduced in Odoo 16.0.
[1]: https://github.com/odoo/odoo/commit/2d08f97c0778469b409fca23f2be5f5a98ce3df8
[2]: https://github.com/odoo/odoo/pull/144693
[3]: https://github.com/odoo/odoo/commit/f54aa6f58d494bca940a3e575d4092ee386d488c
task-3621753 (where the deep investigation and fixes will happen)
closesodoo/odoo#144760
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When a dropdown open a dialog and on the dialog there is a new dropdown,
before this commit, when clicking on the second dropdown, the first one
will close.
This is an issue with closing the first dropdown, is if the dialog is
opened using useOwnedDialogs, the dialog will also close.
Also, if the dialog is open to throw a "find more" of a x2many field,
even if the dialog is not close, as the dropdown will close, the
original field will also be destroyed and it will raise an error.
Now, we avoid closing dropdown's, when opening new dropdowns that there
are not on the same active element.
opw-3464528
closesodoo/odoo#144238
X-original-commit: 6fec387d258dfd945dbbd48a9aab91ce6113ccaa
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Since https://github.com/odoo/odoo/pull/103510, the read_group parameter "groupby" can no longer contain
implicit duplicates. For example groupby=['date', 'date:month] doesn't work
anymore. Here we remove all duplicates from groupby before making a read_group.
closesodoo/odoo#143792
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
This commit increase the receipt size on the receipt screen and
shrink the new order button to fit the new size.
closesodoo/odoo#143292
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
1. minor mistake, prefix for account move line
instead of line.company_id, use `aml.company_id`
2. syntax error : typecase for `::int =`
to compare parent_path with integer value.
closesodoo/odoo#144764
X-original-commit: 286a911f640351640d60efdf597461055f42f9c5
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Atul Patel (atp) <atp@odoo.com>
There is a specific rule that set the `o_AttachmentViewer_view`
background color to a static white color (i.e. `#FFFFFF`).
Then in dark mode, while the font color for the attachement "view"
is set to white due to the `color-scheme` meta, the background
keeps its white color, which makes the content unreadable. In this
commit we use instead the `$white` variable, which is properly
adapted in "dark mode", for the background color.
Steps to reproduce:
* Open Odoo
* Set Odoo in Dark mode using the dropdown menu of the user
* Open the Note app
* Make a note or open one
* Upload a JSON attachment in the chatter
* Open the preview of the attachment
=> BUG text in white and background color in white => text not visible
closesodoo/odoo#144763
X-original-commit: 2af9edb3ca45db0a36552ca751136b7b0c7b6a18
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
Steps to reproduce:
- Install Accounting and Contacts
- Create a contact (e.g. Contact X)
- Add an Invoice Address to the contact (e.g. Invoice Address X)
- Create an invoice with Invoice Address X as partner
- Confirm it
- In invoices list view, Customer field is "Contact X, Invoice Address X"
- Go to Contacts and rename "Contact X" to "Contact Y"
=> In invoices list view, Customer field is still "Contact X, Invoice Address X"
Cause:
"invoice_partner_display_name" field is not recomputed when the name
of the parent partner is changed.
opw-3597741
closesodoo/odoo#144739
X-original-commit: 3254c4e278d559d4cee41fd2c30c6b26094dd09e
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Anh Thao Pham (pta) <pta@odoo.com>
The sequence is equal to 10 and it is causing issues during upgrade. The order used by the menus is _order = sequence, id
As the menu has a new xmlid, it will be placed after the existing one because if his sequence. We could
1) lower the sequence value
2) don't provide a sequence (menuitem is noupdate False) and update the value in the upgrade script.
Proposal 1 is chosen as it does not require an upgrade script.
closesodoo/odoo#144716
Taskid: 3618126
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Before this commit:
When we try to delete a Meeting type Activity from the technical menu
"Settings > Technical > Activities" it do not delete the associated calendar
event.
After this commit:
The calendar event will be deleted when the associated Activity gets deleted.
task-3493426
closesodoo/odoo#144674
X-original-commit: 71dc58acfcc4589bc5996b48e157aea6b0f8a609
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
The color was only used on the calendar event form view, but it was ignored in
these other views.
closesodoo/odoo#144621
X-original-commit: cab9ccb2f9f4168f03ad97b34e2fb6a7474a53a3
Signed-off-by: Leonardo Pavan Rocha <lpr@odoo.com>
Current behavior:
When printing receipt from an iOS device, the QRCode is not printed at
the good position.
Steps to reproduce:
- Install l10n_sa_pos
- Install an ePoS printer
- Go on an iOS device
- Go to POS
- Create a new order
- Pay the order
- Print the receipt
opw-3560424
closesodoo/odoo#144583
X-original-commit: fe46d3a76d49e7753755d4f6d0bee2c628953d6b
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Robin Engels (roen) <roen@odoo.com>
Very rarely the "project" channel would be created in a different second
than the general "channel", which lead to last interest taking priority
over id when sorting them and unexpectedly putting project first.
runbot-28637
closesodoo/odoo#144580
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Fallback to ID compare when the dates are the same.
Added some extra steps in the test to help further debugging if this PR
does not completely resolve the issue.
runbot-28637
Part-of: odoo/odoo#144580
case:
- create a UoM 'Hundreds' related to UoM 'Units', bigger by factor x100
- create a delivery picking
- create a move with the UoM Hundreds, indicate 10 Hundreds
- validate, 1000 should be reserved
- unreserve, only 10 units are unreserved, 990 are still reserved
This is because the stock move line takes the UoM of the stock move by default on the `quantity` field
and `unreserve` uses that field instead of `quantity_product_uom`
This bug led to the discovery of other cases where `quantity_product_uom` should be used instead of `quantity`
closesodoo/odoo#144574
Related: odoo/enterprise#51964
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Steps:
- Install project app.
- Share project editable to user which has no
task.
- Open that project in project sharing.
Issue:
- No content hepler is not properly showing.
Cause:
- Helper in project sharing action is not markup
even and that action is type object so we have to
markup no content manually.
Fix:
- Markup project sharing helper.
task-3293310
closesodoo/odoo#144516
X-original-commit: 34aa8c46a50ebb0923565594c6c74d15c83756b8
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Steps:
- Open Settings > Users
- Change the name of the user by typing it multiple times
- Open Project > Choose a Project
- Create a task with the assignee as our user
- Now open the Kanban view of the Project, where we have the task stages.
Issue:
- In the Kanban view, we can see the name of the assignee overflowing.
(This same issue is also present in Project Sharing)
Cause:
- The text is not truncated due to which the name overflows.
Fix:
- adding the class text-truncate and d-block to correct it
closesodoo/odoo#144492
Task: 3383519
X-original-commit: 93d0b7bb81cf9c682a46626323f4baee9b808cfb
Related: odoo/enterprise#52012
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
In commit[1] the class `order-3` is applied on the ViewScaleSelector
component but it breaks the view in timesheet. This commit creates a
props to contextually use this class on the component.
[1]: f9222c4976
task-3580643
closesodoo/odoo#140750
Related: odoo/enterprise#50055
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Victor Piryns (pivi)