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