Steps:
- Open Appraisals
- Go to Skills
- Add new skill
- Progress-bar was left-aligned in both rtl and ltr mode
Issue:
- progress-bar should always aligned to the right (it should be to
the left only in rtl mode) in list view.In rtl mode, white space coming
before progress-bar.Progress-bar with different percentage values
was not aligned.
Cause:
- the progress bar alignment was inconsistent, especially when dealing
with RTL languages.
Fix:
- By justifying the content of progress-bar to flex-end and of rtl mode to
flex-start Applying min-width to progress-bar value.
Task: 3525850
closesodoo/odoo#145094
X-original-commit: 52a90d638b79f313c6803b09e54b721eeee2e2fa
Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com>
Signed-off-by: Prakash Prajapati (ppr) <ppr@odoo.com>
On a company with branches, you can move an amount from a branch company
account to a parent company account using "Move to Account" action. This
will create a new entry with both accounts. If this entry is created on
the parent company, it will trigger an error since parent company does not
have access to branch company accounts.
Steps to reproduce
- Have a company with a branch company
- Create an account belonging to the branch company
- Create an entry with this account
- Select parent company and go to journal item list
- Select one item with the account created above and use the
action "Move to Account"
- Try to move to an account of parent company => Company access error
Now we create the entry on the lowest child company.
opw-3554088
closesodoo/odoo#145076
X-original-commit: ad43eb54104671a606d1d8b142df2154e86678bf
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Thomas Beckers (tbs) <tbs@odoo.com>
Before this commit, pasting html content that had been copied from the
the Editor failed to paste any content when inside an iframe.
This happened because the DOMPurify library was not configured to use
the iframe's window for Node prototypes, which led `instanceof` checks
to fail, removing nodes a result.
Additionally, commit [1] did not do the job completely: while the
document for creating the document fragment became the one received as
parameter, the DOMParser constructor remained the one from the window in
which the JS code is executed, which might be different from the
received document's window. This mismatch happens in particularly when
the editable is inside an iframe.
task-3575496
[1]: https://github.com/odoo/odoo/commit/c74d01279e49fadc5f509cfc3f6baf43d2b532d1closesodoo/odoo#144744
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
To reproduce
============
on time Off -> allocations, open a record and try to open studio
-> Owl Traceback
Problem
=======
the ButtonBox is not well compiled, we check if it has children
using `!el.childNodes.length`, but this property returns the total
number of child nodes, including text nodes ...
So counting text nodes, we proceed to create ButtonBox node and fill it
with children `for (const child of el.children)`, but the property `el.children`
doesn't take into account text nodes, which leads to return `''` then a null object
Solution
========
as we loop on `el.children` the check must be done using the same property.
opw-3603952
closesodoo/odoo#145080
X-original-commit: e9e8626c7dabd2d0ba51390279e5adb1eb3aef6f
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This traceback arises when the user tries to post multiple
expense sheets of different employees.
To reproduce this issue:
1) Install 'hr_expense'
2) Open 'Expenses/Expense Reports'
3) Select multiple expense sheets of different employees
4) Make sure the selected recordsets status is in 'Approved'
5) Now click on the 'Posted Entries' button
Error:- 'ValueError: Expected singleton: hr.employee(10, 7, 15, 11, 6)'
https://github.com/odoo/odoo/blob/655c408d319a14cc9b972d4f49816c91fb502b22/addons/hr_expense/models/hr_expense.py#L1474-L1475
After applying this commit will resolve the issue by looping the recordset.
sentry-4595012933
closesodoo/odoo#144137
X-original-commit: 840fa66433be5a3e7c8b34c06d6dadf6e8496013
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Signed-off-by: Altaf Shaik (alsh) <alsh@odoo.com>
In an effort to make the module more accessible
in its target country, add translations to the
module. This mostly concerns error messages.
Task id # 3570055
closesodoo/odoo#145116
X-original-commit: 8b504af3226ed1e2581e19736a7f7675aa7a30ee
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Somehow the module disappeared from the file between versions 16.0 and
saas-16.1 even though the .po files exist (up to + including saas-16.2).
Further investigation/fixing will occur later on to check overall
consistency correctly, this commit is only a quick fix to get the
translations working properly for this specific module.
closesodoo/odoo#145044
X-original-commit: d1dfb5085b2d5c21485e75e0eb9e0c43b7e2c079
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Current distribution of taxes is not correct
- 461411 is a current liability account (expressing VAT due)
- 421611 is a current asset account (expressing VAT deductible)
Example distribution as it is:
- grid 459 expresses VAT deductible
- grid 712 expresses VAT due
Hence, the current configuration of all IntraCom taxes is inconsistent.
Essentially, the taxes need to be swapped between these accounts.
task-3619708
closesodoo/odoo#145025
X-original-commit: 3d466638e614e26e0cb3066981bb8bdcf4a767a1
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Aliya Tastemirova (alta) <alta@odoo.com>
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>
Saiyed Irmi