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>
Yannick Tivisse