The payment method line set on the expense sheet isn't the one used
on the payment.
The 'print check' payment method test, requiring
the 'account_check_printing' installation and that module not being
in hr_expense dependencies would fail if both weren't installed.
A new and more method-agnostic test replaces it
Task-3498991
closesodoo/odoo#145017
X-original-commit: c9554cb
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Julien Alardot (jual) <jual@odoo.com>
Before this commit, when adding on a many relational field with an
inverse, the `onAdd()` hook was not triggered on the inverse:
On the inverse, the `addNoinv` and `deleteNoinv` are invoked on
inverse. We forgot to invoke these hooks in these functions.
closesodoo/odoo#144999
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
When a lazy field was computed on-the-fly by a getter and later
the field had its dependencies changed, the field was not
recomputed.
This happens because in this condition, the field is immediately
recomputed, and the code was always clearing the "in-need" flags
when recomputing the field.
This commit fixes the issue by preserving these "in-need" flags
at the end of the update cycle. Note that there's no way to detect
reactive "unread", so a lazy field will keep its "in-need" at least
for an extra update cycle.
Also transition of field flag "on-need" becoming `true` and field
was already "in-need" was not correctly computing/sorting the field.
This commit also fixes this issue.
Part-of: odoo/odoo#144999
Before this commit, when a record was identified by relational
fields, we couldn't insert this record by passing data rather than
the records.
We should be able to insert records and data in the models, so
passing data should be ok.
This commit fixes this issue by backporting some code of improvements
and fixes from master. Note that the internal code of model is
written for retrocompatibility, so some added features like
store.Model in diff is ok.
Part-of: odoo/odoo#144999
Before this commit, the onAdd/onDelete hooks of fields and the
deletion of record was performed immediately. The main drawback was
that `this` and the record being added or deleted from a relational
field was in an intermediate state.
For example, if the record to be added had some computed fields,
the code executed by the `onAdd` hook was reading the field before
it was computed.
This commit fixes the issue by moving the execution of field hooks
`onAdd` and `onDelete` at the end of the update cycle on records,
after the compute methods.
Part-of: odoo/odoo#144999
step to produce :
- go to project
- click on any project in the Kanban view
- click on the quick create button
- notice caret at assignees dropdown
issue:
- at the assignees dropdown the caret position is at the far right and not
aligned with the discard/trash button
Cause:
- changes which happened in task-2944742 added left margin for user_ids field ,
which then moved the position of caret.
Solution:
- changed css to just apply the margin at bottom right for M2M avatar at kanban
and stopped it from affecting user_ids field in quick create task.
task-3506482
closesodoo/odoo#144987
X-original-commit: 519df29285700a33a515d640777745ca6a90fbab
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
When a user creates a journal entry in accounting and the company is empty or
not selected in that journal entry, an error is generated.
step to reproduce -
- install the `Invoicing` & `Inventory`.
- open the `Invoicing`.
- create New.
- open `other info` note page > company (company_id) must be empty.
- the error will be generated.
Error-ValueError:
Expected singleton: res. company()
If the user attempts to remove the company after this commit, they get a
validation error.
sentry-4558397052
closesodoo/odoo#144982
X-original-commit: baa6153bd25a794f432e1a8665098479b33b6e8e
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
When we create public holidays, we can create global ones that will
apply to all 'Working Hours' of the company.
When you create such a public holiday, it is displayed as a an unusual
day for all employees of all companies that have a contract.
The issue comes from the the fact that we use a sudo to get the contract
of the employees and then we call '_get_unusual_day' on the Working
Hours of the contract in sudo. So when we catch the global ones (wihtout
Working Hours) it takes them from all companies as we are in sudo and it
won't apply the record rule.
closesodoo/odoo#144981
X-original-commit: 349762e28461f795d4e8bd3110556b5a80f92d49
Signed-off-by: Pierre Masereel (pim) <pim@odoo.com>
Before this commit:
After clicking one button and then clicking another, the link label didn't
update on the link tools.
After this commit:
The link label now updates when clicking from one button to another.
task-3514717
closesodoo/odoo#144954
X-original-commit: 372c86b70b20ee3992e6376d9b6dba3c3a4b78bc
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Description:
This pull request addresses the inconsistency observed in the rounding behavior of currency rates within Odoo applications and their corresponding PDF outputs. The current implementation leads to a discrepancy that can affect financial accuracy and reporting.
Current Behavior:
In Odoo, when rounding currency rates, the system is set to round up values. However, when these values are transferred to a PDF format, a truncation method is used instead of rounding up. This inconsistency in the rounding method can result in a misalignment of financial data between the system and the generated reports.
Expected Behavior:
The intended behavior is to standardize the rounding process across both Odoo and PDF outputs. By ensuring that both platforms employ the same rounding mechanism, we can maintain data integrity and reliability in financial reporting.
Proposed Solution:
The code modification proposed removes the explicit precision definition on the l10n_ar_currency_rate field. This change will allow Odoo to handle the precision based on the default rounding method defined elsewhere in the system, thereby synchronizing the rounding behavior with that of the PDF output.
closesodoo/odoo#140169closesodoo/odoo#144939
Signed-off-by: Josse Colpaert <jco@odoo.com>
Before this commit, when restarting the synchronization, recurrence outliers were blocking the synchronization restarting because they were being considered as complete recurrences, although they must be treated as single events. Additionaly, when resetting the Outlook account, choosing to delete events in Odoo should not be allowed since recurrence outliers must be treated as single events.
After this commit, this issue is now solved by adding the 'dont_notify' param in the context to skip the validation of single events when restarting the sync. Additionaly, when resetting the Outlook account, the forbiddance of deleting events in Odoo is not a blocking point anymore.
closesodoo/odoo#144928
Task-id: 3617978
X-original-commit: c0e1bbe
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Signed-off-by: Gabriel de Paula Felix (gdpf) <gdpf@odoo.com>
Before this commit
================
Before only error message was displayed, but not the partner's name for which it
was causing error
After this commit
===============
After changes the partner's name is displayed along with the error message
task-3293271
closesodoo/odoo#144915
X-original-commit: 5f1961ef2ca97a4a794685b343bb2236caaa7561
Signed-off-by: Josse Colpaert <jco@odoo.com>
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>
Julien Alardot (jual)