Description of the issue/feature this PR addresses:
A traceback appears when a time off is at the second approval stage and approved with several employees assigned to the time off.
https://www.awesomescreenshot.com/video/5408638
Current behavior before PR:
When validating a time off that is in the second approval stage with several employees assigned to, a traceback appears
Desired behavior after PR is merged:
No traceback appears when validating a time off that is in the second approval stage with several employees assigned to
task-2657656
closesodoo/odoo#77625
X-original-commit: aaa7c5bf10089eb8953f46cccb2e93aa3a20fa35
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Because test cursors are implemented using savepoints, they should *at
most* be nested (ideally they would be strictly sequenced).
If upon being closed a test cursor finds a *different* un-closed
cursor at the top of the stack, one of its followers / children /
descendants was not closed before it, which is a problem.
The initial version of this would look for the cursor being closed in
the stack but this could lead to incoherent cursor stacks and errors
related to the management of the cursors stack, even though it only
exists for reporting reasons.
closesodoo/odoo#76243
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Initialize the savepoint semi-lazily (on-demand) as cycling a savepoint
generates 4~5 queries (depending whether the savepoint is explicitly
released on COMMIT or not):
SAVEPOINT
-- < do stuff>
-- commit
RELEASE SAVEPOINT -- or not
SAVEPOINT
-- close
ROLLBACK TO SAVEPOINT
RELEASE SAVEPOINT
With a lazy savepoint, this is just 0-1 queries (`SAVEPOINT` at the
first explicit query only, creating a cursor and then closing it
immediately is a no-op).
For reliability use a semi-lazy savepoint: always immediately emit a
`SAVEPOINT` on cursor creation, but don't automatically create one
after each `commit`. That limits the issues of overlapping (but
non-nested) savepoints.
Also fix the `generate` API to not use the request: when `website` was
converted to the new API, `cr`, `uid`, and `context` were dropped as
if it were a model... but it's not. So in order to recover an
execution environment, that was looked up on the session.
That, then, turns out to be an issue when `generate` is triggered from
an RPC call: the RPC layer creates its own cursor and environment
separate from the request's which may not have one at
all. Problematically during testing we're in `mono_db` mode, so the
request's cursor/env can be accessed and will be lazily initialized.
This then causes an issue with the `TestCursor`'s savepoints: rather
than be nested, the lifetimes of the request's and RPC's savepoints
only overlap[0]:
|-- rpc --|
|-- request --|
As a result, when the RPC's cursor is committed and released it
automatically released the request's, and the request's explicit
release then fails. This would break `/website:WithContext.test_search`.
By fixing the API of `generate`, it stops triggering the creation of a
request cursor, and therefore the overlap and resulting error.
[0] the laziness or eagerness of the savepointing in the test cursor
has no impact on this issue, as multiple requests have already been
issued on the RPC's test cursor before the request's is even
created
Part-of: odoo/odoo#76243
The query count increases by one because the old code (with
hand-rolled savepoints) never released the `model_load` savepoint.
Part-of: odoo/odoo#76243
Ensure savepoints are *always* released when exiting the context:
rolling back to a savepoint does not release it, so the savepoint
would remain "active" forever (just possibly shadowed).
Also provide a `Savepoint` object to the user, with the following
facilities:
* `name`, in case there are useful things the user can do with a
savepoint name.
The name uses standard UUID representation (rather
than pure hex) because it's otherwise difficult to differentiate
savepoints: in a UUID1, fields 2, 3, and 5 almost certainly don't
change, and the changes between two UUIDs are the last 2-3 nibbles
of field 1 (`time_low`) and the content of field 4 (`seq`, 4 nibbles
at offset 16), with "properly" separated fields it's much easier to
notice the difference.
* `rollback` allows the user to rollback the savepoint to the
initialisation state at any moment.
* `close` allows the use of `contextlib.closing` as well as closing
the savepoint while in the covered span. Closing a savepoint rolls
it back by default (like cursors).
Because there's no such thing as committing a savepoint, it's also
possible to close *without* rolling back, which is similar (but not
identical).
This requires using the semantics of emitting the `SAVEPOINT` during
object initialisation: `closing` was designed to work with non-CMs so
it does not forward `__enter__` to the wrapped object.
Also introduce a CM type for the flushing:
* `_GeneratorContextManager` does not work well when used outside of a
`with`, especially when it yields something: if the CM itself goes
out of scope, the inner generator is `close`d, which raises a
`GeneratorExit` at the `yield` point, which `__exit__`s whichever CM
is held (and in our case would thus rollback and release the
savepoint)
* we probably want to clear() on `rollback`, so having the flushing CM
extend the savepoint one makes a lot of sense
* while it changes the semantics of `Cursor.savepoint` a bit (now
initialises the savepoint at call time instead of delaying until
`__enter__`), it enables the use of `closing` with flushing, and
without having to use the context manager objects directly:
`Cursor.savepoint()` is the only necessary interface, and should
work fine with and without flushing.
Part-of: odoo/odoo#76243
Enabling sql logging for a specific section of code is currently a
pain in the ass as it requires updating both the cursor and the
logger. This utility does that.
This CM is *not* thread-safe as it updates and resets the cursor
without using CAS or anything, so if cursor 1 gets enabled, then
cursor 2, then cursor 1 stops, then cursor 2, cursor 2 will reset the
logger to `logging.DEBUG` which cursor 1 had set, rather than the
probable `logging.NOTSET` it originally was.
Should be possible to fix by e.g. storing the levels in a static
stack (and setting whatever gets popped) buuut... the logging is
already a bit of a mess when multithreaded so I'm unsure it matters
much.
Part-of: odoo/odoo#76243
If `_name_search` is called with `limit=None` it could take time in the loop
because `_name_search` for `product.product` has `limit=100`, i.e. it could be
100 iterations to scan 10 K products. To solve this problem, call `_name_search`
with `limit=None` to get all product variants at once.
As an example, the problem is reproduced on using menu `Manufacturing > Products
> Bills of Materials`, which makes following search query:
```
["|", ["code", "ilike", "XXX"], ["product_tmpl_id", "ilike", "XXX"]]
```
for which ORM calls `_name_search`:
https://github.com/odoo/odoo/blame/9b23864027bc24032993833f213395cb45fe86bb/odoo/osv/expression.py#L863
In a customer database, this speeds up the query from 70 seconds to 3,5 seconds.
---
opw-2631012
closesodoo/odoo#77601
X-original-commit: 038816725a988a0ada3d6f8518a436ea46a81eba
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>
For the "Archive"/"Unarchive" button to appear in the contextual "Actions" dropdown,
the field must be present in the view (which wasn't the case until now).
This commit also fixes the indentation of the concerned view.
closesodoo/odoo#77596
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Add _auto_init for stock_picking.sale_id
to speedup the module installation.
Since its related field, group_id.sale_id is also
created in sale_stock, creating the sale_id column is
enough.
opw-2638554
closesodoo/odoo#77546
X-original-commit: bb16d3e9733a669110a16a1341d56eb3420c8ca2
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Armageddon tax being created should include mandatory country_id,
which should be the fiscal country of the test company.
closesodoo/odoo#77295
Related: odoo/enterprise#21208
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
"account_tax_group.xml" and "account_data.xml" data files
have been renamed to "account_tax_group_data.xml"
when containing only tax groups, for compliance with the standard.
AE, AR, AT, BE, BO, BR, CA, CN, CR, CZ,
DE SKR03, DE SKR04, DO, ES, FI, FR, GR,
GT, HN, IL, IN, LT, MA, MX, NL, NO, PA,
PL, PT, RO, SG, SY, TH, TR, UA, UY, VE,
VN.
Part-of: odoo/odoo#77295
Many changes involved several localizations.
Tax groups data files that were missing the country_id:
AR, AU, EC, ET, HR, HU, IT, JP, LU, MN, NZ, SI, UK, ZA
Account_data.xml files being renamed or split to account_tax_group.xml
AT, CH, CL, PE, SK
Tax templates that were missing tax group information:
CH
Tax groups missing that were added:
EC
Part-of: odoo/odoo#77295
L10n_co taxes still needed their correct tax_group,
which has recently become a required field.
The tax groups have been assigned by rate and type.
Part-of: odoo/odoo#77295
The account.tax_group_taxes is the default group for every localization.
Its name shouldn't be overwritten by any localization, otherwise
any company actually using another localization will see the
name of the tax group in a language he doesn't understand.
Part-of: odoo/odoo#77295
The partner created in TestOnchangePostal and the product created in
TestSwissQR were taken from demo data, which might not be installed
in the test environment, so the create_invoice() method could
raise a traceback.
Part-of: odoo/odoo#77295
In Belgium, selling taxes "21% S." and "21%" are exactly the same.
"21% S." can then be removed.
No need to distinguish Services on Domestic Sales.
closesodoo/odoo#77549
Task: 2653824
X-original-commit: 11fd24856e436136236d67f01dd88acc00105e9b
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
When printing particular reports without specified record IDs, an indexError
occurs, therefore preventing the printing. This PR changes the way the data
is get from the url by using url_parse instead of string.split('?'), which
sets the data to an empty dictionary if no params exist in the url.
task-2552160
closesodoo/odoo#77471
Related: odoo/upgrade#2694
Related: odoo/enterprise#19808
Signed-off-by: Arnaud Joset <arj-odoo@users.noreply.github.com>
Update a specific flow to ensure the record on which session_info is
called has guest in its context. This is needed because session_info
performs some checks on guest to determine if it should add translations
data.
closesodoo/odoo#77433
X-original-commit: bd0940cdbf43131ed8436a5deb3f8afebfbc37ab
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Though it can't really be typechecked it makes clearer what the
expectations are.
closesodoo/odoo#77577
X-original-commit: b28d2f5b9f7ca0656afe8020c1fa4b3c4eb5594b
Related: odoo/enterprise#21336
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
With this commit, the 404 image is now using the theme color.
Not only it will be displayed in the secondary color, but it will also gets
updated when the theme color is changed.
This one was waiting for the new editor to handle inline svg as regular img
(task-2497786) but in the meantime, the website is now capable of doing that
another way, as does in this commit.
task-2659182
closesodoo/odoo#77569
X-original-commit: f1f2ba8ede7641c79eb48412090ce63655ccf831
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Before this commit:
UTM campaigns are accessible to all internal users. But with sale module
installed, few of the fields are added into the `utm.campaign` model and
it's views. Those fields contain information related to quotations and
invoices. So if the internal user who does not have the basic sales rights
tries to access the campaing, an AccessError is raised.
With this commit:
We only show those fields in the views to the users having enough rights
("sales_team.group_sale_salesman") and thus allow other internal users
to access the UTM campaings without AccessError.
Task-2417993
closesodoo/odoo#77558
X-original-commit: eda33edbbd8fac2592c97a4c333f5c92a288c63c
Related: odoo/enterprise#21328
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Previously when creating an applicant through the calendar application,
no activity would be created making the newly created record not show up
in the calendar because it depends on the activities linked to the
record.
A calendar event will now be created upon creation through the calendar
view in order for the applicant to be displayed directly.
Also fixes an issue where if no contact is set on the application it
would prevent you from refusing it.
TaskId-2641495
closesodoo/odoo#76831
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Before this commit when computing the deepest position for a non-visible
node, if that node had no next visible sibling it used the previous
siblings, but it still marked the offset within that sibling as 0.
Because of this, the selection sometimes got lost.
E.g. in Firefox, drop an "Image - Text" block and triple click on the
header text: upon changing its color the range got set to the text node
but ending at offset 0.
After this commit if the used node in the "previous sibling" from the
evaluated element, the offset is set to the length of that node.
task-2655176
closesodoo/odoo#77567
X-original-commit: 3c4426c71ebe080bcbd285e271c61bf1580c3afa
Signed-off-by: Antoine Guenet <Zinston@users.noreply.github.com>
Signed-off-by: Benoit Socias (bso) <bso-odoo@users.noreply.github.com>
Steps to reproduce the bug:
- Create a product and enable serial number option
- Create one “on hand qty” with SN e.g: “001”
- Create a SO for SN product
- Confirm SO and check the delivery order
- In the Operations tab > Enable Serial Number field
- “001” SN is already reserved in Detailed Operations and the qty done is 0 but the Serial Number field in “stock.move” is empty
- Edit and add “001” in the SN field
- save
Problem:
- The SN is deleted and the quantity done in the `”stock.move.line”` is not updated
Solution:
Update the quantity done in the `“stock.move.line”` linked to the selected SN
opw-2623101
closesodoo/odoo#77564
X-original-commit: abc9fdaae2927214d98082f391a1dc0fc75e4c77
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
How to reproduce the problem:
- Install the Employees app
- Create a new user and create an employee form for this user
- Log in with this user, then log out
- On the user's Employees form, the employee still appears as connected
Cause of the problem : as soon as a user logs in,
the system saves the date of his last connection. That value was wrongly
used in the process of computing the user's status.
Now, if the user is offline, he is shown as "Not Available" or "Away"
(grey or orange).
opw-2623386
closesodoo/odoo#77545
X-original-commit: e2991ff6121fee790ef6ead1354cec250428835c
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Remove useless CSS that lead to wrong behavior with popups.
closesodoo/odoo#77573
X-original-commit: 2eaae91ca1c6b466dbd3fd28d65910ea05ea5545
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
-- This is a follow-up of odoo/enterprise#72736 --
The project overview is a significant technical debt
as it is a custom qweb view. It is quite limited:
It is not possible to group the data, to filter on dates,
SOs or Field Service projects.
Improving this is very difficult and would require weeks
of development that are not worth it.
In any case, all the information provided by the project overview
can be found elsewhere. The stat buttons of the report are basically
duplicates of the ones from the project form view.
Therefore, we are removing this report and its twin,
the Project Costs and Revenues.
In addition, analytic items lack context for the user to understand
what generated a certain cost or revenue:
there is no link to the source document;
the entries are not categorized (e.g. it is not easy to understand
if a cost comes from a timesheet cost, a purchase order or an expense);
the billable type group by works fine for timesheets but then all
the other entries are flagged as Undefined, which is not very helpful;
there is no option to easily isolate costs from revenues.
task-2637495
See odoo/enterprise#20740closesodoo/odoo#77547
X-original-commit: 9bbfd3c8f948a3a947cbc0eb73ffc5d89c23d4ca
Related: odoo/enterprise#21324
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
Before this commit, a user could DM a portal user.
Portal user are not supported and can't chat.
task-2632874
closesodoo/odoo#77568
X-original-commit: a7eda6d7314e7261ddda32620fae817f1d828bae
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
When adding an odd width images on website, a thin black line is
drawn on its right side. The problem comes from the getSourceCanvas
of the cropperjs library. A translation is applied followed by an other
translation in the opposite direction. However the second translation
was not the exact reverse of the first due to a rounding problem.
The fix proposed here comes from: https://github.com/fengyuanchen/cropperjs/pull/300/commits/a6481c052cfc93ef14dd95a3bd00142215dda36e
task-2652904
closesodoo/odoo#77562
X-original-commit: 53f13979cc363c74a8f4e2cec0d24ca10c6ac11c
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When registering/creating payments, filter out from the selection
the journals that do not have any relevant payment method lines.
Also, always show payment method lines even when there are only
one of them.
closesodoo/odoo#74741
Related: odoo/upgrade#2861
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
If the name is not known, fallback to the displayName.
closesodoo/odoo#77553
X-original-commit: 50f3581df712d5f2cbb6481f7fcb8c164ebb2da2
Signed-off-by: Samuel Degueldre <sdegueldre@users.noreply.github.com>
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
The current threshold seems to high for most people. It is preferable to catch
too much sound and then request people to increase the threshold, than catch too
little and have frustrating experience of not hearing people talking at all.
X-original-commit: 59aa5b3c209bc6717cd95266c62fc8b1abb68475
Part-of: odoo/odoo#77553
Problem: When installing the Austrian localisation no demo company is
created.
closesodoo/odoo#77552
Solution: Create demo_company.xml and add it to the manifest
Task: 2631136
X-original-commit: ec98c8cf08c37981db13ea664275b05ef9ea5c72
Signed-off-by: Josse Colpaert <jco@openerp.com>
Previously the configurator retrieved the snippet lists
needed to build the website pages from IAP. These lists
have been put in the theme manifests and can be accessed
from it.
odoo/design-themes#505odoo/iap-apps#411closesodoo/odoo#77550
X-original-commit: 01c97c697aa0c5cae79952f1d3ac8de69bf2ad1a
Related: odoo/design-themes#510
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
The message 'Don't worry, you can switch later' and a close icon
redirecting to the website are displayed in the control panel of
the theme kanban view. When we reach this kanban view from the
website settings we want to hide this message and this icon.
task-2610896
closesodoo/odoo#77548
X-original-commit: 72ed96c6febf299dac9b352714c6d5ba05508446
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
In some contexts, an error caught by the error service has no stack,
trying to annotate the stacktrace of this error with the Stacktrace
library crashes, masking the original error which is unwanted.
closesodoo/odoo#77421
X-original-commit: 347ddcc06e23d8f1a94c06379b2bfe104b116d90
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This commit will merge welcome and thread views in the same route and
template. The aim is to make the user interacting with the page (by
landing them on the welcome view first) so that the browser allows the
page to play audio and to switch to full screen.
closesodoo/odoo#77381
X-original-commit: 97ed683e3e7cc6b340bb78c4faa01a703a573f32
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
The empty string, the forward slash `/` and NULL are all to be
considered as without a sequence set on `account.move`.
While this is just true, it was detected because of non deterministic
bugs at the end of the month because the tax closing move was
explicitly set to an empty string on version 14.3 and higher.
See: https://github.com/odoo/enterprise/commit/4641825daa0ed3b8e407fb3817c582cb541e88a4
Most of the tests posting an entry in the MISC journal could then
randomly fail on the last day of the month.
closesodoo/odoo#77532
X-original-commit: 9ed77eb3eee660a77a90c231258b69968e3b8df2
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Since [1], a footer effect option has been introduced which allows to
have the content hovering the footer to then reveal it when reaching the
bottom of the page (instead of having the footer to scroll like the rest
of the content).
To achieve that, the body color was forced on the snippet container (the
`<main/>`) so that the transparent snippet still appear with a
background color for the time they go over the footer.
That background color should however not have been forced in non-full
layouts as another is already forced in that case. In those non-full
layout, the "full" body background (= background of color combination 1)
is applied on the snippet container but the "body" color is another
color which is customizable by the user too.
[1]: https://github.com/odoo/odoo/commit/5879e40445f0176d545b4a50f7f7ec33b2e171c8
Related to task-2590182
closesodoo/odoo#77531
X-original-commit: b0f03cb1d628d29b8a67fc954dc40877dfd1783e
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
ISSUE:
The click on "THEME" tab in editor panel triggers the
'_onThemeTabClick' method which:
1- Starts the loader ('_execWithLoadingEffect' method).
2- Runs '_activateSnippet' which uses the same mutex as the
loader.
Execution order:
A1- '_execWithLoadingEffect' with promise: adds the loader in
the DOM immediately.
A2- '_activateSnippet' sets a second loader to be added after
a delay = 500.
A3- 'releaseLoader' removes the first loader.
A4- '_activateSnippet' ends : (before adding the second
loader: t(4) - t(2) < 500) and timeout is cleared.
In some cases we get t(4) - t(2) > 500 which adds a second
loader to the DOM, and the new flow will be:
B1- Same as A1.
B2- Same as A2.
B3- Second loader added to the DOM / replaces the first one
in 'loadingElements'.
B4- 'releaseLoader' removes the second loader (from the DOM
& 'this.loadingElements').
B5- Same as A4 but the first loader still in the DOM.
The goal of this commit is to fix this behaviour by preventing
more than one loader on the target element.
task-2656308
closesodoo/odoo#77500
X-original-commit: 9f21b2eefab2115c1b8581ad9f43fe1e65f934ed
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This merge will improve the layout of the mail composer and the resend modals
* revamp the mail composer and the resend modals: It will update the labels,
clarify the helper messages and make the buttons more dynamic;
* simplify the mail composer: advanced options will be placed in a dedicated
pane;
* various minor layout adjustments;
See commit messages for more info.
Task-2523036
closesodoo/odoo#71413
Related: odoo/upgrade#2877
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When the user opens the notification panel from the navbar and click on
a notification indicating that an error occurs while sending an sms
or an email, the user will be redirected to a new view listing the users
that did not received the sms or the email. As it makes no sens to create
a partner from that view, we will remove the "CREATE" button.
task-2523036
Part-of: odoo/odoo#71413
Philippe Wauthy