Otherwise, they may crash or be incorrectly verified when
creating/updating recordsets containing multiple records.
Also improve the constraint error messages to be more detailed.
When possible, use a sql constraint instead to speed up the records
validation.
Task Id: 2328664
COM PR: https://github.com/odoo/odoo/pull/55525
ENT PR: https://github.com/odoo/enterprise/pull/12250
The constraint method _check_parent_id was defined twice.
This commit removes the second definition, less efficient because not using
_check_recursion correctly (it can be called on a recordset with multiple records directly).
Task Id: 2328664
COM PR: https://github.com/odoo/odoo/pull/55525
ENT PR: https://github.com/odoo/enterprise/pull/12250
Without write permissions, Time Off Managers are unable to approve
nor refuse leave requests. It seems there was a mismatch with
`hr_holidays.group_hr_holidays_user` as "Approvers" and actual users
at some point.
Bug reported via p/feedback by CMO and LEM after v14.0 migration.
closesodoo/odoo#62084
X-original-commit: 7c32f977aa5233d47ba6aebef56dc70f7b7b9bac
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Correctly format the `product_uom_qty` with the appropriate widget.
opw-2382517
closesodoo/odoo#62085
X-original-commit: 042298f8c949fba470eda6ad90f94c95ca291030
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The prefetching engine wants to prefetch all the registrations to all
the events of all the schedulers, which may make a lot of data.
If the autocommit is on, then all this prefetched data is discarded at
each loop.
This commit limits the prefetching to each scheduler, so that we avoid
prefetching the data unnecessarily.
closesodoo/odoo#62052
X-original-commit: 904a46f28cb64e3bd51c40dc364b256d434d1c93
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Signed-off-by: Paul Morelle <madprog@users.noreply.github.com>
What are the steps to reproduce your issue ?
1. Install 'stock'
2. Create 'ProductA' with 'Tracking By Lots'
3. Create some 'Lots/Serial Numbers', for example 'CodeA0 and 'CodeA1'
4. Go to 'Reporting/Inventory Report'
5. Remove 'Product > Location' from the search bar.
6. Click 'Create' and select 'ProductA' with 'WH/Stock' Location
What is currently happening ?
When you set 'Lot/Serial Number', the available lots to choose
are not limited to the selected product only.
What are you expecting to happen ?
Show only lots of the selected product.
Why is this happening ?
The domain contained no condition which depended on the product.
How to fix the bug ?
Addition of a condition that depends on the product.
opw-238143
closesodoo/odoo#62046
X-original-commit: 3b33f1d3f5cb5182d5577176640bcf7427757ed2
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Problem
-------
When a sale order has more than one task within the same project
clicking on X tasks lead to an access error since regular user
cannot read action anymore
Solution
---------
use _for_xml_id method to fetch action data
closesodoo/odoo#61953
X-original-commit: ff43c875a7566ef4473452fc359e73fbf589b615
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This change allows uninstallation of hr_timesheet from the configuration of
Project.
Previously, attempting to disable the Timesheets feature from the configuration
of Project resulted in a user error that requested the user to first remove
tasks in projects that were linked to analytic accounts. This was caused by the
removal of demo data during the uninstallation of hr_timesheet, which attempted
to unlink analytic accounts before unlinking the projects that were referencing
those accounts. The order in which demo data are removed during uninstallation
of a module is currently not fixed. This change avoids the problem by instead
removing the explicit creation of analytic accounts as demo data.
Furthermore, hr_timesheet would be immediately re-installed upon uninstallation
through project_timesheet_synchro and project_timesheet_holidays. Disabling
those modules along with hr_timesheet fixes this.
Task 2339016
closesodoo/odoo#60134
X-original-commit: 43db576b7f0efed563ee597ab087e4d7ef5c74d9
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This part of the tour can't work with the new online synchronization
module (account_online_synchronization) due to the fact that we are
using an iframe to display the list of institutions and therefore
those steps won't work within the iframe.
Also remove account_plaid & account_yodlee from _auto_install_l10n as
those modules don't exists anymore.
closesodoo/odoo#50267
Related: odoo/upgrade#1780
Related: odoo/enterprise#8200
Signed-off-by: Cedric Snauwaert (csn) <csn@openerp.com>
If a job position has a default recruiter, when applying for this job, the application's recruiter is not the correct one.
To reproduce the error:
(Need hr_recruitment,website_hr_recruitment)
1. Go to Recruitment > Configuration > Job Positions
2. Create a new one
- Fill in the Recruiter field
3. Save it
4. Click on "Go to Website"
5. Publish the job position
- Top bar: click on "Unpublished"
6. Log out
7. Go back on the job position page
8. Apply
9. Log in
10. Open the Recruitment module
11. Check the applications for the job position
=> The application is created, but the associated recruiter is not the one previously set (step 2 above).
This fix makes sure an application has the correct recruiter when the associated job position recruiter is defined.
OPW-2387888
closesodoo/odoo#62038
X-original-commit: b7deda4185e3c240c3c30c9a570dc7173f9d8aa3
Signed-off-by: adwid <adwid@users.noreply.github.com>
- Create a product P with a MTO Reordering Rule (Buy Route)
- Add a supplier to P with a specific vendor code
- Create a SO for 1 unit of P, validate
A PO is created for the supplier but without using the vendor code.
It happens because the vendor code is overridden by the product
description.
To avoid losing information and redundancy, we add the line description
only if different from the product name.
opw-2383418
closesodoo/odoo#62037
X-original-commit: 0b138ffa5a1b2b03f03fb5dc51994a3bfc4e5dea
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
A user without admin access cannot add any views to his dashboard
To reproduce the error:
1. Connect using an account without admin rights
2. Go to CRM (for instance)
3. Favorites > Add to my dashboard
4. Set name & Save
=> An AccessError is raised
A user should be able to add some views to his dashboard.
OPW-2382713
closesodoo/odoo#62034
X-original-commit: a2d2006f24f56e16007a62cdec5af32a03f5552a
Signed-off-by: adwid <adwid@users.noreply.github.com>
Indeed the non-pinned thread are not displayed in the menu and should not be
taken into account for its counter either.
task-2389824
closesodoo/odoo#62045
X-original-commit: 938d621db5355064e51c4b5e57238a91570aa685
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
There is a user whose email login is "joe@examplé.com", notice the
latin "é" in the domain. This domain is a valid IDNA-2008 domain but
the smtplib of python is incompatible with such domain and raises a
UnicodeError because the character is not ascii.
Note the removed comment about bytestring is a leftover of a dark
python2 age and is no more valid.
Closes#61972closesodoo/odoo#62026
X-original-commit: 89a1989bd271f49a9222d5c255e03d4877045621
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
PURPOSE
The motive is to change dynamic placeholder by giving context to the user for
indicating whom he/she is writing.
SPECIFICATION
Changing placeholder "Write Something..." by "Message person/group..." for chat
and "Message #channel..." for channel.
LINKS
PR https://github.com/odoo/odoo/pull/60582
Task-2361155
closesodoo/odoo#60582
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
This commit changes the default crm alias prefix from 'info' to 'contact'.
As the alias of the default sales team is configured to 'info', also having
'info' for the "crm_alias_prefix" setting was leading to an alias collision.
This change allows an easier configuration by the end user and avoids confusion
when first playing with your CRM settings.
Task 2373095
closesodoo/odoo#62025
X-original-commit: 31497e17e2369147fa40ab8b3f82cb2602ec9012
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: awa-odoo <awa-odoo@users.noreply.github.com>
This commit slightly changes the crm tour by changing the position of a tip
bubble.
During the quick creation (kanban) of a record, the tip text was placed on top
of the m2o selection proposals, making them hard to read / click.
We simply moved the tip text to the top of the selection instead.
Task 2373095
X-original-commit: 878bffce2582a3abbc9285631af947be78086e19
- Create a product with price 2335.5, no tax
- Start a POS session
- Add the product, set a discount of 3% on the line => total is 2665.44
- Validate and close the session
- Got to Point of Sale / Reporting / Orders, open the pivot view
The Total Price of the order is 2665.43.
It happens because the server returns a value of 2665.435, which is
displayed in the pivot view as 2665.43.
We round the Total Price based on the company currency decimal
precision. Indeed, all amounts are converted in this currency in the
report.
opw-2369023
closesodoo/odoo#62023
X-original-commit: 178d5c879ccf7ed59e602f049377417ace353fa9
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
before this commit: portal_rating_composer.js do not return anything, as it does
not return anything extending RatingPopupComposer is not possible, as
RatingPopupComposer loads template using xmlDependencies so inherting template
'website_rating.PopupComposer' is also not possible because if some other module
wants to extend 'website_rating.PopupComposer' template then it has to add extended
template by extending 'RatingPopupComposer' widget.
with this commit: RatingPopupComposer is returned in portal_rating_composer.js
closesodoo/odoo#62020
X-original-commit: 6514bb7071b30093ad27006cf46530262a742a39
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Install accounting app
- Go to "Charts of Accounts" view by setup panel
- Create a new record
A traceback occurs because `self.ids` is empty in the context of the
creation of a new record.
opw-2379463
closesodoo/odoo#62014
X-original-commit: b325266bc9d3893e037b3fd8d734ac7d3d510c41
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
As of v14 and #53335 (6c97a6d), access to `ir.actions*` models has been
restricted to admins, except in specific context such as via the
`/web/action/load` route.
This commit updates the `/website/action/` route to follow that logic,
and allow custom server actions to be exposed as "custom controllers".
The principle is that the action is located in a sudo environment, but
executed using the request environment. Access will only be permitted if
the model of the action is writable for the current user, or if any
action "groups" are set and the user belongs to one of them
(cfr f0d37c384b for that part).
closesodoo/odoo#62009
X-original-commit: ddf4c705ae0b83761495cd6a00d34463fa252043
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
Before this commit, the warehouse settings for MRP ("Manufacture to
Resupply" and manufacture step) wasn't displayed even if multi-step
rules is enabled until the multi-warehouse is enabled.
task-2376352
closesodoo/odoo#61482
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
To reproduce the error:
1. Invoicing > Reconciliation Models > Create
2. Add name
3. (Counterpart Values) Add a line
- Amount Type: Percentage of balance
- Amount: Something bigger than 100
4. Save
=> UserError raised ("The amount is not a percentage")
This is an error. A user should be able to set a percentage greater than 100.
The fix removes the constraint.
OPW-2375462
closesodoo/odoo#62010
X-original-commit: 2776209ba9a437c413dd5670c1695a06da909a5a
Signed-off-by: adwid <adwid@users.noreply.github.com>
When removing custom models from the registry, one also has to remove
indirect references to those model. One such reference is the name of
the custom model in its parent models' `_inherit_children`.
Not removing that reference causes a crash when one of the parent models
is extended: the parent model will make its children models recompute
some of their attributes (see method `_build_model_attributes`).
closesodoo/odoo#62008
X-original-commit: 07404bf5e93878b26468e2944c69885bbc688e57
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
The field `display_name` is a magic field automatically added to all
models. On a custom model, it depends on `x_name`.
As it is automatically added by the ORM, `display_name` is considered a
`base` field, while `x_name` is considered a `manual` field.
On loading the transitive dependencies of `display_name` of a custom
model, for which the loading of the `x_name` has been skipped because it
depends on field not yet loaded, the exception was not ignored because
exceptions are ignored only for `manual` field, and `display_name` is
considered a `base` field.
Upgrade request 56274
X-original-commit: e57e2798ed7871967487d953ffcdc10884bcf9a2
Co-authored-by: Raphael Collet <rco@odoo.com>
The compute `_compute_outdated` of `stock.inventory.line` didn't manage
inventory lines of different `inventory_id` because of the
ensure_one of `_get_quantities` (coming from
68518afe33).
Call `_get_quantities` by inventory and save it in a dict to be use in
the loop after.
closesodoo/odoo#62000
X-original-commit: e369f15a9194b530c14ad1c796e4f10b80338260
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
As part of QoL PR #26267 the way the recursion limit was
managed (where it is checked) was changed, effectively decreasing the
recursion limit by 1 (to the originally expected limit of 2).
According to #29877 this is an inconvenient change / regression in
e.g. accounting context: if an object has journal entries, updating a
field of a journal item requires 3 levels of indirection (entries ->
items -> field). The same would occur if an object is e.g. linked to
multiple projects (projects -> tasks -> field) or SO (-> lines ->
field).
Therefore bump the recursion limit up to 3.
Closes#29877closesodoo/odoo#61997
X-original-commit: 64ff41ce805c72eb700b45d55adfc7379de56862
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
This doc page details the extract API and has the following structure:
- Service explanation.
- Expected successful flow
- Description of the 3 routes (request and response structure)
- /parse
- /get_results
- /validate
- Hint for integration testing
closesodoo/odoo#61991
X-original-commit: af486cb87a0086d29ea45a31f3667458ad73e7fd
Signed-off-by: Florian Daloze (fda) <fda@odoo.com>
Signed-off-by: Sébastien Mottet <smottet@users.noreply.github.com>
PURPOSE
When opening the same form view 2 times in quick succession (e.g. clicking twice
on the name of an employee from a chat window), there is a traceback
SPECIFICATION
It should open public employee form and not raise any error
LINKS
Task-2371687
PR https://github.com/odoo/odoo/pull/61457closesodoo/odoo#61971
X-original-commit: 587ed5df5b542c6c6b3f13d1e348dd28d0da1f2c
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit, click on a button stat from the website dashboard, don't always respect the current filter.
Date filter was missing, website_id wrongly filtered, or domain not exactly the same.
Now, we try to align the dashboard data with the actions.
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#61936
Forward-port-of: odoo/odoo#61883
Forward-port-of: odoo/odoo#61333
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
Were missing the translations of the javascript code that was outside
of the static/src/js folders
closesodoo/odoo#61977
X-original-commit: 3fd53ad297ae84cddaafc6214f6de7060ebd48e9
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Since 14.0, the javascript code of snippets is moved inside a
/static/src/snippets directory.
With owl, the components are defined in static/src/components
Some other modules were using more exotic path and ended up with no
translations.
opw-2381030
X-original-commit: f1d403723d59b8e53b00cf2d26bd9d3d54437803
Steps to reproduce the bug:
- Let's consider a user U with access rights Inventory Amdinistrator
- Try to create an operation type with U
Bug:
An access error was raised because U has no rights to create an ir.sequence
record.
opw:2381272
closesodoo/odoo#61966
X-original-commit: 472fc28255ad29bcaaa7bd2f68a64018361b2665
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Before this commit, the python domain on sale.report would not get today's data
as it would do `date >= 2020-03-03`, but it means `2020-03-03 00:00:00`,
actually excluding today.
Then the JS domains to retrieve those data once you click on the metric (it
loads an act window with his domain + additional domain though js) would have
a different date domain, including today.
Note that there is still some inconsistencies between python and JS such as
last month filter which is in python (in template filter) today - 30 days
while in JS it is moment.subtract 1 month which might be 31 days.
X-original-commit: 23e65d70baf2444b35c81a10cdc09fee9d625c75
Those were removed with f9874b2b04 and restored in 14.0 (master at that point) with cc6000abfa.
This commit restores the missing filters for the context filters to work on
the view used in stable.
X-original-commit: 0fd1a8ce30ff83030577b95b2ac10669425671e9
Act window domain are used to load tree view data when clicking on dashboard
metric.
That metric is retrieved through domain in backend.
This domain part wasn't adapted in act window domain (can't use ref).
As searching on website is enough to get ecommerce order, this line can be
safely removed, it is an old code that was needed before website_id was set on
order, as it can be noticed in f6fc7c2319.
X-original-commit: b31abe06583c06dfc8b0df047d2659e657785b89
The metrics displayed on the dashboard are retrieved through a domain used in
`fetch_dashboard_data()` route.
When clicking on one of those metrics, an action is called with a domain.
This commit fixes incoherences between those domains.
task-2369420
X-original-commit: 84a759af1e29aa5181a6ccf08b1dec5e79f63586
Without this commit, when clicking on a metric on the website dashboard, it
would not load the correct data.
Indeed, the dashboard is loaded for a specific website only, but clicking on a
metric opens the data for every website together.
Step to reproduce:
- Make some orders on 2 differents website ecommerce
- OPTIONAL: Get through the payment on some orders, then just leave some
products in the cart afterward to have some unpaid orders
- Go to the website dashboard, you see some metrics
- Change the selected website on top right, you see the metrics adapts
correctly
- Click on a metric, it doesn't fit the number you clicked on. For instance,
if you had 1 Unpaid Orders for website 1 and 3 Unpaid Orders for website 2,
you see 4 orders in the tree view once you have clicked the metric.
This commit ensures the correct website is appended to every dashboard action
domain.
opw-2369420
Fixes#44926, fixes#51125
X-original-commit: 06f954787cf60e657768e365a15ea4513d459c0b
The ControlPanel has been converted in Owl [1], and the code using
it has been adapted accordingly. However, in the FieldX2Many, we
didn't properly wait for the ControlPanel to be updated (an update
of the ControlPanel was synchronous before owl, and is now async,
like every Owl renderings, as it waits for the nextAnimationFrame).
As a consequence, we might have tricky issues because the mounted
hook of the control panel might be called multiple times for a
single call to willUnmount later on. In mobile, we bind a global
event handler (on scroll) in mounted, and unbind it in willUnmount,
so we had leftover event handlers, that crashed when called after
the ControlPanel was destroyed. Note that even if the issue popped
in mobile, calling mounted on already mounted Components isn't a
good idea, and this should be fixed anyway.
The issue could be reproduced for instance in FieldService (with
collaborative pads activated in Project), in mobile, by opening
a task in Edit mode. Then, you might get a traceback by scrolling
after having discarded the edition
Here is a description of what technically happened:
- when clicking on Edit, all widgets (including the FieldX2Many
are destroyed and re-instantiated in 'edit' mode).
- the pad widget directly triggers a field_changed event which
causes a reset of the FieldX2Many (i.e. 'render' is called
again)
- the FieldX2Many detects that it already has a renderer (and a
ControlPanel) so it updates them
- it first updates the renderer, and when it's done, it updates
the ControlPanel BUT doesn't wait for its promise, so the
promise returned by that call to 'render' in FieldX2Many is
resolved before the ControlPanel is actually updated
- note that at this point, all thoses new widgets are not in the
DOM yet
- when all widgets are ready, the renderer patches the view (i.e.
the former content is removed from the DOM, and the new one is
attached into the DOM). As soon as this is done, the renderer
calls 'on_attach_callback' on its children, including the
FieldX2Many, which leads to a call to 'mounted' on the CP.
- then, just before the nextAnimationFrame, Owl complete the
rendering of the CP, and detects that it is now in the DOM (it
wasn't at the beginning), so 'mounted' is called a second time,
will cause the issue described above.
This commit fixes the issue by properly waiting for the CP to be
rendered in the FieldX2Many. However, this required on cascade
changes:
- Form view renderings with a FieldX2Many are now *really* async
(+- 16ms), meaning that the user can easily trigger concurrent
renderings by, e.g. clicking quickly several times on 'Edit',
'Save' or 'Discard'. Concurrent renderings are properly handled
so to prevent this from happening, we disable the buttons and
re-enable them when the rendering is done (like already done in
[2])
- in the FieldX2Many, '_updateControlPanel' was called at several
placed, but we never waited for it. As this method was
originally sync, its calls have probably been naively adapted,
whereas their should have been deeply rethought (for instance,
as it is async, and we need to wait for it, we don't want it
to be called multiple times sequentially when something happens).
This commit does that work, i.e. we clean the places where this
function is called such that it is (hopefully) never called
sequentially twice. To do so, we changed a bit the spec of the
pager in multi page, and we also fixed a paging-related bug.
In a few words, here is what we did/do when adding a new row
in the bottom of a full page:
- before: tweak the count in the data to fool the pager and
make it think that no new record has been added (so
basically, let it display something wrong)
- now: temporarily increase the pager limit so that the new
record is displayed on the current pager, and the pager
values are correct w.r.t. the displayed records.
Some tests needed to be adapted accordingly.
- By waiting for the ControlPanel when updating the FieldX2Many,
a bunch of QUnit tests failed. Those tests have something in
common: they spawn an X2Many (list or kanban theoretically,
but always list in practice) containing a FieldBoolean (only
field widget of /web converted in owl). When the FieldX2Many
is updated, we update the renderer (i.e. re-renderer the
FieldBoolean, so we have to wait for the nextAnimationFrame),
and when this is done, we update the page (again, we have
to wait for the nextAnimationFrame). So basically, we have
to wait for two nextAnimationFrames to see the result in the
DOM. For this, we added a new test util which basically does
a nextTick ('owlCompatibilityNextTick'), and called it
everywhere it was necessary. When everything will be written
in Owl, we could get rid of this util and its calls.
[1] https://github.com/odoo/odoo/commit/fbf347498f1cc7b74ef373179b7bcae201715c24
[2] https://github.com/odoo/odoo/commit/39f08950d6e20460e3a20a5b9c33e4ddf66dce78closesodoo/odoo#61926
X-original-commit: e8e64f75606f1501a8be7b0bb418a296cfd8be61
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In previous versions of Odoo, in the New message box, typing a few
letters of the name of your recipient and pressing Enter would
automatically select the conversation with this contact.
Since 14.0, one has to select the first result with the Down key.
This commit restores the previous behavior by using the
[`autofocus`](https://api.jqueryui.com/autocomplete/#option-autoFocus)
option.
closesodoo/odoo#61967
X-original-commit: addd392a1b5f7e569c65a4503152ba0bdfe49eb3
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
This change highlighted issues with the async behavior of `useUpdate`, which
was no longer necessary and therefore reverted.
This in turn highlighted issue with animation of chat window unfolding, making
restoring of scroll position not work as intended due to the message list not
having its whole height available during some time after render. This animation
being minor (and even annoying in some cases) it was decided to remove it.
task-2387729
closesodoo/odoo#61962
X-original-commit: f22c34e7f61f7f8ac5b9ab7f9579cc4e6dd0e334
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Steps to reproduce the bug:
- Delete the current website
- Go to homepage
Bug:
An error 500 was displayrd
opw:2381929
closesodoo/odoo#61959
X-original-commit: ae6515a5fb849a4b561b87eaa5c78035771a17b8
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Victor Feyens