This commit changes the way timesheet are invoiced.
An invoiced timesheet is a timesheet line linked to a invoiced
(timesheet_invoice_id set). This happens when the sale order line
linked to several timesheets is invoiced, but only for the line
based on 'delivered quantity' policy. Those timesheets will be linked
to the new created invoice.
Those timesheets can not be changed as they are considered as invoiced
to the customer: quantity, project, SO line, ... are freezed.
Those timesheets are now marked as invoiced at the invoice creation,
and not at the invoice validation, like before. This only concerned
Customer Invoice (and not Vendor Bills, Credit Note, ....).
For timesheets linked to a SO line based on 'ordered quantity', they can
be modified as their purpose is only to track the time spend on the SO
line, and it does not impact the amount or the quantities invoiced to
the customer.
The timesheet linked to milestone sale line can be modified too, they
are now linked to invoiced, as their is goal purely time tracking (as
the delivered quantity is manually change on SO line).
This commit also adapt the tests accordingly.
Task #1857652
The timesheet revenue is a field introduces for 11.0, as a field
computed on the fly (not a computed one). Its goal was to estimate
the theorical (and effective) revenue (amuont of money received when
selling the timesheet), depending of the invoice policy, the quantity
really invoiced, ...
Its computation is quite complex, and is not working perfectly as it
is difficult to determine how much is already invoiced in case of
selling time in ordered quantity.
Also, this field is not used anymore in the project overview, removing
it will reduce code size and complexity. Soon, the amount to invoice and
invoiced coming from the SO lines replaced the timesheet revenue.
This commit removes the field, and its related tests.
Task #1857652
As we plan to remove the timesheet_revenue field, we can
make 'timesheet_invoice_type' a computed field, to simplify
code and readability.
Before, this field was readonly, and set automatically on
timesheet creation.
To allow searching on it, we keep it stored.
Task #1857652
Before this commit, a subtask was forced to have the same SO line
than its mother.
We now want to make it updatable: the default value will be the one
from its mother, but the user can change it manually and set it to
whatever he want (it still should be a service SO line, belonging to
the same customer than the task).
Task #1857652
Since the 2 fields 'untaxed_amount_to_invoice' and
'untaxed_amount_invoiced' are reintroced
we can now use them in sale report, and in profitability report when
selling time. They will
be used in the project overview, solving the wrong amount in that view.
Task #1857652
Similar fields were introduced at d2e33ba57c
but their computation were not totally exact, so someone removed them.
Also, for performance sake, they were replaced by a (too) simpler
calculation at 39d0613187d36f16c541734e80925e9d.
Turns out, those fields were usefull !
Neither of those 2 implementations were 100% correct, so this commit
reintroduced thoses 2 fields on sale.order.line object:
1/ untaxed_amount_invoiced: will contain the amount (money without
taxes) invoiced
from the sale line, taking refund linked to the same SO line into
account. The formula is
SUM(inv_line.price_subtotal) - SUM(ref_line.price_subtotal)
where
`inv_line` is a customer invoice line linked to the SO line
`ref_line` is a customer credit note (refund) line linked to the SO
line
2/ untaxed_amount_to_invoice: will contain the amount (taxes excluded)
of the money to invoice from this sale line. The formula is
SOL.total - SOL.untaxed_amount_invoiced
Those numbers are interesting in reporting, and to manage the billing
part for salespersons.
Task #1857652
When making a refund, a list of field is read during the
process. This field list comes from the
method, which return some field that does not exist anymore.
Reading non-existing fields creates warning in logs
In _sanitizeValue we can receive field as a string of the form
fieldName:grouping, if we search for this directly in the fields of the
model we won't find anything.
Hence we should use the fieldName part of it.
As soon as a website menu contained a sub-menu, the whole website layout
was broken as we put <li/> elements inside a <div/> element (this
occured by mistake with BS4 migration).
In BS3, the combination "text-danger" and "bg-danger" worked as the red
color for texts was not the same as the red color for backgrounds. With
BS4, they are the same so it does not make sense.
Fortunately, we introduced a mixin customization which automatically
selects the correct color according to the background. So removing the
"text-danger" part is enough to make sure the text will be visible over
"bg-danger" background.
* website_slides
The app was still using an old BS3 variables that happened to be created
by the website_slides app (that is why the bug was not noticable
on runbot).
In enterprise version, the select elements have a custom style. For it
to work, the "appearance" CSS property must be understood... which is
not the case in most browser without vendor prefixes.
As discussed in https://github.com/odoo/odoo/commit/770aec399c4e6e29cfc5854318cbda19a605315d,
vendor prefixes are added by post-processing the scss generation.
This commit allows the user to link some mail template to activity type
with res_model.
When a activity has template, buttons appears in activity, allowing the user
to send mail based on templates.
Task: #1844563
PR: #25620
Before this commit, the function that computes the aged partner balance
could return a list instead of a dict if no partner were found
After this commit, we make the function's signature consistent
closes#26095
This commit updates the demo data in order to have a beautiful dashboard
when using the standard demo data.
It also enables us to display false in a graph view when using a boolean
measure, previously this was considered an empty value, as many2one
fields use false to indicate that they are empty hence we were
displaying undefined instead of false.
Task #1844742Closes#25944
In the graph view, by default the value false was considered to be a non
set value (which is the case when dealing with M2O fields). But in the
case of boolean fields, we want to display the value false.
Before this commit, saving a file being watched by watchdog
(--dev=reload) with vim (and possibly other text editors) would
crash the server via a KeyboardInterrupt error.
This happens because vim, emacs cause multiple filesystem events to
happen when saving a single file, the FSWatcher registers these events
as multiple SIGHUPs which in turn calls restart() multiple times in a
very small amount of time which makes the KeyboardInterrupts completely
shut down the server
This is fixed by only calling restart() if odoo.phoenix is False, since
catching a SIGHUP sets it to true.
Fixes#21178
Special thanks to @odony for the help :)
This field is used by the multiple payment wizard; the payments it generates are always individual and should never have multi=True. Before this commit, they did, because of the values given in context when calling the payment wizard.
When archiving records through the generic toggle_active methods we now
remove ongoing activities.
Purpose of this commit is to avoid having ongoing activities in the systray
linked to archived records. As archiving records means we won't work on
them anymore it makes no sense to keep related activities.
Purpose of this commit is to speedup tracking values creation by manually
creating them using the newly-introduced multi create. As tracking values
creation is already done manually as sudo when creating mail message we
just update the code to directly insert them as multi.
This commit is linked to task ID 1870656 and PR #26068. No functional change
should occur with this commit.
Commit 896e36edab added support of multi insertions when creating new
records. This had a great impact on mail-related tests involving several
followers update. This commit updates the counters to match the current
runbot state on master.
This commit is linked to task ID 1870656 and PR #26068. No functional change
should occur with this commit.
jem-odoo