When the crm.lead is of type 'lead', we don't want to display the
"Customer" field on the form view unless it's set (or debug mode).
Indeed, most of the times leads will not have this information set,
since when we assign a Customer we usually convert the lead to
an opportunity as well.
This means that on the lead form, we don't want to display this field
since it may be misleading for the end user.
When it's set however, we want to display it, mainly because there are
a few automatic synchronizations between the lead and its partner
(phone and email for examples), and this needs to be clear that modifying
one of those fields will in turn modify the linked partner.
Task-2596955
closesodoo/odoo#76233
Signed-off-by: awa-odoo <awa-odoo@users.noreply.github.com>
Having the same VAT fiscal position for the same region multiple times doesn't make sense and is not supported by the report enfinge. We should prevent that.
closesodoo/odoo#77663
X-original-commit: d9dfeeb498dab359df52db87ff601d68fcf0ad7c
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
The 'Country Group' field should be displayed under the 'foreign VAT' one, so that it its grouped together with 'Country' and 'Federal states'.
X-original-commit: 302586c6b35825e19945b92faa48ccc892179ea6
Part-of: odoo/odoo#77663
* = test_discuss_full
Before this commit if 2 persons are joining the call at the exact same time, the
join RPC of each will return the list of RTC sessions without the other person
included.
In more general terms, the server should actually rarely send the full state to
the JS (in this case "use the replace command") because there is no guarantee
that a concurrent transaction is not changing the data at the same time. In
other words, even the python is actually working with partial knowledge
relatively to the database.
Using a DB lock would guarantee it, but we don't want to lock tables and wait on
locks if there are alternatives. In this case it is acceptable to keep obsolete
sessions for a little bit longer, as long as they are cleared eventually.
closesodoo/odoo#77656
X-original-commit: d3a84172fc78f5783f75aa1155f1a25e4f9614b7
Signed-off-by: Samuel Degueldre <sdegueldre@users.noreply.github.com>
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
It could take seconds to annotate a simple stack trace, it is therefore not
suited at all for quick logging as we do in RTC.
It's unfortunate but acceptable to just log the non-annotated stack trace in
that case.
X-original-commit: 8b3495c489c274e878d2a0938ea29b4da17710aa
Part-of: odoo/odoo#77656
This commit adds a test in order to strengthen the behaviour of
recurring subtasks.
This test asserts that child with depth > 3 are not copied in a
recurrence, that recurrent subtask are well copied with the recurrence
correctly set.
This commit prepares the recurrence refactoring.
task-2660756
closesodoo/odoo#77632
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
Issue: With margin enabled and avco for stock valuation, after
confirming a SO with a product variant which is a bom kit,
when we try to change the variant, there is a traceback
Steps to reproduce :
1) Install Stock, Accounting, MRP, Sale,
2) Enable Margins in settings
3) Configure a Product Category with costing method AVCO
4) Configure a Product with 2 variants and that product category
5) [Important: KIT] Create 2 BoM, one for each variant and set those
BoM to KIT
6) Create a SO for that product and one variant
7) Confirm the SO, cancel it, and set to quotation
8) Edit the SO and change the variant, save
-> Traceback
Side-Note:
This issue is due to the fact that we iterate over the stock_moves to
find the quantity of the BoM, but that stock_move correspond to
confirming at step 7, when we change the variant at step 8, the stock
move has not changed, so still contains the previous bom_line_id with
the quantity, but this doesn't reflect with the new state of the SO
which is for a different variant.
For me since the stock move is canceled, it should be taken into
consideration when computing the average price but I might be wrong,
it's up to the reviewer to decide if it makes sense
opw-2639093
closesodoo/odoo#77606
X-original-commit: c0d4ed5ac641d339a6cd4e23db9667048d35360d
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
When invoicing via POS delivery address is missing on the invoice.
This value is needed in some localizations (i.e. l10n_co) to correctly
validate the invoice
opw-2653661
closesodoo/odoo#77556
X-original-commit: d57a44d875eabba0586e24245a9af435169fda22
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Steps to reproduce the bug:
- Create a promotional program P with 'Fixed amount' discount of $50 and 'Automatically applied' on current order
- Create SO and cancel it
Bug:
P was applied on the canceled SO
opw:2579344
closesodoo/odoo#77455
X-original-commit: 8f11cabcb605cab5c83e4889156e4979d55aa517
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Previously, the land page of Time Off was month view. When you select a leave from Month's view, you can edit/delete it directly.
Now, the land page is Year's view, and you can open the modal form of the leave, but it's not possible to delete it.
Add a delete button on the form view of the leave from the year's view of the dashboard
task-2638305
closesodoo/odoo#76080
Signed-off-by: Kevin Baptiste <kba@odoo.com>
No menu allowed viewing all tax groups at once before. With the new subtotals features, it could become painful for the user if he wanted to change the groups' sequence in order reorder subtotals on his invoices (he had to change the sequence manually on each group, accessing their form view through taxes using them). It is now possible in the tree view opened by our new menu, with the sequence widget.
X-original-commit: 708899fc0e1a793f29884d82b34ba6c492461737
Part-of: odoo/odoo#77662
"Rounded" and "Flat" buttons didn't have their proper styling
if the website module was not installed.
Styles for rounded and flat buttons have been added to theme_default.scss
closesodoo/odoo#77661
X-original-commit: 74540364428e9d5a308a1012ae8614aa37ecb8a6
Signed-off-by: Antoine Guenet <Zinston@users.noreply.github.com>
Let us assume we have a slow network and a (new) search bar with two
items, one of them expandable.
Before this commit, click to expand that item and then hover the other
item quickly would not end in a situation where the item is expanded.
This was due to a naive concurrency management in the (new) SearchBar
component.
In this commit, we allow to focus another item (via the mouse or the
keyboard) without cancelling an ongoing asynchronous operation.
closesodoo/odoo#77655
X-original-commit: 6fc0c5ee2d1d68bf82a034fe1744ac5673e522c9
Signed-off-by: Mathieu Duckerts-Antoine <Polymorphe57@users.noreply.github.com>
This commit removes all the 'extend' initially introduced to avoid code
repetition and ensure visual consistency across Bootstrap and Owl dropdowns.
Despite achieving the desired results, using 'extend' in this context
was seriously impacting the bundle generation time, probably due to an
underestimated amount of Apps' legacy-code applied on these elements.
In order to achieve the same results, the chosen strategy is to add
Bootstrap default classes directly into Owl dropdowns.
Also, it moves code related to bootstrap dropdown in 'webclient.scss',
leaving 'core/dropdown/dropdown.scss' for Owl code only.
Due to the discrepancies between Bootstrap and Owl html
structure, the '.dropdown-item' class could not have been added
directly to Owl's '.o_dropdown_item' itself, without refactoring
the Dropdown component structure.
// ==== Bootstrap 4.6 default Structure ================================
<div class="dropdown-menu">
<button class="dropdown-item" type="button">Action</button>
<a class="dropdown-item" href="#">Another action</a>
</div>
// ==== OWL default Structure before this commit =======================
<ul class="o_dropdown_menu">
<li class="o_dropdown_item">
<span>Action</span>
</li>
<li class="o_dropdown_item">
<a href="#">Another action</a>
</li>
</ul>
// ==== OWL Structure after this commit ================================
<div class="o-dropdown--menu dropdown-menu">
<span class="dropdown-item">Action</span>
<a class="dropdown-item" href="#">Another action</a>
</div>
// ==== web.assets_backend.css Bundle Generation Comparison ============
With all modules installed (enterprise edition over runbot):
Before this commit, bundle took ~2.5s and ~4s to generate and weighted ~322kB (~2.5MB uncompressed)
After this commit, it takes between ~1.2s and ~1.6s and weights ~257kB (~1.6MB uncompressed)
closesodoo/odoo#77649
X-original-commit: 84715436d87bb05b421bc9ccaacda67d07571690
Related: odoo/enterprise#21370
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Co-authored-by: Stefano Rigano <sri@odoo.com>
Co-authored-by: François Georis <fge@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
Since commit a1f286916d o_cp_action_menus is not centered
anymore as justify-content: space-between; was removed from scss.
with this commit we are making o_cp_action_menus centered again.
task-2628050
X-original-commit: 590d0ca81382d4c3d6007bdf9bf65ed3a0ed795e
Part-of: odoo/odoo#77649
Facturx expects line price to be subtotal, not unit price. Odoo parser
is also dividing the gross price by quantity. So before this commit,
importing PDF invoice rendered by Odoo, results in: unit price / quantity.
The bug was introduced in odoo/odoo#53894closesodoo/odoo#77527
X-original-commit: 3769a6cdda259a839f00267d99a57f2aa3d89aa1
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Given that we have a viewport of 320px and, to simplify the explanation,
we discard the height of the <header> (aka. the top navbar).
Since the refactoring of Discuss [1], a global rule was added to the
'.o_action_manager' to allow the flex to shrink the discussion's list
in Discuss on Mobile.
But this rule change the box sizing of '.o_action_manager' as now it
takes the minimum size (e.g. before 3000px became now 320px +/- the
height of the viewport).
Therefore a limit for the sticky-scroll behaviour of control panel is
set at the end of the height of the element.
Then when the viewport goes outside this limit the sticky doesn't work
anymore until the viewport returns before this limit.
(e.g. <= 320px ok, > 320px ko).
The fix is to change the flex basis of the '.o_Discuss_notificationList'
to be 0 which avoids to alter the global '.o_action_manager' and scopes
rules to Discuss' specific classes.
DOM before this commit:
┌───────────────────────────────────────────────────────┐
│ '.o_action_manager' ▲ │
│ │ │
│ │ │
│ │ │
│ │ │
│ │ │
│ ELEMENT HEIGHT │ │
│ = 'VIEWPORT' │ │
│ 320px │ │
│ ┌────────────────────────────────────────────────┐ │ │
│ │ │ │ │
│ │ │ │ │
│ │ │ │ │
│ │ Control Panel │ │ │
│ │ │ │ │
│ │ │ │ │
│ │ │ │ │
│ │ │ │ │
│ └────────────────────────────────────────────────┘ ▼ │
│ - - - - - - - - LIMIT OF STICKY ELEMENT - - - - - - - │ <- 320px
│ ▲ │
│ │ │
│ OVERFLOW │ │
│ VISIBLE │ │
│ │ │
│ ▼ │
└───────────────────────────────────────────────────────┘
DOM after this commit:
┌───────────────────────────────────────────────────────┐
│ '.o_action_manager' ▲ │
│ │ │
│ │ │
│ │ │
│ │ │
│ │ │
│ │ │
│ │ │
│ │ │
│ ELEMENT HEIGHT │ │ <- 320px
│ >= 'VIEWPORT' │ │
│ 3000px │ │
│ ┌────────────────────────────────────────────────┐ │ │
│ │ │ │ │
│ │ │ │ │
│ │ │ │ │
│ │ Control Panel │ │ │
│ │ │ │ │
│ │ │ │ │
│ │ │ │ │
│ │ │ │ │
│ └────────────────────────────────────────────────┘ ▼ │
└───────────────────────────────────────────────────────┘
Steps to reproduce:
* Open Odoo on Mobile
* Go to a Kanban view with list height at least twice the screen height
* Scroll to the end of the page (the control panel is hidden)
* Scroll a bit upper => BUG the control panel is not visible until we
scroll in the 'box' of the '.o_action_manager'
Note this behaviour is maybe related to an issue from CSS3 [2]
from MDN [3]
Ref:
[1] odoo/odoo@3fea5b2136
[2] Issue 865 on https://github.com/w3c/csswg-drafts
[3] https://developer.mozilla.org/en-US/docs/Web/CSS/positionclosesodoo/odoo#77660
X-original-commit: fdcfaa7b72a4af0d0c3e308e299638fc8fa19bdb
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Pierre Paridans <pparidans@users.noreply.github.com>
Signed-off-by: rfr-odoo <rfr-odoo@users.noreply.github.com>
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>
dht-odoo