We want to add a dashboard view for sale in enterprise, for this we need
to make changes in the way views are defined on the actions (use
act_window.views) in sale.
We also need to modify the demo data in order to have beutiful display
in demo mode.
Task: #59409Closes#25940
In order to be able to add some enterprise views to sale, we need to
define some act_window.views.
We also make some slight changes in the sale_report for use in
sale_enterprise
Currently, when a digital product is purchased, the list of attachments
is incorrectly computed. Product template's portal files are retrieved
correctly, but all product variant's attachments are taken into account,
not only its portal files.
This commit causes the portal attachments to be computed correctly,
taking into account only portal files from both the product template and
product variant.
Closes#25609
third positional argument is places not msg (which expects a number not a str)
https://docs.python.org/2/library/unittest.html#unittest.TestCase.assertAlmostEqual
fixes errors like these:
if round(abs(second-first), places) == 0:
TypeError: 'str' object cannot be interpreted as an integer
and gives the intended message when assertion is errornous
In Python 3.5, items() on a dictionary return keys in a randomized order.
location_data can thus be processed in different orders, leading to
different quantities in the MO's created by the procurement scheduler.
This fix makes the output of the scheduler deterministic.
(thanks to @odony for his help in troubleshooting this issue)
opw-1865711
Impacted modules: account, hr_timesheet, sale and sale_timesheet
This merge commit contains many small changes in the way we
sell time in odoo.
* amount to invoice/invoiced amount: change the simple formula
used to really takes amount on invoice into account. This reintroduces
the 2 fields on sale.order.line model.
* some usability improvements: styling project overview, better
error and warning messages, ...
* invoicing timesheet: only timesheet linked to sale line with
'delivered qty' product will be linked to the invoiced (and considered
as invoiced) at invoice creation (instead of validation). Those
timesheets can not be modified then.
* Previous change implies to remove timesheet_revenue, which
became useless.
For more details, have a look at subcommit, as they explain
more precisely their feature and purpose.
Thanks to @bst-odoo for his support and functionnal coaching.
Task #1857652
Steps to reproduce:
- activate the EUR currency
- set a currency rate 1 USD = 1.2 EUR
- create a Bank journal in EUR with a EUR account
- create a Vendor Bill in EUR for 1200 EUR in total
- go in the Vendor Bill list view (Accounting > Purchase > Vendor Bills)
- select the created Vendor Bill
- click "Register Payment" in the action menu
- select the EUR Bank journal you created
Bug:
The payment amount is 1000 EUR instead of 1200 EUR.
opw:1870351
This commit add the support of the tooltip for the last
table in plan project. It also provides a cosmetic change
and make the code more extendable as we will need this in
enterprise to add a column to include forecast in remaining
computation.
Task #1857652
In plan project, when there is something to invoice on the SO
the "Create Invoice" button will be displayed, even if the
"to invoice" amount is zero. This can happen when the SO contains
an ordered service line (that does not create project/task). This
line will be in 'to invoice' status, but it is not taken into
account on the plan project since it does not interact with the
project (no created task, no timesheet, ...)
So, to avoid confusion, we hide the button on the project
overview.
Task #1857652
If the project does not allow timesheets, the 'timesheet' tab on task
should be hidden. If the project allows timesheet but its related
analytic account is inactive, the warning message will be displayed
to avoid user to record timesheets.
Task #1857652
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
This commit reverts a configuration update recently done. Tax display
configuration was moved from pos config to general company settings.
This was a mistake and should not stay as it is. Even if saas 11.4 could
be considered as stable this change is necessary and does not impact
anybody as this branch is not released.
Partially revert e434690fe3 .
Since 6a3324a7 and 0c489cf1fa, a translation can not contain a \n
Previous text was not correct rst anyway.
Reexport base translations to include all missing modules
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.
Before this commit, when cliking on "mass mail attendees" on a event form
the default domain on the attendees for determining the mass mailing recipient
was lost in an onchange
After this commit, we retrieve the right domain
OPW 1869308
closes#26081
This reverts commit 4e5f826ce5
for two reasons:
1) A lot of people are working with splitted desktop screen and
will see the view switcher/search as on mobile: it's not efficient.
Only the burger menu should have been visible for the tablets,
not the other mobile features.
2) When you switch between vertical mode and H mode, we don't want
to change the mobile mode because widgets aren't reinstantiated and
some features don't work.
For example, the burger menu is broken if you switch from H mode to
V mode.
Task-1869468
RomainLibert