How to reproduce:
- Create a tracked product using expiration dates and don't set the
`expiration_time` field;
- Create a receipt for this product (using "Create New Lots/Serial
Numbers") and confirm it;
- Create a move line for this product and define an expiration date;
- Valid the picking -> Traceback.
The issue was as `expiration_time` isn't set on product, the production
lot created on the receipt's validation don't have an `expiration_date`.
So, if the `expiration_date` is set on the receipt move line, the
production lot will try to get a time delta with its unset
`expiration_date`, causing the traceback.
task-2119330
closesodoo/odoo#39795
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Purpose
=======
Allow to add an attribute ``show_unusual_days="True"`` to display
some days in green, according to a linked method ``get_unusual_days``
that should be defined on the related model to return all the
concerned days for a given period.
*: hr_timesheet
project_timesheet_holidays
account
Creation of analytic lines will be done in batches instead of creating single
record by iteration. This optimization is done in order to speed up the creation.
task-1971460
closesodoo/odoo#34481
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
* the employees file apparently never worked as the marital status was
updated before template files were added (respectively
0eb58775c9 and
b60de0db41)
* the purchase template was never updated to reflect the Big Demo Data Changes
(58fc4e4409).
Fixes#39074
Employees file update split off of task 2059779.
closesodoo/odoo#39823
X-original-commit: 80a2f6877378a87638c04061ceaf69965c1707c0
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Co-authored-by: Prakash Prajapati <ppr@odoo.com>
Someone new to Linux can run into problems when some system dependencies
are missing. There is a single sentence warning talking about those hard
dependencies and it does not explain how to install them.
Added two § containing the missing `apt` commands required to install
the dependencies on a fresh debian minimal install.
closesodoo/odoo#39774
X-original-commit: f7d0022f11d63777eb88bb5f808be3c5ced88fd6
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
To prevent having holes between statements and for better usability using import and synchronization
we try to automatically set the starting and ending balance based on the previous existing
statement.
To do that, we added a new field previous_statement_id so that whenever we change the ending_balance
of the previous statement, we recompute the starting balance and ending balance of the current statement.
Also creating a new statement in between 2 others statements will automatically set the correct value
to the starting and ending balance of that statement and all the statements afterwards.
Exception: creating a statement by hand won't automatically set the balance_end_real, however if you
create one between 2 statements, the balance_end_real of next statements will be recomputed
Was Task #1880409closesodoo/odoo#38696
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
odoo/odoo#28519 removed large parts of pycompat, but left reraise
despite that not having much value.
Remove that helper and replace it by just a `raise` in most cases:
when raising from an except block, the old exception is automatically
chained to the new one, no need to mess around.
There is one exception: in http we have to re-raise an existing
exception explicitly (aka `raise exc` rather than just `raise).
This is less than ideal as Python *concatenates* stacks: the
previously reified stack (from the except clause) is stacked on top of
the new stack (from this raises), this leads to tracebacks "jumping
around" at the break point of the handler and is somewhat confusing.
So we want to use explicit chaining (`raise a from b`) with the
"source" providing the caught exception's original traceback and the
child providing the rest.
However since callers rely on the exception making sense, we need the
re-raised exception to be the original[0]. Copying the exception
doesn't work (see [0]), chaining an exception to itself doesn't
do anything useful, and while we could probably copy exceptions using
the pickle method[1] that's still risky.
So the most reliable option seems to be to create a new "cause"
exception, move the old traceback over to it, then re-raise the
original exception having cleared its traceback, chained to new the
cause.
[0] or a copy thereof but Odoo exceptions don't all work properly with
copy.copy and we don't want that to fail so not really an option,
we can't rely / bet on every new exception being cleanly copy-able
[1] create an "empty" instance using __new__ (or an instance of
something else onto which we re-set the __class__ in case the exctype
actually overrides __new__) then copy the __dict__
closesodoo/odoo#39709
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
The unittest signature of `assertRaises` allows a named parameter
`msg`[1]. The message is displayed in case of assertion failure if
`assertRaises` is used as a context manager (but not when giving it a
callable).
The Odoo implementation did not implement this behavior, despite it
being expected by multiple odoo tests.
Fix Odoo version to be in line with the method we're overriding /
shadowing.
[1] https://docs.python.org/3/library/unittest.html#unittest.TestCase.assertRaisesclosesodoo/odoo#36719
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
- Create an event
- Add a mail reminder for it
- Run the mail scheduler manually
- Duplicate the event
The mail reminder is sent on the duplicate too.
This commit remove the field `mail_sent` from duplicating.
OPW-2117343
closesodoo/odoo#39777
X-original-commit: 7fede2c0360f72410ac36f5d706ac5c7c18b7c7d
Signed-off-by: Jason Van Malder <jasonvanmalder@users.noreply.github.com>
The 'delivered quantity' field sometime needs to trigger a search
on related objects (e.g. analytic lines) to know how much has been
delivered.
For performance reasons, this search is done using a read_group where
the results are grouped by SO line.
Unfortunately, this computation is sometimes launched during
recomputes/onchanges where the line in question has a NewId instead
of a regular id.
This means that the mapping will return something like
{240: 50.0}
indicating that (e.g.) there are 50 timesheet hours for the SO line
with id 240; unfortunately by doing
mapping.get(line.id, 0.0)
the NewId (240) is used - therefore returning a delivered quantity
of 0.0 for a line which has actual timesheets.
This commit ensures that if the line has a NewId and an original
underlying record, the id of the latter is used as the key to fetch
the value from the dict that contains the read_group result.
Note that the problem was quite tricky to reproduce as it depended
on the order of operations launched by triggers - the order of
operations was important since triggering the compute with the 'real'
record put things in order before any other piece of code could have
spotted the issue.
closesodoo/odoo#39781
X-original-commit: cf54606edb9130f2c5b351150f0e37b75f10ae66
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Business cases should not prevent the unlink of module-related records
during an uninstall.
This commit allows the reinstallation of sale_stock with demo data and
also allows the proper removal of tables and records if a db has any
non-draft inventory adjustments.
closesodoo/odoo#39776
X-original-commit: cedafe00941b869d284cd511633d7da15868fc0a
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
The extra informations not on the sale.order models were sent before
13.0 with the superuser user. In 13.0 with the change of `sudo` and
`with_user` behavior, we were now in superuser mode but not with the
superuser so the mail would error (no from address) and the sale order
would error.
With this changeset, we get back to the pre-13 behavior.
opw-2116346
closes#39730closesodoo/odoo#39748
X-original-commit: 7b1654a10f5a005677492ec71e6fa1e54df09ae2
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Before 13.0 .sudo() before sending a mail would send it as superuser user
(which was the intention in this case), but since 13.0 for the same
intention we need .with_user(SUPERUSER_ID).
Without this change, the confirmation email on a sale order would have
no sender ending up in failure.
opw-2118612
closes#39737closesodoo/odoo#39752
X-original-commit: 6aebb5231c3ed0b87cdddcd9cb463952e346ec07
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Before this rev, it crashed when opening the (sale or purchase)
product matrix (e.g. on runbot, go to quotations, create, add a
line, select 'My Company tshirt').
This was due to a recent override of _applyChanges (see 4bf98b47),
which didn't return the value returned by super.
OPW 2116083
closesodoo/odoo#39747
X-original-commit: 49626acbacb87a6f5d37bea22d0b51a506121914
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Purpose of the commit is if sales order is very long, the down payment
gets lost in the middle of it and will be best to make it appear
systematically at the end of it.
currently the sales order line is order by the sequence and while
creating the down payment it takes the default sequence of the line
so adding sequence by +1 will show the down payment at the end.
task-2025709
closes odoo/odoo#34404
Closes: #34404
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
In the contacts app, you can select 2 partners and merge them.
Before this commit:
- If a partner was added by a SQL query and not directly on Odoo,
the create_date will be empty. This causes a crash because the
merge wizard try to sort the partners by date
After this commit:
- If a partner do not have a create_date, it will be considered
as 01/01/1970. The merge wizard will sort the partners by IDs too.
OPW-2091925
closesodoo/odoo#39523
X-original-commit: deeb769c0d579c51ab42b072ccc1c013d79fcea4
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Prior to this commit: b234e97f87,
uninvoiced orders' state is set to 'done' when the session is validated.
However, this was not taken into consideration in the said commit such
that even if the session is already validated, the uninvoiced orders'
state remains 'paid'.
Setting the orders state to 'done' is the correct behavior and is
implemented in this commit.
closesodoo/odoo#39735
X-original-commit: bb490301c22c84c86d2b1c2d27ecb96a4ff19ac5
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
odoo/odoo#30688 (6ce2d6efb5) added an
indirection in prefork workers: Python-level signal handlers are
delayed until native calls have ended (e.g. accept() or
execute()). Running the actual work in a sub-thread allowed the main
thread to handle signals in all cases.
However there is apparently an issue with SIGXCPU on linux (possibly
other cases as well): SIGXCPU is delivered to the child thread (if
possible?) and Thread.join apparently stops it from redelivered to
the main thread (Thread.join is signal-interruptible since 3.2 but
possibly not Python-interruptible).
Blocking SIGXCPU on the child thread causes the OS to deliver on the
main thread and fixes the issue.
Also split set_limits so it sets the signal handler in the parent
thread but properly updates the soft limit in the child after each
request, as the goal is to put a hard limit on the CPU time per
request, not on the worker. 6ce2d6ef would set the limit once then
never update it, likely cycling workers more than desired.
While at it:
* block other signals with a handler set, they seem to work
regardless on linux but other OS may have a different way of
dispatching process-directed signals
* unset signals which are set by the prefork server but whose
set behavior makes no sense in workers:
- TERM and CHLD were already unset
- HUP is used to restart the server, workers can just be killed
- TTIN and TTOU configure the number of workers
closesodoo/odoo#39731
X-original-commit: 549bd199bad269e4e28efac933efac3f41495877
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Make an invoice in Foreign
Make a refund in Foreign
reconcile the two, partially
Make a payment in domestic, partial also, but with writeoff
Before this commit,
The invoice was not fully reconciled and -0.02 was yet to pay on it
Notice the negativity of that number, which actually means that it HAS been
fully reconciled !!!! (there is too much payment compared to invoiced)
This was because, the account.payment in domestic currency is doing:
Invoice residual in foreign, converted to domestic
Then that amount minus payment's amount gives write off amount in domestic
Then, at reconciliation, the whole payment's amount, which is
the payment + the writeoff contained the expected and mathematically
correct conversion and currency rounding errors
(which should make out the exchange difference)
The exchange difference IS created, and rightfully too
that is, it records the exchange difference as debit 0.01 in the receivable !
What was tricky though, is that the partial line recorded the debit 0.01 receivable
as its CREDIT move line !
After this commit, the receivable line is recorded as the DEBIT move line of
the partial between the payment and the invoice
so the invoice, is fully paid.
We keenly admit this is hackish, but justified:
- business-wise: the rounding/exchange errors are appearing ex-post
to the choice of the amount of the reconciliation between the payment
and the invoice, because we are reconciling them on the domestic amount
- technically: our hands are tied because some key information is not present
every time, and weirdly, not symmetrically. That is, the computation of
line.amount_residual[currency] may be different if your are on a line with a currency,
or on a line that doesn't.
We should really think of systematically putting the currency on the line
whichever it is ! The same goes for partial reconciliation model !
Touching the current behavior is out of the question.
Moreover, we should take into account that comparing amounts at different
points in time should be done by actualizing those amounts to a common date
See #39117 for details
OPW 2057845
X-original-commit: 40db7a8
Note that the tests did not change in spirit, but the writing
of the exchange difference may vary from happened in v11.0
Indeed a quite big refactoring has been done in between
The tests reflect this
closesodoo/odoo#39727
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Usecase to reproduce:
- Set warehouse as 3 steps delivery
- On pack rule set the procure method as 'take from stock if enough or
trigger another rule'
- Do an inventory adjustement of a product and set 10 units in pack zone
- Do a delivery order for this product with only 1 unit.
It will create the delivery order from stock to pack even if the
quantity in pack was sufficient.
It's due to [1] that introduce a new function but if the force company
and location (with an integer) are both set in the domain it will
select the wrong ids. It will take all the location in the company + the
location in the context. However if a location is explicitly given to
the context, it should only consider the stock at this location.
[1] commit 330b99f60c
opw-2090384
closesodoo/odoo#39726
X-original-commit: e77d9fc735d845bbb0b5562c359fbf2354d72f0e
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
before this commit, when try to make payment with
empty card details, it will raise error dialog.
after this commit, error will be append to acquirer
form
task - 2089999
closesodoo/odoo#39729
X-original-commit: 01b143b971a85d6da673df6c536917ad4754b83a
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Steps to reproduce the bug:
- Let's consider Today = 31/10/2019
- Create a new hr.leave.type LT and set a validity from 01/01/2020 to 31/12/2020
- Set mode = Free Allocation Request and Validation = No Validation
- Try to create leave allocations for LT
Bug:
It was impossible to create a leave allocation for LT because Today < 01/01/2020
So it was impossible to allocate future leave.
We had to wait the 01/01/2020 to make the allocation of LT leaves
So now, when no default_date_from is in the context, no domain is applied
opw:2092830
closesodoo/odoo#39715
X-original-commit: 6bc9e6920c23262e13398b1b88ea7cfd3b4f1e7d
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Steps to reproduce the bug:
- Let's consider two storable products P1 and P2
- Update the cost of P2 to 10€
- Create a BOM for P1 with P2 as component
- Click on Bom Structure & Cost
- Click on P2
- Try to update the cost
Bug:
A traceback was raised saying that "Record does not exist or has been deleted" or the cost of an other
product was displayed because the active_id was still the id of the bom.
opw:2093199
closesodoo/odoo#39710
X-original-commit: e984d8f94534373fde894e9e6ad0c932585deb46
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
`is_false` relies on no small part on equality tests between the input
triplets and either `TRUE_LEAF` or `FALSE_LEAF`. While these are
defined as tuples, RPC domains will always be lists (as neither
XML-RPC nor JSON have tuples, and their arrays deserialize to Python
lists).
This is an issue, because tuple and list never compare equal. As a
result, while the in / not in predicates can succeed, the TRUE_LEAF /
FALSE_LEAF never will, and thus domains which contain either and might
shortcut (avoid a query entirely) will always go through the entire
process.
Fix by having domain normalization also ensure all triplets are
tuples: that's the first thing `is_false` does, it should never cause
issues and could fix / improve / shortcut other routines.
Note: Also implements TRUE_LEAF and FALSE_LEAF handling in the
SSF's modifiers evaluator. And fixes the ValueError to work
correctly if it breaks on a tuple / dict.
closesodoo/odoo#39706
X-original-commit: a44f008b918ee66742f7e943b00e4ee3d7fe2b78
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Activate Google Synchronization, create on GC a recurrent event,
synchronize OE, then delete an event of the recursion on GC, sync again
on OE.
The event will be deleted from GC but not from OE after sync.
The exclusion on OE is not correctly working in that particular case,
fixing require also to "suppress" the attendee to avoid that just
created exclusions would be detected as changes to send in a following
synchronization.
closesodoo/odoo#37884closesodoo/odoo#39510
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Yannick Tivisse