As a reminder, the readonly expression in grouped kanban can enable or
disable the drag and drop feature. If the view is not reaonly but the
field in the arch on which the view is grouped is readonly, the drag
would be disabled.
Before this commit, there was a regression introduced in commit
ba1a5509fa that made the kanban record not
able to evaluate the readonly expression in the fields.
This commit fixes the issue by making the kanban record evaluate the
provided expression. It does not however correctly evaluate the
expression if it contains another field as the drag and drop feature
can be enabled at a view level, not at a per record level. It would then
resolve to not readonly.
Task id 3611116
closesodoo/odoo#148533
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
As Czech legislation is changing its VAT structure on 1.1.2024, a new 12% tax
is added. Also some account were wrongly named, misclassified or missing. The 15%
taxe is kept in lower version for backward compatibility.
task-3609608
closesodoo/odoo#148409
X-original-commit: c0aba48f3c4fd2ebfa140fbe237ccde635e17b34
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Simon Morais Da Cunha (smdc) <smdc@odoo.com>
Steps to reproduce:
- Install `CRM` module (for test purposes)
- Create a lead and set the name, email, phone, company name and
contact name
- Save the lead
- Click on `Send message` button in the chatter
- Uncheck/Check the recipient checkbox
- Save the partner
- Discard the changes on the lead and open the partner created
Issue:
- In the wizard, the `phone` value is not set with default value and
the name is set with the company name instead of the contact name
- On the partner created, the company and phone are not set
Cause:
The default values (used in the partner creation wizard) retrieved
from "/mail/thread/data" route are not set on the recipient object.
opw-3512045
closesodoo/odoo#148213
X-original-commit: 372fe2fe61e3121b27bf1305dfac8fbf0ff8e9b5
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
This traceback arises when the user tries to reinstall the 'pos_restaurant'
module
ParseError:
Parse error rises
When users try to reinstall the 'pos_restaurant', a traceback will be
generated. Because duplicate 'MRCSH'records exist, they raise the ParseError.
Which leads to the traceback from here
https://github.com/odoo/odoo/blob/8b4f4f2e373896fcaa50f6ee55467274f8e440d5/addons/pos_restaurant/models/pos_config.py#L134-L139
After applying this commit, it will resolve the issue by if the
pos payment methodexists, returning the values otherwise create it.
sentry-4736057055
closesodoo/odoo#147539
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Steps:
- install to project_enterpise module
- Go to project > all tasks in the Gantt view
- Group by customers
- Filter any customer
Issue:
The wrong domain is passed in the search method so traceback occurred.
Cause:
Currently, we don't replace `child_of ` operator with `ilike` in _search_on_comodel method so
child_of is passed in the search method and orm is not handled.
Before this commit domain:
`[('name', 'child_of', 'admin')]`
After this commit domain:
`[('name', 'ilike', 'admin')]`
Fixed:
We correct the domain.
Issue in this commit-
https://github.com/odoo/enterprise/pull/41257/commits/57eb5b72796e0aeff6d8368219281760acb7c307
task-3625825
closesodoo/odoo#144989
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
When `test_display_name_for_empty_payment_details` was tested around
midnight, the test would fail because it compares the current date with
the token's create date, which would be the day before.
closesodoo/odoo#148781
X-original-commit: 87f94715a09b7681bcd92d1cba4f84d30918c502
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Current behavior:
Before this fix, when you sent the order to the kitchen, the preparation
changes were not saved directly. So if you refreshed the page right
after sending the order to the kitchen, the preparation changes were
lost.
Steps to reproduce:
- Open a POS restaurant session
- Add a product to the order
- Click on Order
- Refresh the page (F5)
- Go back to the table were you made the order
- The product still appears as not sent to the kitchen
opw-3614345
closesodoo/odoo#148755
X-original-commit: 8f33d6fa0261373fee276efd20dcbf75e95e1e28
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Robin Engels (roen) <roen@odoo.com>
The parser of the library we use to extract strings to be translated
(python-babel) doesn't handle escaped newlines in the same way as the
JavaScript parser. The resulting mismatch makes the content that uses
them untranslatable.
for example:
```js
const hey = _t("slt \
çv ?"
);
```
is exported as "slt \nçv ?", while the content of the variable is
"slt çv?"
This commit removes faulty occurrences from the code base and re-exports
the corresponding POT files.
*: point_of_sale, pos_sale, project, web
closesodoo/odoo#145971
Related: odoo/enterprise#52617
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Steps
=====
- Install sale_timesheet
- Create a project shared (in edition) with a portal user
- Creata a task with a subtask and log timesheets for the subtask
- As a portal user open the parent task form
- Go in the timesheet tab
- Click on the button "Sub-tasks Hours/Days Spent" at the bottom of the
page
Issue
=====
An access error appears for a res.partner record.
Cause
=====
https://github.com/odoo/odoo/pull/135528 introduced the field
allowed_so_line_ids on model account.analytic.line. This field is
computed based on the values of the field
commercial_partner_id (res.partner relation). However, portal users have
no access to res.partner records and the presence of this field in
account.analytic.line view (for timesheet) therefore raises an access
error for portal user.
Fix
===
A sudo is used in method _default_sale_line_domain to be able to fetch
the ids of the partners linked to the timesheet, even as a portal user.
task-3572112
closesodoo/odoo#139866
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
A class s_turnstile added to the script tag was missing. Without it,
the function cleanTurnstile called by the destroyed cannot clean the
script tag.
So it would result in the script being present several times in the DOM
after some manipulation.
fixes https://github.com/odoo/odoo/pull/147886closesodoo/odoo#148783
X-original-commit: e5af8a16fccc784e21fcc30d891fafb5d0951d17
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
Steps:
- install project ,website,saleorder
- open project ,share a saleorder project to admin from the share button
- then go to website,click on projects
- pen the shared project
- In that the size of the chatter is small
Issue:
- The size of the chatter is abnormally small
Cause:
- The problem occurs because the width of the chatter is less
Solution:
- By increasing the chatter size the problem can be solved
task-3549279
closesodoo/odoo#148770
X-original-commit: a2efc1a0a1b831f4dd356661d1ef40e9174af73b
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Fix various use case of HTML encoding / escaping in mail flows. Depending on
functional flow HTML entities could appear as they were not correctly
managed as valid HTML.
Notably when managing attachments in '_process_attachments_for_post' we
should return Markup-ized HTML to be sure it is considered as valid in
other post processing.
Task-3675159 (Mail: correctly escape HTML when updating content)
Task-3619348 (Mail: propagate markup flag when processing attachments)
closesodoo/odoo#148769
X-original-commit: f4bf63077d4129807e00e15b833e47623869491f
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When a customer with a sale portal link confirms the order, the
registrations in the order won't have the data for the partner of the
order which would be the expected default.
In 6cfdf64a86 the intention is to avoid
that registrations made on the website by anonymous users are registered
with the public user. There's a side effect to this in the portal
workflow though.
We can reproduce it like this:
- We need a payment aqcquire wich confirms our sale order (we can use
payment demo)
- In backend, create a sale order with the desired partner and a
registration to an event.
- Send the quotation to the partner.
- With the link portal (and without being logged in) sign and pay the
order with the demo payment aquirer.
Result:
- The order gets confirmed.
- The registrations are created with no partner (booked by).
So this fix avoids the original issue (having a public user as the
registration partner) but saving the case where we are confident about
the booked by value.
TT44782
closesodoo/odoo#148758
X-original-commit: 28020f2046b0183293a06ab03d4724173e3a0fa0
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Issue:
The query for the Tax Report Account>Tax is slow.
Analyze:
The query for the Tax Report is huge, and exceeds the
join_collapse_limit threshold
(https://www.postgresql.org/docs/current/runtime-config-query.html#GUC-JOIN-COLLAPSE-LIMIT)
of postgresql (8 by default and on our servers). It is then needed to
help the query planner to optimize this
query. Running the query with increased join_collapse_limit and checking
the explain analyze, helps in this process.
Fix:
The query planer with increased join_collapse_limit made the
res_currency joins at the very end of a truncated query.
Moving the res_currency join help as the inner join is made on AM^2 on
current position. Moving it after the base_line reduce it back to AM^1.
Benchmark:
| # Input data | Before PR | After PR |
|:-------------:|:----------:|:---------:|
| 271000 AM | 900 s | 13.24 s|
| 25000 AM | 180 s | 1.5 s |
| 51 AM (demo data) |52ms | 80ms |
Related task:
opw-3581671
closesodoo/odoo#148740
X-original-commit: b92b6846bfa7de8a41a6808e347fb78980baa4eb
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Signed-off-by: Benjamin Hanquin (beha) <beha@odoo.com>
Co-authored-by: Julien Launois (jula) <jula@odoo.com>
*: website
This basically reverts the parts of [1] that are the known cause of race
conditions in runbot tests (in particular, the link tools one:
`test_15_website_link_tools`). But more importantly, this just did not
make sense to stop observing changes for async period of time, at least
unless there is no alternative given the state of the related code.
Commit [1] test-hack was actually adapted with [2] which probably made
it even more unreliable and hacky.
On top of that, this commit is of course trying to restore whatever
purpose this was made for ("dirty" flag addition, the history steps
recording, etc). Although fixing those the most robust way would
probably require a deeper refactoring in master and other stable fixes.
Note: in this forward-ported version, the test is still disabled on
runbot and broken for other reasons. Those will be fixed later.
[1]: https://github.com/odoo/odoo/commit/8cab404dce3a65c0bdd635a93682ee14282a3ebb
[2]: https://github.com/odoo/odoo/commit/99b50d18e220aedf14de806f4bf1b2d35c32de35
runbot-18747
closesodoo/odoo#148728
X-original-commit: 003422a73f0b5fb5540fbf2bd95a26a6dd663530
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: web_editor
The editor has a feature that allows to automatically select a whole
paragraph on click when that paragraph contains text by default. At the
origin, this happened at every click on the element, until its content
was replaced, by typing something while it is selected or the cursor is
inside. Placing the cursor inside was actually impossible by clicking on
the element, since this forced a selection on the whole text again.
Since [1], that behavior changed (for no apparent reason): only the
first click forces a selection on the element. This is done by removing
the marker class from the element ("o_default_snippet_text"). Also, the
code which removed that class while typing was left behind... even
though it did not work anymore due to a code typo.
This commit fixes that without changing the main behavior:
- On click, we do not remove the marker class anymore, but only force a
selection on the text if it was not already seen before. Small change
of behavior: not changing the text and coming back later in edit mode
will force a selection on the text again on click.
- While typing, the code removes the marker class and thus the text will
never have a forced selection again (fixed the code typo).
Note: we may reconsider restoring the behavior there was before [1], in
master. Automatically selecting default text that was never changed
could indeed be better, although it will require better code to allow
placing the cursor inside easily anyway.
The main purpose of this fix is to avoid a mutation of the DOM on click
(removing the marker class). Indeed, this wrongfully marked the page as
dirty.
Steps to reproduce:
- Enter edit mode
- Add a "Text - Image" snippet
- Save
- Enter edit mode again
- Click on the first paragraph of the snippet (=> it is auto-selected)
- 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/912996fe902c41cafa12dcfe09713ce9857f95ab
Related to runbot-18747
X-original-commit: 3cc5bbcab641d7d436ebfbb0f160c9e0d77da142
Part-of: odoo/odoo#148728
*: 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
Simon Genin (ges)