*: web_editor
Commit [1] made the multiple drag and drop feature of the editor stop
using jQuery and used our own implementation. Unfortunately, the
initialization of that implementation in the case of the "drag column
on image move" feature marked the page as dirty by mistake.
Steps to reproduce:
- Enter edit mode
- Add a "Text - Image" snippet
- Save
- Enter edit mode again
- Click on the image of the snippet (and do not do anything else)
- Click on discard
=> A popup appears to say you will lose your changes... while you did
not make any.
[1]: https://github.com/odoo/odoo/commit/7594d71ca8610d5947e80f325ccb57abc23c2c76
Related to runbot-18747
Part-of: odoo/odoo#148728
*: web_editor
Next commits will extend the main new test to make sure the flows they
are fixing are not wrongfully marking the pages as dirty. This commit
introduces it on its own as it deserved some more detailed explanations.
In 15.0, where this commit is being merged, the final version of the
test was failing for no apparent reason on staging only. This is because
the staging builds are made with more apps... which fill the website
menu with more items in such a way the "+" auto-fold menu feature comes
in play. That feature is marking the page as dirty by mistake in this
version, 3 different ways for 3 different configurations:
- the menu is not folded outside of edit mode and when entering edit
mode, the "+" appears and some menu are folded
- the menu is folded outside of edit mode and when entering edit mode
the resize actually makes it so a different set of menu is folded
- the menu is folded outside of edit mode and when entering edit mode
it stays the same (known to have been broken because edit mode
tweaks the dropdown behavior)
The first problem with this is actually the way we check the page is
dirty in case of discard: we check the whole DOM and compare it to the
way it was when entering edit mode... the whole DOM, including the non
editable parts. This is wrong by definition but it is also weird that it
does not match what is done when we *save*: where we only consider
sections that are explicitly marked as dirty (.o_dirty) and other
exceptions. This can't be changed in stable though, some save / discard
override may rely on this (not marking with the o_dirty class etc).
In 15.0, the original commit of this forward-ported version fixed the
3rd case described above, which was less risky than fixing the 2 others.
The cause for the DOM diff in that case was the `data-toggle="dropdown"`
which mysteriously reappeared between the moment we check the "initial
DOM" and the "DOM when we try to discard". This was because of [1],
which makes the dropdowns behave differently in edit mode, combined with
the fact that the "+" menu is re-rendered after each resize (and one is
triggered when entering edit mode since [2], originally for that
actually). That behavior is however apparently not needed for the "+"
dropdown, so we simply disable it. Some lower level fix is still needed
but will be done in master, as the real problem falls in the dirty page
detection system. A test was added for this specific third case.
In 16.0, this is different: all 3 cases seem fixed, probably indirectly
thanks to the website-in-iframe refactoring at [3] and the bootstrap 5
migration at [4]. Not sure. This forward-port commit thus only adds
tests and a bunch of comments. Note that what was said about the 15.0
version was actually not entirely true: "That behavior is however
apparently not needed for the "+" dropdown, so we simply disable it." is
actually wrong. Indeed, it changed the behavior when clicking *outside*
of the extra items menu (which is less important). A patch in 15.0 will
be backported anyway to explain that.
To make the final test pass, it ensures most menus are removed so that
the "+" feature is basically disabled always during the test. Behaviors
will of course be fixed in further versions.
Note that in this 16.0 forward-ported version, a test kinda already
existed for this... although it was badly written and the code that was
merged with it actually worsened the dirty check behavior. See [5].
This commit adds comments around some more problematic parts.
[1]: https://github.com/odoo/odoo/commit/fe67b34f1a03d838df82a1307cf6467f994a8f3b
[2]: https://github.com/odoo/odoo/commit/392c91cda3133b921e9aca9a7b1c511231027438
[3]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
[4]: https://github.com/odoo/odoo/commit/971e5a91aab96d36129a823e03f1f9f1b1293968
[5]: https://github.com/odoo/odoo/commit/650a97d1bd59254cc2115d54d58940b6112a8d70
Related to runbot-18747
X-original-commit: a0b741a53fef6a2a15d9283397dd7ec22d624382
Part-of: odoo/odoo#148728
This probably does not change much but it short-circuit a bunch of code
when we click outside of an editable zone and something in the DOM
happens. Allows for easier debugging of mutations. It also avoids the
creation of a jQuery object when the mutation is about changing a
contenteditable attribute, I guess any small perf improvement should be
welcomed.
Related to runbot-18747
X-original-commit: f93a2da57e1424898fbf6e157945e2afa97be89e
Part-of: odoo/odoo#148728
The original issue (in saas-16.4) has been fixed in 17.0
by refactorings.
This commit only fw-ports the test
Steps to reproduce:
- Open the Subscription app
- click on the list cog wheel
- Spreadsheet > Insert list in spreadsheet
- Select the blank spreadsheet and insert the list
- right click any cell with a list function
- click on "See list properties"
=> boom `undefined is not iterable (cannot read property Symbol(Symbol.iterator))`
The list domain has the shape `["subscription_state", "not in", ["2_renewal", "5_renewed", false]]`
`false` makes the domain selector crash.
opw 3670344
closesodoo/odoo#148727
X-original-commit: cfdc9c6d62050e3aac4bf18f374e4772ce18a504
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
The jsconfig.json file is used by editors to provide autocompletion
but the paths were not updated when it's used in the enterprise
path.
closesodoo/odoo#148725
X-original-commit: c41824c35f26708bece94a6bb507496a259172c0
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
Before this commit, a Field using the useInputField hook can ignore values
from an onchange in some cases.
Problem:
=======
In order to know if it should apply the value of an onchange on the field's input,
the useInputField hook uses a useEffect which will check if the field is
not dirty (being edited) and if it is not invalid. If it true, it will apply
the value returned by getValue which often corresponds to record.data[fieldName].
By executing getValue, it will therefore start to observe changes in record.data[fieldName]
until the next render. If getValue is not executed then changes applied
by onchange on record.data[fieldName] are ignored because we don't observe record.data[fieldName].
Solution:
=======
Always execute getValue in the useEffect to always observe changes on
record.data[fieldName] and apply them correctly on the input if needed.
(It s a hack but we don't have a better solution for now)
How to reproduce:
================
- Go to a Form view with a field B with onchange and a field A (char field)
- Edit field B (an onchange is in progress)
- Insert a value in the input of field A
- The onchange is resolved with a value for field A
- The value in the input for field A does not change (because the field is in edition)
- Click outside the input for field A (trigger change event)
- Edit field B (an onchange is executed directly)
Before this commit:
The value returned by the second onchange is not visually applied to
field A. The old value is still present in the input.
After this commit:
The value returned by the second onchange is correctly applied to field A.
Its input contains the value of the onchange.
closesodoo/odoo#148711
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The problem was the hard coded `@Mitchell Admin` in the expected result.
The case can be different when the demo data changes.
Change the test and make it fixed in all cases.
closesodoo/odoo#148710
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Currently, when you attempt to uninstall an industry module, you are met
with a 'record not found' error.
Cause
-----
The list of industry modules is fetched from `odoo.com`. Since they do not
exist in the database, they are all assigned an ID of `-1`.
This ends up causing an issue in case of uninstall because no record
with and ID of `-1` can be found.
Fix
---
When a module is installed, it gets a record in the database (and ID).
The fix simply uses that ID if it exists, instead of `-1`.
opw-3662239
closesodoo/odoo#148456
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>
This commit adds the simulcast feature to calls when relayed by an odoo
SFU server, this allows for better bandwidth management by scaling down
resolution instead of losing packets.
closesodoo/odoo#148276
See: https://github.com/odoo/sfu/releases/tag/v1.1.0
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Steps to reproduce:
- Using a company whose currency is USD, make sure to have a rate change with EUR a week before Today.
- Create an analytic plan with Default Applicability set to Mandatory.
- Create an analytic account for the plan.
- Create a Storable Product with a Product Category that has FIFO Costing Method and Automated Inventory Valuation.
- Create a Request for Quotation in EUR using the new product and the new analytic account.
- Confirm it, click on Receive Products, then Validate.
- Go back to the RFQ and click on Create Bill.
- Change the date to two weeks ago (in order to trigger an exchange difference).
- Confirm it.
Current Behavior:
A `ValidationError` is raised in `_validate_distribution()`: "One or more lines require a 100% analytic distribution."
Cause:
This happens because the exchange difference journal items are created without `analytic_distribution` even though they should, since it was set as mandatory.
Solution:
Make sure the `analytic_distribution` is properly set when creating stock valuation lines.
A test is also added to cover this use case.
task-3582164
closesodoo/odoo#147387
X-original-commit: fafcf452c68aad27754a8c9bd7bde1742be61cb8
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
Signed-off-by: John Laterre (jol) <jol@odoo.com>
To reproduce (16.2 and >):
1. Install pos_restaurant
2. Open the Shop pos session
-> "Kitchen Note" button display
=> Unintended as this button does only make sense in restaurant
Before this commit:
The button actually shows due to `iface_orderline_notes` value being
set to `True` by default.
After this commit:
The setting value is unset (for shops) to prevent the button to render
opw-3651750
closesodoo/odoo#148700
X-original-commit: afd9c9faaff9603eb1a11dc79ea3053a1eac98fb
Signed-off-by: David Monnom (moda) <moda@odoo.com>
Signed-off-by: Loan Sens (lse) <lse@odoo.com>
In odoo@98ca5140baf96, a test using a product of type 'product' was
added. Since this type is introduced in stock, stock needs be installed.
Since the delivery module was split in saas-16.2 to remove the
dependency to stock, this test needs to be moved in website_sale_stock.
Build error 48757
closesodoo/odoo#148691
X-original-commit: c517b45eb36b02c2f0679be79da565087c5e48ca
Signed-off-by: Vallaeys Valentin (vava) <vava@odoo.com>
In e0297bd, we fixed the inverse field values of the new record during
the onchange. But we actually filter out inactive records by doing
record[self.name] in _update(). And since the XtoMany field cache
values should always contain inactive records, we need to add
with_context(active_test=False) on records.
Also remove the useless 'if value', value is always truly because it
is always a record.
Note that this solves a performance issue in our production, because
in order to filter out inactive records, we need to fetch the active
field next to every prefechable field.
closesodoo/odoo#148675
Signed-off-by: Raphael Collet <rco@odoo.com>
Before this commit, when trying to remove a format of a
`data-oe-zws-empty-inline` of an empty block, the attribute was added to
that block and would never be removed. Also, unformatting a zws would
not remove the zws from the dom.
How to reproduce the original bug:
- put the selection inside an emtpy p
- ctrl+b (in windows/linux) or cmd+b (in mac)
=> The zws attribute data-oe-zws-empty-inline is added on the P rather
than creating a span.
- The next letter that will be typed will not be bold but should be
bold
- That attribute should not exists in a block, that could lead to
unexpected bug
task-3628480
closesodoo/odoo#148659
X-original-commit: 7b7e343e7b4fd5bab4f41eeead85dedbf2ab717d
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Before this commit:
The editor's code was unnecessarily adding an access token to attachments
created from external URLs. This addition of a query string with an access
token to an external URL made no sense and could lead to issues.
After this Commit:
This commit prevents such behavior by adding a condition to check if the
attachment is created from an external URL. If so, it will not generate and
add an access token, ensuring the integrity of the external URL.
task-3470982
closesodoo/odoo#148646
X-original-commit: e5d464660f29a3b0b2af1c0ed534b63f81f1b10d
Signed-off-by: Nicolas Bayet (nby) <nby@odoo.com>
Signed-off-by: Sanjay Sharma (shsa) <shsa@odoo.com>
issue:
Currently, the project task count in kanban view calculates all closed and
opened task.
cause:
In this commit 03235ae in task count both closed and open task considered.
fix:
In project kanban view we only show task count for open task.
closesodoo/odoo#148641
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit, when a project user shares a recurrent task to an
internal user, the internal user cannot open the form view of that task
because he does not have access to `project.task.recurrence` model.
The reason is because the compute methods to set the recurrence fields
assumed the user has access to that model.
This commit adds `groups="project.project_group_user"` to recurrent fields
to be sure the user has access to `project.task.recurrence` model before
computing the field.
task-3430762
closesodoo/odoo#148636
X-original-commit: c1623c7c8b1a3c5c69a866b55db77e69958e8754
Related: odoo/enterprise#53911
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
thanks to the following PR: https://github.com/odoo/odoo/pull/131369/files
todo tasks are not considered grouped by M2M when grouped by personnal stage
thus the actions are now available, but still export is missing so we're adding it to the allowed actions
Task-3515879
closesodoo/odoo#137239
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
The range widget doesn't work with Serbian language, because language
locale subtag contains `@`.
Steps to reproduce:
1. Activate Serbian Latin language (sr@latin) on your website
2. Go to /shop
3. Switch to Serbian lang
The price ranger slider (which can be disabled) will throw this TB:
"RangeError: Incorrect locale information provided".
The fix is to do as other places in the code: replace this specific
lang code with the expected one.
Ideally, a util method should be used at all those places.
closesodoo/odoo#148593
Forward-port-of: odoo/odoo#148279
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Steps to reproduce:
- Install Purchase and Inventory apps
- Go to General Settings > Purchase > Invoicing > Bill Control
- Choose "Ordered quantities" and Save
- Go to Purchase app > Products > Products
- Create a New product
- Set the product type to "Storable product"
- Go to "Purchase" tab > Control Policy
- Notice how the control policy is "On received quantities" although we set it up to be "On Ordered quantities"
Discussion:
- I added a compute method to manage the default **purchase method** value based on the res.config.setting **Bill Control**.
- I kept the behavior of setting the `purchase_method` to **receive** when the product type is **service** based on [task-2897867](https://www.odoo.com/web#id=2897867&cids=1&menu_id=4720&action=4043&model=project.task&view_type=form) which is associated with the commit **479a38466751e7bc31b26e5635b9735b37dde81f** and [PR](https://github.com/odoo/odoo/pull/96548)
opw-3552786
closesodoo/odoo#148585
X-original-commit: b0ea838364f63d25ca79211d8be5cbf332b6bf70
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Ali Hassan Youssef (alhy) <alhy@odoo.com>
Improve the performances when searching journal entries filtering by
account.
Steps to reproduce:
* Accounting > Accounting > Journal Items
* Use a name search by account, inputting the code. Do not select the
exact account, but keep the name search.
On large databases, this can take more than a minute, while using the id
of the account directly would take only tens of milliseconds.
This is because when using a domain like
[('account_id', 'like', string)]
it will be translated in SQL as a subquery unable to use a performant
index. Therefore the query planner will use other means and filter on
the account afterwards.
The reason it is not able to find a good index despite there being one
is because char fields are using `unaccent` by default, but the index is
a btree.
Since searching for the account with the code
* only makes sense by prefix
* only uses numbers
We can and should actually use the btree index without the unaccent
feature.
closesodoo/odoo#148583
X-original-commit: 78e2b028d6a04638722edf462f970ebeb29a94ac
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Versions:
---------
- 16.4
- 17.0
- master
Steps:
------
1. Have a project with tasks with deadlines;
2. go to My Tasks;
3. open calendar view;
4. select a task.
Issue:
------
The task's project field is empty.
Cause:
------
Commit fb88a7448c added the
`display_in_project` field for tasks. The `project` widget uses this to
decide whether to display the project. As this field hadn't been added
to the calendar view yet, it defaulted to `false`, so projects don't
get displayed.
Solution:
---------
Add `display_in_project` to `view_task_calendar`.
opw-3672339
closesodoo/odoo#148582
X-original-commit: 0139cbeb03c6f36ccb6bddda716e3d43b9fb541c
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Levi Siuzdak <sile@odoo.com>
The digits option was of type string, but it needs to be an array of two
integers.
We introduce a new digits type to handle that case.
This is used in studio, more info in the enterprise PR.
opw-3614919
closesodoo/odoo#148571
X-original-commit: 6dbf59a9db1a68069df7e922fcab673ce7f7ae5a
Related: odoo/enterprise#53865
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
Steps to reproduce:
- Install `survey` module
- Go to survey and open any survey
- Click on 'Test' button
Issue:
Navbar is visible in survey mode (and therefore able to edit the
survey with web editor).
Cause:
At some point, the XML has been refractored and the concerned `nav`
element as been replaced by a `div` element, but the related CSS that
hide the navbar has not been updated.
opw-3369894
closesodoo/odoo#148569
X-original-commit: bd91a88c68c5fb4903791eee1cbb822198d79ca0
Signed-off-by: David Beguin (dbe) <dbe@odoo.com>
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
Currently there are the following bugs when XML-exporting invoices
that are not in company currency and use discounts:
* The discount is computed and exported in document currency.
But it should be exported in company currency.
* The unit price value (excl. discount) is computed wrongly
since it uses the wrong discount value.
This commit corrects the discount and unit price computation / export.
closesodoo/odoo#148566
X-original-commit: 1cc846e8a53fd7c4298b7324d9c4f272592f0497
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Sven Führ (svfu) <svfu@odoo.com>
Before this commit, when an image was cropped in a record on which
multiple users were collaborating, multiple attachments would be created
for the same image (one per user).
Multiple attachments for the same image would also be created if the
user uploaded the same image multiple times in the same record.
This commit makes sure that, when about to create an attachment via the
'add_data', 'add_url' and 'modify_image' routes, if an attachment
already exists for the same field values, the existing attachment is
returned instead of creating a new one.
task-3524601
closesodoo/odoo#148556
X-original-commit: 0e2508388fc03b2ea7a4033e571d289efa4ac479
Signed-off-by: Nicolas Bayet (nby) <nby@odoo.com>
ISSUE
=====
clicks_ratio uses a formula that is not relevant as it accounts
for emails that could not lead to a click. It divides the
number of clicks by the total of expected emails instead of
substracting cancelled ones.
HOW TO REPRODUCE
================
1. Create a mailing M
2. Create a mailing list of 5 contacts with same email adress
3. Create a link tracker associated to M
4. Send -> 4 emails will be canceled as same email is used
5. Click the link.
6. Ratio of 'clicked' on the mailing view will be 20%
instead of 100%
FIX
===
Only use mailing traces where trace status is not 'cancelled';
aligning the formula to other stats set in _compute_statistics.
The formula becomes:
CR = # clicks / (# total_traces - # cancel_traces)
A test on statistics is modified to check this behavior.
Task-3607171
closesodoo/odoo#148551
X-original-commit: 5dc7c6102f1d23ffa02d3b6aff3c518204fb4566
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, when the user was in RTL mode, the row menu UI was
appearing on the right side of the table UI toggler, which would make
it invisible to the user.
This commit fixes the issue by making the row menu UI appear on the
left of the table UI toggler in RTL mode.
task-3664939
closesodoo/odoo#148543
X-original-commit: 25a9c993ff0bdbe30fca1e4306da9018a7ec836a
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Before this commit, the row table UI toggler was positioned on the left
for RTL languages. Since the first TD was on the far right rather than
the far left, it was impossible to click on the row UI. It disappeared
whenever an attempt was made to click on it.
task-3664939
X-original-commit: fbc167bf84340b4bb6d0f8c59f2734814f56c6df
Part-of: odoo/odoo#148543
The border was adding 1px offset that made the o_table_ui children 1px
off.
task-3664939
X-original-commit: cd497d12031bc88c8b62151f432970024ce5ce84
Part-of: odoo/odoo#148543
Currently in calendar views in mobile it is possible to create events selecting
the time of the event by dragging. However, in calendar we also have the action
swiper responsible for moving between weeks when swiping close to the borders.
The issue is that when trying to create events by dragging close to the border
will cause the action swiper to trigger a swipe, therefore switching to the
next week. This commit fixes this by adding a swipeInvalid prop to the action
swiper that will be checked during the touch move event handler. If the
swipeInvalid is executed at any move and returns true, the swipe is cancelled.
task-3635841
closesodoo/odoo#148541
X-original-commit: 7772b17f226ddb99060b51d6b337e5f5106b5c25
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Signed-off-by: Leonardo Pavan Rocha <lpr@odoo.com>
Steps to reproduce
==================
- Set the zoom option on an image field (You can do it with studio
starting from 16.3)
- Go to a record and hover over the image
=> Nothing happens
Cause of the issue
==================
The tooltip is only displayed in readonly,
but with https://github.com/odoo/odoo/pull/100570 ,
the readonly mode has been removed.
So it only applies for views with the readonly attribute.
Solution
========
Always display the tooltip
opw-3646005
closesodoo/odoo#148534
X-original-commit: e0f9a7eedfb91ea46969490cf261548835844907
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
When converting a card for e-mail client compatibility, we apply the
attributes of the card's block children to their respective cells and
unwrap them. However, that's an issue if the child is an image or a link
since their respective `src` and `href` attributes are meaningless on
the cells.
task-3631900
opw-3580317
opw-3630693
closesodoo/odoo#148529
X-original-commit: d3bdb08c97ad7eab005ac185f393807df35f383e
Signed-off-by: Nicolas Bayet (nby) <nby@odoo.com>
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
When a model_terms translated field is overridden to a model translated field.
Its terms in the po files should be ignored otherwise calling field.translate
which is boolean will cause error.
opw-3644158
closesodoo/odoo#148518
X-original-commit: 50b314ff3c5d5003ad570d29a05bacd832d70362
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Chong Wang (cwg) <cwg@odoo.com>
Before this commit, it was possible that an attempt to update
peer connections made right at the moment the connection was swapped
from peer-to-peer to server mode. Which would cause a traceback.
This commit fixes this issue by checking if there is a
`RTCPeerConnection` before trying to update it.
closesodoo/odoo#148505
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Steps to reproduce:
- Go to "Settings / Users & Companies / Groups"
- Create a group (e.g. Group X)
- Go to "Settings / Technical / Actions / Server Actions"
- Create a server action:
* Model: [any] (e.g. Contact)
* Action To Do: Execute Python Code
* Python Code: [any]
* Security: Group X
- Create contextual action
- Connect with a non-admin user (i.e. Marc Demo)
- Open Contacts app
=> An Access Error is raised:
"You are not allowed to create 'Model Data' (ir.model.data) records.
This operation is allowed for the following groups:
- Administration/Access Rights
Contact your administrator to request access if necessary."
Cause:
When the group is created, its external identifier is not created directly.
When opening Contacts app, the list of authorized actions is evaluated.
During the process, "_ensure_xml_id" is called on the groups configured on
the actions to create the missing external identifiers.
However, the current user (i.e. Marc Demo) has not the rights to create an
external identifier.
opw-3328506
closesodoo/odoo#148503
X-original-commit: 34af4c8e6b4273688881b37bfba33d457054676c
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Signed-off-by: Anh Thao Pham (pta) <pta@odoo.com>
Versions:
---------
- 16.3e+
Steps:
------
1. Create an Sales Order with two lines that will create a task;
2. confirm and go to the new project's settings;
3. in Invoicing tab, link an employee to an SO item;
4. link yourself to the other item;
5. go to timesheets;
6. add a new line;
7. select the project and the task created for the other employee.
Issue:
------
The SO item changes to the one linked to the other employee instead of
the one linked to you in the project's settings.
Cause:
------
The new `account.analytic.line` record doesn't have an `employee_id`,
which `_compute_so_line` needs to accurately determine the sale line.
In saas-16.2, the new record retrieved the `employee_id` from the view,
which defaulted to the current user's, but these dissapeared at some
point between saas-16.2 and saas-16.3
Solution:
---------
Modify the `_timesheet_determine_sale_line` method can be modified to
compare `map_entry.employee_id` on `self.employee_id` or
`self.env.user.employee_id` instead of only `self.employee_id`.
This approach is already used in
caace8a88ed62fd15f2033742221736165940036 to fix a similar bug.
opw-3641939
closesodoo/odoo#148493
X-original-commit: 0802f35eaf0322e9c4e7b0475bf05c2468de38ad
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Levi Siuzdak <sile@odoo.com>
Current behaviour before commit:
In website, space before the word is lost when deleting the word.
Desired behaviour after commit:
Now space is preserved when deleting the word.
task-3233352
closesodoo/odoo#148492
X-original-commit: 5f5d12dd1bbdc63a9565aa84f197c4a9bba55d7a
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Before this commit, the mockServer didn't respect the unity specification
for many2one fields. When you do a mockWebRead and you want to read other fields
than "id" and "display_name" for a many2one field, the mockServeur ignores
this part of the specification.
The goal of this commit is to ensure that the mockWebRead respects
the full specification for many2one fields.
closesodoo/odoo#148483
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit addresses a synchronization issue with Microsoft Calendar,
which arose after the implementation of commit d9c4043.
The mentioned commit added tracking to the pre-commit process,
inadvertently causing problems during calendar synchronization.
The issue surfaced when the `_message_track_post_template` function was
called in the pre-commit phase. If the appointment function was
installed, the `_track_template` was overridden in this module, leading
to an attempt to access the removed event, which raised an error and
prevented calendar synchronization.
With this modification, the `_track_template` will not be called for
the created event that was cancelled in the same transaction.
opw-3635261
closesodoo/odoo#148439
X-original-commit: f46276590f62bc578aab954a88e495519b46a07a
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Whenever a user's is successfully connected with l10n_in_edi* it will display
the user a notification of successfully being connected with Indian EDI
Services
closesodoo/odoo#148418
X-original-commit: 9c0e6123c4b03ca27e1855755ce2728faeb567e6
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Harsh Modi (hamo) <hamo@odoo.com>
Added buy credits button in the view which gives ease to user to directly buy
l10n_in_edi IAP credits
X-original-commit: a604e023d79c72ab2f91b063bdd592f6c03e1eac
Part-of: odoo/odoo#148418
Issue:
When printing delivery slip report the warehouse address is shown instead of the delivery address.
Steps to Reproduce:
1. Install Purchase App.
2. Install Inventory App.
3. Create Purchase Order.
4. Receive Purchase Order.
5. Return the transfer.
6. print delivery slip
Solution:
Issue was that upon creating the return stock moves that will be outgoing
we copy the attributes from the original incoming stock move which does not
have a partner assigned, So the solution was to assign the partner on the outgoing
stock moves right away from the stock picking.
opw-3623451
closesodoo/odoo#148398
X-original-commit: 5c9b8cea1a08d310363cd93bc27662f2b848ef84
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
Signed-off-by: Omar Abosamaha (abom) <abom@odoo.com>
This commit ensures that elements returned by the getTabableElements
method of the ui utils does not return invisibe elements. This fixes an
issue with the trapFocus method of the ui service which could set an
invisible element as lastTabableEl therefore making it impossible to
loop back to the firstTabableEl when the actual last tabable element is
focused and the client presses tab. Also fix a side effect of these changes
in list renderer where focusCell would be called before the cell width
computations which would work by chance before since getTabableElements
took into account elements with 0 width but is now no longer the case.
This is fixed by moving down the onPatched method which calls focusCell
underneath the useEffect method which performs column style computations.
Steps to reproduce:
- Go to any dialog with mail installed
- Press tab multiple times
- At some point, the address bar should be focused instead of the dialog
buttons
Explanation: the chatter is present in the DOM but not displayed so the
last tabable element that is detected by getTabableElements is a child
node of the chatter which cannot be reached.
OPW-3584847
closesodoo/odoo#148382
X-original-commit: c631bf09b927003edc4c2b85e8790e8e2e8c044a
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Julien Carion (juca) <juca@odoo.com>
qsm-odoo