Use case to reproduce:
- Set "receive good in input and then stock" on the warehouse.
- Set two suppliers on a product. one from a partner (higher priority)
and one from a child partner (lower priority).
- Set the child partner as the vendor on the replenishment report.
- Order a replenishment for the product.
It happens due to an hack that use a field on `stock.move` in order
to temporaly store the partner among the moves until the RFQ.
But this field is a many2one on `res.partner` model and not on
`product.supplierinfo`
`_run_buy` receive a partner and still use `_select_seller` with the
partner in order to find the best pricelist. But it won't use the
specific supplier price list set on the orderpoint.
In order to fix, we don't store anymore the price list partner on the
intermediate move. In run_buy we receive the orderpoint if it's the
origin of the procurement. On the orderpoint the supplierinfo is set.
So we take it from there.
opw-3180945
closesodoo/odoo#119063
X-original-commit: 3cd5b9b7688ef7e6c6fa4fce1c0ad319fb577745
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
In this paragraph, we are trimming the string and then converting it to an int type. But there is no guarantee that value_string can be converted to int
closesodoo/odoo#119059
X-original-commit: 84fca48dfbabbaa928823d3a27621c77cc53d6dd
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Before this commit, when opening Discuss from chat window and then
accessing the settings page of a channel, the breadcrumb showed
"Unamed" as the name of the App instead of "Discuss".
This happens because the client action was not named when expanding
the chat window by opening Discuss app.
closesodoo/odoo#118939
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit, when quick creating a new record in a kanban view,
the "read more" button is briefly shown (flickering). This issue occurs
because, when creating a new record, we increment the number of records
in the group before adding the record to the list of displayed records.
This means that for a brief moment the number of records of the group is
bigger than the number of displayed records, therefore the "load more"
button is show.
Note that this flickering was introduced due to the following
refactoring : https://github.com/odoo/odoo/commit/067bcac53336b5f66f695b1c10b333d8c722225d
Now, we increment the number of records on the group after we added the
record to the displayed records' list.
closesodoo/odoo#119142
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit,
The audio context used in media_monitoring was not
closed. Which could lead to memory leaks.
The source was not connected to the destination in the
script processor (used in old browsers that do not support
audioWorklets), which would prevent the monitored audio to be used as
an audio source.
closesodoo/odoo#119124
X-original-commit: f1c3f78dd6e17fe2a3f5a01d8510ca4343b880fe
Signed-off-by: Thanh Dodeur (tso) <tso@odoo.com>
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This commit prevent the reset of password for de-activated partner
closesodoo/odoo#119114
X-original-commit: 71f4cf2da157d3457885339d116c38d673187b59
Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>
Calling `fetch` with 'id' in the `fields_name`, will always generate
SQL query even if all requested field values are in the cache.
This is because we also look for values in the 'id' field cache,
but we don't ever fill the cache for `Id` fields.
closesodoo/odoo#119107
X-original-commit: 3ba8d0e5e57e1358cc8958abf511d514515eccb2
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
When Operation is 'Archive' and it is still in use as 'Consumed in Operation' in
bom while creating Manufacturing Order and confirming it, KeyError will be
generated.
Steps to Produce:-
1) Create a new product, create bom for that product, add components, and
create or add at least 2 operations to the BoM.
2) In the components of 'Consumed in Operation' add the newly created operation.
3) Now, Archive one operation.
4) Create new Manufacturing Order with a newly created BOM
5) Try to confirm it.
KeyError will be generated.
By applying this commit, if there are no operations left after archiving
one linked to the component then the server error won't occur
sentry - 4042593205
closesodoo/odoo#119098
X-original-commit: ba2364f9188ff44c68a1b86d5029884815a33216
Signed-off-by: Tiffany Chang <tic@odoo.com>
Current behavior:
When printing a bill in the restaurant you had an error poping.
Steps to reproduce:
- Open a restaurant session
- Go on a table and add some products
- Click on the bill button
- Click on the print button
- You get an error
opw-3259014
closesodoo/odoo#119041
X-original-commit: 1d1808e7136c6416fe88c28e7971e97707de2557
Signed-off-by: Heinz Robin (rhe) <rhe@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Since [this commit], a horizontal scrollbar appears on mega menus. This
is because Bootstrap position the dropdown automatically and the mega
menus are a bit shifted on the right (due to a `translate3d` added by
dynamic position of popper). This commit fixes the problem by removing
dynamic positioning for mega menus.
Steps to reproduce:
- Have a system setting that enlarges the texts size or zoom the page
- Have a mega menu
- Open the mega menu
=> There is a horizontal scrollbar.
[this commit]: https://github.com/odoo/odoo/commit/8689241f86e2d4ddb4e4510951f92b80e115b914
task-3133137
closesodoo/odoo#118842
Signed-off-by: loco-odoo <loco@odoo.com>
Since the upgrade to Bootstrap 5 and especially since this [BS5 commit],
there is a gap between the mega menu and the navbar when the user opens
a mega menu. This commit removes that gap.
Steps to reproduce the bug fixed by this commit:
- Have a mega menu on your website.
- Drop a block of a dark color at the top of the page (it helps to see
the problem).
=> When you open the mega menu, you can see a small piece of the block
of dark color between the navbar and the mega menu.
Technical explanation:
This [BS5 commit] introduces a new css rule that adds a
`margin-top: 0.125rem;` on the `.dropdown-menu[data-bs-popper]`. However
when [mega menus were introduced], another css rule prevents having a
gap between the nav and the mega menu (`margin-top: 0;` on
`.o_mega_menu`). This commit makes sure that it will be a `margin-top`
of 0 by making the property more important.
[BS5 commit]: https://github.com/odoo/odoo/commit/c48f57ea2538ad51e00ac27d58f8e191781444f3
[mega menus were introduced]: https://github.com/odoo/odoo/commit/1345702258adbfbee0d780dc22e552395e6d1df7
task-3133137
opw-3226013
X-original-commit: b41c76bd7583756ad059f77f0d3c1151720b0b0b
Part-of: odoo/odoo#118842
This commit allows to reopen submenus and mega menus if one of them was
opened when scrolling on a page of a website.
Steps to reproduce the bug fixed by this commit.
- Have a submenu or a mega menu in the navbar
- Open a dropdown of the navbar
- Scroll down
=> It is no longer possible to open the dropdown.
This commit fixes this issue and adds a test for this flow.
task-3133137
opw-3226013
X-original-commit: 9b1de9e28697edbb6e1fa88665294f983f60e37f
Part-of: odoo/odoo#118842
Purpose
=======
Allow to use favorite in Knowledge embedded view.
For that purpose, we need to hook some function in the web module
(because favorites are stored in view arc and not using ir.filters
records).
Task-3251129
closesodoo/odoo#117188
Related: odoo/enterprise#39057
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
# Editor changes to enable the collaborative mode in Knowledge
Here are the necessary changes to make it possible to enable the collaborative
mode in Knowledge. Knowledge commands introduce a new kind of editor blocks:
`Behaviors`, which are OWL `Component` which need to be mounted. This mounting
is asynchronous and this has to be supported, while not all nodes are observed
by the editor, meaning that parts of a `Behavior` can be collaborative while
others may not.
The following is a brief introduction for every commit in this PR, check them
out individually for more detail.
### [FIX] web_editor: notify current step when joining a collaborator
- Inserting an embedded view from a module in an automated process happens as
soon as the first collaborator connect. This commit notifies the step for the
embedded view during the following collaborators connections (to be sure they
actually received it).
### [IMP] web_editor: fully implement oeProtected and oeTransientContent
- Those attributes will allow a fine control on which nodes are NOT observed by
the editor (`oeProtected="true"`), and which nodes are NOT saved/serialized
for collaboration by the editor (`oeTransientContent="true"`). It can be a
better choice than using `observerUnactive` which stops the observer for all
nodes of the editor, in case a node should never be observed.
### [IMP] web_editor: prevent 'insert' command unwrapping in root
- Modify the 'insert' command of the editor so that it does not unwrap nodes
when the selection is directly inside the editable ('root'). Unwrapping a
paragraph in that case would put text nodes as direct childs of the editable,
which is not desirable with the current implementation.
### [IMP] web_editor: add a hook for historyResetFromSteps
- When joining an `html_field` in collaborative mode, there is no way to know if
there are connected collaborators before actually making said connection. This
is a problem when we want to automate the insertion of an embedded view from
another module in Knowledge. With the hook, it is now possible to execute a
specific action as soon as a collaborator is joined.
### [IMP] web_editor: force load collaborative on form view
- The collaborative mode loads lazily with the focus by default. In Knowledge it
should start as soon as possible, therefore this commit adds an option to do
so.
### [IMP] web_editor: make mocha tests odoo modules
- Since `web_editor` tests were not odoo modules, it was not possible to import
dependencies from i.e. `web`. This commit addresses that.
### [IMP] web_editor: buffer external steps during Component rendering
- In a collaboration, when applying a step requiring a custom OWL `mount`
(which is asynchronous), further external steps should be buffered while the
rendering is done, in case those following external steps should concern
"rendered" nodes which are not yet present in the editor. Once all nodes are
rendered and present in the editor, further steps can be applied safely.
See odoo/enterprise#33483
See odoo/upgrade#4384closesodoo/odoo#104680
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Add a mechanism to buffer external steps when some asynchronous rendering needs
to be done (i.e. OWL rendering). This is to prevent external steps occuring
inside the rendered result from being applied when the rendering is currently
ongoing.
Remove `historyResetFromSteps` and `onExternalHistorySteps` as they were only
introduced to trigger an update of Knowledge Behaviors, but now that update is
done through `checkForExtraRendering`.
Modify collaborative tests of the editor so that steps `afterCreate` and
`afterCursorInserted` can be asynchronous.
Task-2821374
Part-of: odoo/odoo#104680
In order to be able to use web dependencies for mocha tests, convert every
existing test to an `@odoo-module` and make a new asset
`web_editor.mocha_tests` that will be used for tests in `/web_editor/tests`
Task-2821374
Part-of: odoo/odoo#104680
Add an option to the html_field (collaborative_trigger) to allow to choose if
the peerTopeer connection of the collaborative mode should happen when the
html_field is loaded ('start') or when the field has the focus ('focus').
Will be used in Knowledge since the html_field of an article is the main focus
when opening the form in edit mode. The collaborative mode should be loaded as
fast as possible.
Task-2821374
Part-of: odoo/odoo#104680
When the current user connects to a collaborative peer, the content inside his
editor will be reset. When opening a record, there is no way to know if such a
connection will happen.
In Knowledge, when one wants to insert an embedded view in an article body from
elsewhere in Odoo, it is inserted programatically once the article is opened. At
that time the peerToPeer connection is not established. Then, if a collaborative
session is started with someone already editing the html_field, the content is
reset, and at that point, the insertedd element is removed, so it should be
inserted again.
This commit introduces a hook that can be used to execute some specific action
if the content of the editor is reset through `historyResetFromSteps` during
the collaboration first synchronization. It can be provided as an option of the
`wysiwyg`.
Task-2821374
Part-of: odoo/odoo#104680
Currently, the 'insert' command unpacks nodes from a lone paragraph, or from
the first and last node if there are multiple nodes.
In knowledge, to append an embedded view to the editable, there is a need to
insert two sibling nodes at once (without unpacking them). With the current
behavior of 'insert', it is possible to do so by inserting a paragraph
containing the 2 nodes that need to be inserted. The result will be that the
'insert' command unpacks the parent paragraph and correctly insert the 2 nodes.
This commit prevents the 'insert' command from unwrapping nodes if the
anchorNode of the selection is the editable itself.
Task-2821374
Part-of: odoo/odoo#104680
With the introduction of Knowledge Behavior Component, came a need to create
html nodes which would have limited interactions with the editor. i.e. an Odoo
view already has everything it needs to function properly, and when it is
inserted in the editor, any manipulation on the selection or on the style that
could be done with it should be prevented. Another example would be the
/template block (will be renamed /clipboard in the future) that has a
non-editable part (buttons which have a definite action in Odoo, and which
should not be interacted with) as well as an editable part inside of it).
To solve this use case, this commit proposes to mark specific html nodes with
a `data-oe-protected` attribute which could have one of three values:
- "true"
- Only mutations of type "attributes" can be registered on the node itself
which has the `data-oe-protected="true"` attribute
- Prevent mutations of children (and sub-children) from being registered by
the mutationObserver of the editor
- Prevent the selection handling when its anchor is inside a
`data-oe-protected="true"` element, even if it is `contenteditable="false"`
- Prevent the command hint
- Prevent the usage of the wysiwyg toolbar
- Prevent the dblClick tooltip
- Prevent the editor sanitization `Sanitize.js`
- "false"
- Designed to be contained inside a node with `data-oe-protected="true"`
- Re-enable all features disabled by a parent node with
`data-oe-protected="true" for the children of a node with
`data-oe-protected="false"
- ("")
- This is considered equivalent to have the `data-oe-protected` attribute
set to "true" (like other html attributes).
Another attribute is added: `data-oe-transient-content`, with the following
values:
- "true"
- Prevent the serialization of the children of the node, so they are not
shared during a collaboration.
- Transient nodes will be removed during `cleanForSave`, meaning that they
will never be part of the html_field value in the database
- ("")
- equivalent to "true"
The use case is an embedded view: there is a large quantity of nodes that
are not relevant to share nor to save, since it will be recreated with the
lastest data from the database, with the information relevant to the
currently active user each time it has to be rendered.
Note:
This commit does not handle the dynamic switch from a specific value for
`data-oe-protected` to another (i.e. switching from "false" to "" or "true").
This could cause a number of problems like:
- some mutations from when the value was "true" are not yet handled when the
switch (to "false") happens => those mutations will be registered as if they
were always under the "false" value, even though it is not the case.
- in collaborative, some nodes with oids that were not relevant (under the value
"true") won't necessarily have the same oids in between collaborators.
Therefore we cannot suddently listen to their mutations and expect the changes
to be shared by switching to "false".
In conclusion: the `data-oe-protected` attribute value should stay the same
during the entire edition.
Task-2821374
Part-of: odoo/odoo#104680
How to reproduce (scenario):
- Open 3 windows with 3 different sessions in Odoo
user_1 -> in CRM, My Pipeline
user_2 -> in Knowledge on article "target"
user_3 -> in Knowledge on article "target"
-> user_2 and user_3 are in a collaborative session
-> user_1 "insert view in article" "target" (via Favorites)
-> user_1 is redirected to knowledge to the target article
-> RTC_DATA_CHANNEL_OPEN between user_1 and user_2 happens
-> user_1 reset the html_field value from the history steps of user_2
-> the embedded view "My Pipeline" is inserted via `execCommand` and create a
step in user_1 editor
-> user_2 is notified via OE_HISTORY_STEP and receive the new nodes (view)
-> RTC_DATA_CHANNEL_OPEN between user_1 and user_3 happens
-> since user_3 was already synced with user_2, there is no
`historyResetFromSteps`
-> user_3 does not get the step from user_1 with the embedded view nodes now
-> user_3 makes multiple steps (i.e. write some text in a paragraph)
Current Behavior:
-> user_2 and user_1 are notified of those steps and add them to their histories
-> user_3 stil did not get the step with the embedded view nodes
-> now if user_1 and user_2 make some steps, user_3 will be notified, but those
steps "parents" are the steps from user_3, so user_3 may not request a full
history comparison and may never get the missing step
Fix:
-> when a RTC_DATA_CHANNEL_OPEN event happens, the connected client is notified
of the last registered step so it can call GET_MISSING_STEPS if it does not have
it
Note:
This fix solves the specific case mentioned above, but other cases of
desynchronization may happen, see Task-3208277 for a more complete fix.
Task-2821374
Part-of: odoo/odoo#104680
odoo/odoo#111651 improved and optimised triggers but dropped the
in-place cleanup of field dependencies. As a consequence, during
module uninstallation if a stored computed field is removed (because
it's part of a module being uninstalled), and one of its dependencies
is subsequently altered (e.g. it's itself removed, or written to) the
second update will break as the query trying to find out which
dependent records to update will error, either because of trying to
select / filter on a missing column, or because of trying to fetch
in a missing table.
The simplest examples of this issue are computed fields with a
dependency on `ir.model`:
- In `calendar`, `calendar.event.res_model` is a related on
`res_model_id.model`, this prevents the removal of *any* `ir.model`
record if it gets uninstalled.
As a result the `calendar.attendee` and `calendar.event` tables
don't get removed (just emptied of all their non-automatic fields),
their records remain as well, and when the non-automatic fields get
re-added during installation re-instating the NOT NULL constraints
fails, breaking the uninstall/reinstall test.
- In `payment`, `payment.provider.module_state` is a related on
`module_id.state`, this breaks *during* uninstallation, as after
`module_uninstall` first calls `_module_data_uninstall` which
removes the field, then it *updates the modules being uninstalled*
(sets their state), which tries to find out which
`payment.provider`'s `module_state` is should update, which breaks
because the `module_id` column has been removed.
This second one was worked around in odoo/odoo#118900, by marking
modules as uninstalled before actually gutting them, but as it turns
out the "actual" fix is needed anyway. So revert the workaround, and
actually fix the issue.
closesodoo/odoo#119130
X-original-commit: 48a420efcf7c7b46416bab006003553cc9d23846
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
If applied, this commit will solve the tuple index out of range error when the
'Percent' value is not set in the Due Terms and the user tries to add 'Fixed'
value in more than one line.
To reproduce this issue, follow the steps.
- Open Accounting -> Configuration -> invoicing -> payment terms.
- Open any payment term, and change the value from 'Percent' to 'Fixed' in Due
Terms.
- Add another line with a value as 'Fixed'.
see-https://tinyurl.com/22e2yj2a
sentry-4072967091
closesodoo/odoo#119131
X-original-commit: fcb3c237e24ec44fd6df0de5f2a0f329efb1bf13
Signed-off-by: William André (wan) <wan@odoo.com>
- Enable Cash Rounding in settings.
- Create the cash rounding as
- Rounding precision: 5.00
- Rounding Strategy: Add a rounding line
- Profit Account: Any
- Loss Account: Any
- Rounding Method: Half-up
- Enable "Lock Posted Entries with Hash" on Customer Invoices Journal.
- Create a draft invoice and set the cash rounding on it.
- Confirm
Error will raise
You cannot edit the following fields: Account, Label, Partner.
The following entries are already hashed
This occurs because cash rounding is recomputed during post,
after hash was written
opw-3235377
closesodoo/odoo#119126
X-original-commit: 5cb044dd8a2385c9a3c09520ed97eb4faa39216d
Signed-off-by: William André (wan) <wan@odoo.com>
Current behaviour:
When a pricelist discount with a % is present for the /shop, but
doesn't apply for the product, for some base prices that are not
easily representable as floats, the comparison between the base
price and the post-pricelist price may be different, when they are
not, due to floating point inaccuracy.
Expected behaviour:
Even if floats are not accurate, if the price is essentially the
same, it shouldn't be counted as a discount.
Steps to reproduce:
- Install eCommerce and Sales
- Settings > Activate all pricelist settings for discount and check
the "Comparison Price"
- For a product set the base price to `4,152.48`
- Create a price list that shows the discount of 25% that *doesn't*
apply for the product we set, set it selectable for the e-commerce.
- Go to the /shop, set the pricelist and look for your product, see
that the base price and discounted price are the same, but one is
strikedthrough as if there is a discount.
Reason for the problem:
Floating point inacuracy when computing the base price of the
product, and we compare with the "reduced" price, they are different
(4,152.48 vs 4,152.480000xx), so when we compare them, they are
different, when they shouldn't be.
Fix:
Use `compare_amount(...) != 0` of the currency to safely compare the 2
prices.
Affected versions:
- 16.0
- saas-16.1 (couldn't reproduce, but the line is present, so
possibly faulty)
- saas-16.2 (couldn't reproduce, but the line is present, so
possibly faulty)
- master (couldn't reproduce, but the line is present, so
possibly faulty)
opw-3246461
closesodoo/odoo#119072
X-original-commit: aaaae309d38651c9ce5cd63439695e858a7c047d
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
Create a product category [FIFO] with:
- Costing Method: First In First Out (FIFO)
- Inventory Valuation: Automated
Create a product [PROD] having:
- Product category: [FIFO]
- Product Type: Storable Product
- Invoicing Policy: Delivered quantities
- Can be expensed: True
- Re-Invoice Expenses: At cost
Create a sales order with [PROD]
Confirm, Deliver
Open the created STJ journal entry:
- Reset to draft
- Add analytic account on a line
- Post again
To the sale order is added a reinvoice line with negative quantity.
This should not occur with cogs lines
opw-3199428
closesodoo/odoo#119048
X-original-commit: 347975d6d9b07db521e02ee12694aa834708abbe
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
We refactor the ModelFieldSelector and ModelFieldSelectorPopover
components.
We also improve a bit ModelFieldSelectorPopover:
- on first page, the button to go back is no longer available
(so that it is now more difficult to produce an invalid path)
- we always start with a page presenting the model where the last
selected field name belongs to
- the keyboard navigation is improved
- click on model field selector opens the popover with the focus in
the search input (if any)
- for relational fields in popover: the user can either click on the
relational field (and select it) or a special button that make him
follow the relation to the field comodel
We also refactor the hook useDynamicPlaceholder to make it use a new
component DynamicPlaceholderPopover that uses ModelFieldSelectorPopover.
Task ID: 3272798
closesodoo/odoo#117951
Related: odoo/enterprise#39673
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Michaël Mattiello <mcm@odoo.com>
Make the public `read_group` depends of its private method `_read_group`
refactored to match the backend usage.
We try to keep the public API similar for this first part of the
rafactor, but there are still some API change:
- We cannot order by `id` anymore.
- The display_name of many2x group values are not lazy anymore.
Part-of: odoo/odoo#110737
Lot of override of read_group reimplement partially custom security
rule of `_search` method. In order to simplify these security check
and have a consistent behavior between the search and read_group method,
_read_group now use _search to create the from and where clause.
Part-of: odoo/odoo#110737
The new backend version of read_group can simplify the
current overrides of read_group. Do it for each of them and
avoid making extra search (done with __domain) when it is possible.
Part-of: odoo/odoo#110737
The `_read_group` was designed to be used by the web client to
efficiently compute aggregations grouped by one or more fields.
However, more and more developers have been using it from the backend
to make computations more efficient (avoid doing the aggregation
in Python). Unfortunately, the API was designed for the web client,
which added a lot of boilerplate when used in the Python (list of
dict with misleading key name choices).
`_read_group` was created to improve the performance of read_group
for backend use (4ef0c00b4b), but didn't
change the API and based the implementation on read_group itself.
Rewrite `_read_group` from scratch with a new API to make it easier
to use from the backend (see the method documentation). Also, split
the method to make it easy to override and add custom behavior.
Part-of: odoo/odoo#110737
`read_group` cannot order on the fields that are not
aggregates in the same transaction. We get a warning for it:
`<model>: read_group order by '<field_name> ASC' ignored, cannot sort on empty columns (not grouped/aggregated)`
Fix it.
Part-of: odoo/odoo#110737
The default `group_operator` of `Many2oneReference` is 'sum' (inherited
from the parent class `Integer`), it doesn't make any functional sense
to sum ids.
Also set group_operator to None on `co2` instead of override read_group
for the same result.
Part-of: odoo/odoo#110737
This PR hide the message body when the link preview is an image and the message
only contains the link to the image.
closesodoo/odoo#117772
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this commit, chat window take at most 95% of global
height. This is ok in desktop, 5% room allow clicking on
systray menu. In mobile, however, the intend is for chat window
to take whole height.
This commit makes chat window take whole height in mobile, while
preserving the max-height 95% of global height in desktop.
Also fix an issue where chat window were foldable in mobile, when
this feature is desktop-only.
closesodoo/odoo#119058
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Steps:
- Install hr_holidays module
- Got to employee app and create employee (Test)
- Open Test emp and Click time-off stat button
- Click Allocation Request
- Test employee not set in Allocation Request but current employee
Issue:
If we allocate leave from a particular employee but set the current login user employee
closesodoo/odoo#119078
X-original-commit: e07f83e2181573604102c2323ac48c08aa0d116a
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Issue:
------
It is possible to create recurring events
that are in the same DST period.
Unfortunately, the basic event is sometimes duplicated
Cause:
------
The cause comes from the Daylight Saving Time (DST).
With the base event, we create a recurrence.
This recurrence will create all the events
of the recurrence.
To achieve this, with the basic event, we create all the ranges.
Then, we compare these ranges to remove those which already have
events.
Logically, we must reconcile the first range with the base event.
Sometimes the range of the base event and the first range
calculated to generate the occurrences do not match.
The consequence is the creation of a new event.
The cause of this problem is that we go back too far to find
the starting date of the period from which we will generate the ranges.
For example, in the case of a recurrence with a frequency of `MONTHLY`,
we will take the first date of the month.
And if we are in the month when the DST changes,
we will have the problem.
Solution:
---------
The solution is not to go back
if we encounter a difference in the DSTs
between the starting date of the base event
and the starting date for generating the ranges.
opw-3143680
closesodoo/odoo#119073
X-original-commit: 065dd4a2548ff0da6cf23a7ac62321ce99500d35
Signed-off-by: Arnaud Joset <arj@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
The issue is when we create a new PO with notes/sections and these notes/sections are showed on purchase reporting and only the products were supposed to appear there.
This issue happens because the SQL query wasn't applying any filter to the lines. The solution is apply a filter by display_type.
Steps to reproduce:
1) Go to Purchase App -> Purchase Orders -> Create a new PO with notes/sections
2) Go to Reporting -> View as pivot
3) You'll be able to see the section/notes you just created
closesodoo/odoo#119001
Opw: 3245933
X-original-commit: 8a9aa4c65bfdc776772e46bd199f6042f2678895
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: malv-odoo <malv@odoo.com>
"ERROR: Unknown Unsplash URL!" is generated when we try to add premium
Unsplash images. This is because when we add the unsplash image, it accepts the
image whose URL starts with "https://images.unsplash.com/" but the premium
image URL starts with "https://plus.unsplash.com/".
This commit solves the above issue by checking that the premium splash
image link starts with the correct format.
sentry-4075507166
closesodoo/odoo#118662
X-original-commit: 00894718cc7332131a7096c1e6dbe124d5d6d233
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
before this commit, on duplicating a contact tag
will duplicate the assigned partners also.
suppose if we have a partner A with tag B assigned,
and then we duplicate tag B and create new tag C,
the newly created tag is automatically getting
assigned to partner A.
after this commit, the copy is set to False for
partner_ids field in tag and then the partners
wont be copied on duplicating a tag
closesodoo/odoo#118974
X-original-commit: 5dc9104403606b6421b9cde732cfa3d6bb5962aa
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Before this, uninstalling the `payment` module (or any of its
dependencies) is broken: as payment.provider has a dependency on
ir.module.module.state, marking the modules causes a lookup of the
payment provides to update, but the table was removed by
`_module_data_uninstall`, so the lookup blows up.
This is a consequence of odoo/odoo#111651 which improved and optimised
triggers but dropped the in-place cleanup of the triggers tree.
Thus while the columns & tables get removed from the database the
in-memory structures (registry, models, fields, ..., as well as the
trigger and dependency caches) are not so the python side will happily
try to look up stuff which has been nuked if accessed at the wrong
moment (which is any moment between the start of
`_module_data_uninstall` and the creation of a new registry, really).
As `_module_data_uninstall` is nothing but a giant pile of dodgy state
anyway, making modules as uninstalled before it executes doesn't seem
like a huge deal. It may cause unnecessary extra recomputation for the
few models which depend on modules, but that doesn't seem like a major
issue, at worst it makes uninstallation a touch slower but they're not
a huge performance concern at the moment (they're more of a
correctness one).
closesodoo/odoo#118959
X-original-commit: 460efeb623ec62c980d187710bd4e7614af0e7bd
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Arnold Moyaux