This commit introduces "Sub-task", a concept remotely similar to
the "delegated tasks" available in version 7.0, but covering a
more specific and narrow scope.
Activating Sub-tasks
--------------------
Sub-tasks are made available within any project by configuring
a "sub-task project" in the project settings. This feature is
considered low-level and technical, and only accessible with
"Technical Features" enabled.
The "sub-task project" may be the project itself.
Using Sub-tasks
---------------
Conceptually, a sub-task represents the allocation of a part
of the scope of its parent task. Multiple sub-task levels
are possible.
Once activated in project settings, a new "Sub-tasks" smart button
will appear on the task form, giving the option to view and
create sub-tasks. In addition, a new field "Sub-tasks Hours" will
appear next to the other computed "Hours" fields, representing
the total hours allocated to sub-tasks.
(Technically, the sum of the maximum between the planned hours
and spent hours of all sub-tasks, with spent hours always used
when a task is closed)
These sub-task hours will be dynamically subtracted from the
remaining hours of the task, and will therefore affect the
task's progress as well.
Upon creation, a sub-task will inherit the link to the
original sales order and procurement from its parent task, and
will by default be assigned to the "sub-task project" set on
the project of the parent task.
Enhancement
-----------
The kanban view for tasks will now display a color-coded label
with the number of remaining hours, whenever the percentage
of remaining hours is below 20% (orange=20%-, red=1%-).
Notes
-----------
This is a forward port of 43c42b304d
Since hr_timesheet has been migrated to the new API, the forward port changes mostly consists in migrating the sub-tasks system to the new API as well.
When the user chooses as product image a file which is not an image, the
message "Could not display the selected image" is displayed. However, at
saving, a traceback is thrown since the file chosen is uploaded anyway.
If the image cannot be displayed, the image field is cleared.
opw-672206
When the user chooses as product image a file which is not an image, the
message "Could not display the selected image" is displayed. However, at
saving, a traceback is thrown since the file chosen is uploaded anyway.
If the image cannot be displayed, the image field is cleared.
opw-672206
When a CRM activity is defined, the subscription is activated by default
for any user. There is no way to change it since the field is not in
the form view. Therefore, a customer is automatically subscribed to any
internal activity, and the user must manually remove the subscription
afterwards.
The `default` field is displayed in the forw view, so this default
behavior can now be configured for a given activity.
opw-672453
This revision is related to 99d8cd6
Avoid to check the journal centralization
mutliple times, for each move lines.
Checking the journal centralization
for each journal for each period just
before the call to `super` is enough.
Before this revision,
if a large number of move lines
was passed in the `ids` parameter
of the `write` method, with all
the same journal / period, this
could lead to huge performances issues,
the `_check_moves` being called
a large number of times for the same
journal and period couple, uselessly.
opw-672797
Revision 15f27b2 introduced a dynamic form submission to
avoid some payment transaction problems.
It so happens that form submission in jquery necessitates
said form to actually be in the dom (at least for Firefox
and some version of MSIE); this revision ensures that the
form is updated in the dom by the rpc call then properly
submitted.
In 8.0, when paying by wire tranfer, the confirmation page
contained the detailed payment information.
This behaviour was lost in 9, this revision reintroduces it.
1/ An empty notebook was created in analytic and filled in account_budget
That way, we had a horizontal line while the module wasn't installed yet
2/ The fields use_task and use_issue displayed on the account.analytic.account
are just redundant information. The probable use case is to go on the project
select the issues management on it, and it will be activated on the related
analytic account. I don't think that anybody will come on the analytic account
to activate the issues. So we hide them in group_no_one
3/ On the analytic account form view, display the title label only in edit mode
Currently there is a selection field 'account_type' on the
account.analytic.account model with 2 values : Active or Archived
Let's use an active field instead and add a Archive stat button on the
form. That way, we can remove all the domain ('account_type','=','normal')
which are implicit with the generic active field behavior
We generate the Mercury invoice number in JavaScript based on the uid
property of the order. That uid is generated by
Order.generate_unique_id() which generates a 12 digit number. A decimal
12 digit number can contain a maximum value of 10^12 - 1 which requires
40 bits to store. The issue is that Integer fields by default are backed
by a PostgreSQL integer type which is only 4 bytes. This means you can
end up with an invoice number you won't be able to store in the
database.
In order to resolve this we will update the field to be a Float field
instead which will result in a PostgreSQL double precision type which
allows values up to 10^308.
opw-671362
When attempting to pay a cart in the ecommerce,
if the customer went on the payment acquirer site
(meaning, the `payment.transaction` is created
in the database), then come back to the checkout form
using the browser back button, and changed his customer
details (address, email, phone,...),
these changes in the details were not applied
in the `payment.transaction` record that was being
re-used.
e.g.
Checkout > Confirm > Choose Paypal, Pay Now
> History back to the checkout and apply changes
in the address > Confirm > Pay Now.
The original issue is the following:
- Go to the journal item creation
- Choose a partner
- Add a line => the partner on the journal item is removed
This is because `partner_id` on the account move is a related to
`partner_id` on the account move lines. This is likely to cause errors
during the manual encoding of a journal item, since the relation will
link the partner of the account move to the partner of the first account
move line only.
opw-670661
1. Add an accounting configuration option
"Assets management & Revenue recognition"
2. Deferred revenue account not set by default in product
- Create new Deferred Revenue Type
- Create new product and assign this "Deferred Revenue Type"
you can see in income account there is nothing set. Actually
when we select revenue type then in income account system
have to set "Deferred Revenue Account" which we set on revenue type.
Otherwise, if we create invoice for this product then system will
by default take the income account from product category.
3. Change word Depreciation to Revenue :
The current test in landed costs puts landed costs on outgoing pickings.
It is a bit weird as they are put on incoming shipments normally. It checks
if the lines of the landed costs have been calculated well, but not if the
amounts/accounts/... on the account move and account move lines have been
calculated correctly. It should also check the entries created when some
part is already out and when we create negative landed costs. (in order to
be able to revert them)
Scenario :
- Two new products without stock as is done in current test in real-time
valuation,...
- Both products are received
- One product goes out (or a part of the quantity)
- A landed cost is created for the incoming picking
- Check that the journal items created, have the correct amounts and that there
is a part that went out and is put on the out account
- Create a negative landed cost as the first landed cost was a little bit too high
- Check again that the journal items created have the correct amounts
[FIX] account: fixed behavior in order to create the exchange rate difference entry at the full reconciliation only.
This is needed in order to support the use case where an invoice in foreign currency is paid on a bank account in company currency,
with the user encoding manually the difference due to the currency fluctuation (writeoff in the bank statement reconciliation interface): before
this patch, Odoo was doing automatically the same, what results in a duplicated currency difference booking). ticket ID: 670876.
A test has also been added in account/tests/test_reconcilication.py (test_statement_euro_invoice_usd_transaction_euro_full) to ensure that use case
is now fixed.
[FIX] account_full_reconcile: a reconciliation is full as soon as either total_debit = total_credit OR if total_amount_currency is 0
[FIX] account: when registering a payment with a writeoff, always create the writeoff line exactly as entered by the user. Before, it was modified
by the exchange rate entry, for some reason...
[FIX] account: on invoices, show the payment widget and outstanding payments in the invoice's currency always
[FIX] account: when assigning a payment in company currency on an invoice in foreign currency, save the amount_currency in order to create the correct
exchange rate.
[FIX] account: show the currency difference entry on the invoice payments widget
[FIX] account: fixed the reconciliation methods in order to work with exchange rate entries that have debit = credit = 0
[FIX] account: fixed reconciled field computation. A line is reconciled only if its amount_residual AND amount_residual_currency are 0
[IMP] display the move name of payments on the invoice payments widget
Thibault Francois