Before this commit, the user had to go over each expenses to
register a payment.
He now has the possibility to do so from the expense report
tree view via the "register payment" button.
task-id: 3116195
[community](https://github.com/odoo/odoo/pull/109671)
closesodoo/odoo#109671
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
RATIONALE
Purpose of this commit is to cleanup main post helpers and have a more easy
and understandable way of calling them.
SUMMARY
We now have two main API methods, based on business flow: either posting
on documents, either sending a mass mailing. Indeed those two flows are
different
* post: create message, then launch notification process by taking into
account subtype, followers, ...
* mail: create mails in batch with recipients being based on template or
given partners. No notifications is involved, only maybe traces if a
mass mailing is linked
Delegate QWeb rendering to the render mixin (i.e. _render_template_qweb_view)
in order to have a single point to forge evaluation context and re-use
existing rendering code.
SPECIFICATIONS
Main API helpers are now
* ``message_post_with_source``: (batch) post on records, using an ir.ui.view
(given a record or its xml id) or a mail.template record (given a record or
its xml id). When using a template, a composer is called to post on each
record (as batch post is not yet supported). When using a view, a direct
call to message_post using the rendered bodies is done, one record at a
time.
* ``message_mail_with_source``: send a mass mailing on records, acting like
invoking the mail composer in mass mode. Same arguments are valid, either
a reference to a view, either a reference to a mail template.
Other helpers are
* ``_message_log_with_view``: (batch) log on records, using an ir.ui.view
to render the body using QWeb (no notification process);
* ``_message_log(_batch)``: (batch) log on records (no notification process);
* ``message_notify``: notify partners on records (creating notifications
specifically for some people while message itself is not displayed in
chatter);
Code migration
* ``message_post_with_template`` in "mass mode": use ``message_mail_with_source``
and set the template record as source;
* ``message_post_with_template`` in "comment" mode: use ``message_post_with_source``
and set the template record as source;
* ``message_post_with_view``: its main usage was to post on a document, in which
case it generally can be replaced by ``message_mail_with_source`` using
the view reference as source;
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
RATIONALE
Purpose of this commit is to be explicit in subtype chosen when invoking the
message composer / calling message_post. As default value may not always be
clear, better be explicit in case the composer default value changes.
SPECIFICATIONS
Add explicit references to subtype when it is not obvious what will be the
final subtype, notably when using helpers (post_with_view or template which
uses the composer that is not crystal clear in its subtype management).
In this commit we also add support of XMLID-based subtype when invoking the
composer. A ``default_subtype_xmlid`` context key is transformed into a
``default_subtype_id``, to be used notably in JS where we cannot easily
use a ``ref``-like statement. Post API now also supports 'subytpe_xmlid'
argument allowing to give the xml id and ease calling the methods.
Use ``_xmlid_to_res_id`` to get directly the ID of subtypes in order to
avoid useless queries from ``ref`` that does an exists.
Also remove useless values given to post API, notably author_id that is by
default the current users' partner.
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
Steps to reproduce:
- Install Expense module
- Activate analytic accounting in settings
- Create an analytic account X
- Create an expense with X as analytic
- Delete the analytic account X
- Go back to the expense created
Issue:
Cannot access the expense (error message).
Cause:
The analytic account is deleted but the analytics (Json field) on the
expense are not updated.
Solution:
When deleting an analytic account,
if used in an expense raise an error.
opw-3059908
closesodoo/odoo#109012
X-original-commit: 6c058e62812605f511220ec6cde06ebe77ae7edd
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
Expenses paid by company are marked as paid but the related journal
entry is not paid and cannot be paid
Steps to reproduce:
1. Install Expenses and Accounting
2. Create an expense payable to company and set an amount
3. Create report
4. Submit report
5. Approve report
6. Post journal entries
7. Open the related journal entry
8. Attempt to register payment: an error is raised
Solution:
Mark the journal entries created for the expense as paid if the expense
is paid by the company
opw-3075818
closesodoo/odoo#109375
X-original-commit: f5dd4e3326a17c1f6d06630503d1ede8cc6c59fe
Signed-off-by: William André (wan) <wan@odoo.com>
An `IndexError` traceback that occurs in `hr_expense_predict_product/HrExpense:_onchange_predict_product` was caught by Sentry
This tuple index out of range happens because we are trying to access the first record of a recordset returned by `records.filtered()` without checking that it actually contains records.
since https://github.com/odoo/enterprise/pull/34994
opw-3111577
closesodoo/odoo#108720
Enterprise: https://github.com/odoo/enterprise/pull/35232
X-original-commit: 0a74cc1175377826a0adfb52ac68286b17630894
Related: odoo/enterprise#35245
Signed-off-by: Achraf <abz@odoo.com>
The - Split Expense - feature was introduced in odoo/odoo#90770
In this commit we fix the following bug, related to it:
Steps to reproduce:
- Create expense with tax_ids.
- Click on - Split expense on the expense form. From the first
hr.expense.split line remove the tax_ids. Rename it as '1',
so that it is easier to find it back for checking later on.
- Click on - Expense split on the wizard.
Check the resulting expenses. Specifically, the one with the name '1'.
Current behavior - The tax_ids field for the first expense
(with the name '1') is still populated.
Expected - The tax_ids field for the first expense should be empty.
On top of that, we introduce the tests that check Split Expense flow.
task - 2831024
closesodoo/odoo#108049
X-original-commit: 3aaf4f1ee2967793c9a4c29766cec63d2c6e3cf4
Related: odoo/enterprise#35005
Signed-off-by: Kevin Baptiste <kba@odoo.com>
When filling a Sales Order applicability rule line, the financial
account prefix is useless, as it will not be used.
Thus we can make it invisible in the case of business_domain corresponding to sales and purchases.
task-3040927
closesodoo/odoo#105014
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
* = {account, sale, purchase, hr_expense}
When a plan is mandatory for SOL, POL or expenses, the flow should still be blocked when pressing the button, and not only when creating analytic lines.
We add the info in the context of the button, so automatic flows are still not blocked.
When the applicability rule requires a mandatory analytic distribution, raise an error upon :
- confirming PO,
- sending or confirming SO
- approving Expense Report by manager.
t-3040929
closesodoo/odoo#107166
X-original-commit: 8623a7850288828759db125b1054b0fed6b6b135
Signed-off-by: William André (wan) <wan@odoo.com>
It is not possible to post the journal entries related to an expense
paid by the company
Steps to reproduce:
1. Install Expense
2. Create an expense payable to company
3. Set an amount
4. Create report
5. Submit report
6. Approve report
7. Attempt to post
8. An error is thrown
Solution:
Relax the constraint on account.move.line linked to an expense paid by
the company
Problem:
The constraint `_check_payable_receivable` in the account module forbids
to post the journal entries even though they are correct
opw-3038648
closesodoo/odoo#106266
X-original-commit: 09274db12a25c178974dc20c4d669134e21cddbe
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
Steps to reproduce:
- Install `Expenses` module
- Go to Settings > Technical > Email > Aliases
- Edit the `expense` alias
- Ensure the model is `Expense`
- Set `Alias Contact Security` to `Everyone`, then save
- Send an e-mail to the expense alias, using an e-mail address not
referenced on one of the employees.
Issue:
Error in logs related to `currency` variable.
Cause:
Trying to create an expense for a non-existing user, therefore,
no currency is set.
Solution:
If no user is found, no need to create the expense and let the orm
raise the error that a required field is not set (field employee on
expense).
opw-3027350
closesodoo/odoo#106057
X-original-commit: a339caa2faf8cde0ec1c85079b9d74f31b055f24
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
Purpose of this commit is to cleanup alias usage in hr_expense. Indeed it
is currently used as a master data without being cleanly supported.
In this commit we
* globally avoid crashes if the alias data has been removed;
* recreate Xml ID record if it has been removed as it is considered as
being a master data;
* avoid issues when trying to configure the expense alias in settings if
alias has been manually removed. Setting a name now creates the alias
and an XmlID if it has been removed;
* rename a generic 'use_mail_gateway' field into 'expense_use_mail_gateway'
in order to avoid conflicts with future changes in generic settings linked
to email gateway and configuration
* fix empty list helper: it is now translated and correctly encode parameters
given to 'mailto';
Task-2710804 (Mail: Clean MailThread Posting API)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#105992
During a refactoring [1], the behavior of having the taxes included in
the price for all expenses was broken/removed.
All the fields related to taxes are computed should be computed with the
correct context key when computing entries related to expenses. This is
preferred to adding the context key only when creating because it will
then keep the behavior even when editing the document.
task-3043252
[1]: https://github.com/odoo/odoo/commit/d8d47f9ff8554f4b39487fd2f13c153c7d6f958dclosesodoo/odoo#104746
X-original-commit: 6e944ac5fe108d5f2bc2d3f41ab547efd88a5ede
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
The `analytic_distribution` field is a Json.
It was stored temporarily as a char.
Search is not available yet, so we do queries by hand when we need to search on keys.
Also added a constraint on account_analytic_distribution_model,
so we don't have models with accounts specific to a company when the model has no company or another company.
It would cause an issue when looking at the models from another company.
X-original-commit: 7064c95aa04e5138bb12ae97acfee04ebb67cc0e
Part-of: odoo/odoo#103097
Currently, when posting accounting entries from an expense report, the accounts set on the expense entries were not taken over in the account move lines. Also, the employee was not set as the vendor of the purchase receipt (account move).
This PR makes sure that both the accounts on the expenses, as well as the vendor (employee) is set on the account move created from an expense report.
Tests added as well.
closesodoo/odoo#103037
X-original-commit: 066c70e483b2f49ae48cb98ddc412014f4fe258a
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Add choices for the business domain on applicability rules, so rules are more precise
Also put 'general' as domain from the view when it's what should have been.
Make analytic field visible since owl migration (for sale and purchase)
closesodoo/odoo#102461
X-original-commit: c5867d5009a7fb448fff1be487b9e9c3e7945d4b
Related: odoo/enterprise#32421
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
This PR adapts the form views since the merge of #100570.
task-3002465
closesodoo/odoo#102750
X-original-commit: 03b7ed51d9bb1e0717d21cd6516f98e477a2c926
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Steps:
Create a expense with product having no cost and having the
total amount directly added from expense sheet.
then create an innvoice.
Issue:
While adding journal lines in hr expense the amount per unit
was calculated as the total amount of product such as quantity into the
price per unit inside the invoice.
Cause:
expense's total_amount was passed as price_unit instead of expense's unit_amount
and due to that total amount was multiply by qty so wrong value was passed.
Fix:
If unit_amount of product is non-zero then pass the unit amoun for invoice or
pass the total_amount if unit_amount does not exist.
task-3000758
X-original-commit: d47ca52a2cb8eb7146094e7d172f41f6aa3621a2
Part-of: odoo/odoo#102768
When creating an expense paid by the company, we want the expense
to be on a bank journal. This is currently incompatible with the
current constraint we have that force expense of type 'in_receip'
to be on a purchase journal. Since expense only behave like type
'in_receipt' we can ignore that constraint.
closesodoo/odoo#101307
X-original-commit: f95eb814166646ec3113d35b910a677b21737cd1
Signed-off-by: William André (wan) <wan@odoo.com>
The goal of this commit is to get rid of the analytic tags as they were confusing, serving tag purposes as well as distribution on analytic accounts.
Everywhere analytic tags were used as a distribution have been replaced with a new widget that will dispatch distribution on analytic accounts. If there was an analytic account field next to the tags, it has been included in the distribution.
Analytic tags that were used simply as information tags have been removed.
To fill the new widget, there are now 2 kind of rules that will help fill and prefill it.
The first are applicability: previous groups have been removed, and have by replaced by plans. Each account is required to have a plan. These plans define when they are available in the widget: a default applicability per plan and applicability lines that can specify rules following the context of the widget.
The second one are distribution models, that will replace previous default rules but follow the same principles. The accounts (and so the plans) that will be given by the distribution model can override the applicability rules from before.
closesodoo/odoo#98914
Related: odoo/upgrade#3885
Related: odoo/enterprise#30743
Signed-off-by: William André (wan) <wan@odoo.com>
Co-authored-by: Habib (ayh) <ayh@odoo.com>
The field is related towards the 'manager' field of the expense sheet,
which means that when the approver is suggested automatically based
on hr data, the expense records get written a value for this field
(which is not in the view) which gets logged as:
- None -> Mitchell Admin (Approved By)
which seems to suggest that:
- the expense has been approved (it has not, a report was created)
- Mitchell Admin has approved: it may not be him (as when approving,
the 'manager' field does not log who did the approval but who was
supposed to initially)
Disabling tracking for this field (which contained no actionable
information at best, and incorrect suggestions at worst) makes this
problem go away.
closesodoo/odoo#100241
Signed-off-by: Kevin Baptiste <kba@odoo.com>
The context before click button cancel in expense sheet not cleaned yet.
closesodoo/odoo#100288
X-original-commit: 6f8d3d989cc024c8e5b3e9e1a6b2f4af636721d6
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Revision 26a5653f48 introduced
the possibility to set up a default journal for accounting
entries created by "employee-paid" expenses
This commit adds the same possibility for the "company-paid"
expenses (because why allow it for one and not the other?).
closesodoo/odoo#99993
Signed-off-by: Kevin Baptiste <kba@odoo.com>
In the Employees app, when using the department kanban view and clicking on the
Time Off Requests or Allocation Requests, it leads to a tree view but the department
from which the user comes from is not part of the filters.
This commit adds the department in the filters of the tree view.
Due to the search panel being present in the tree view, the department filter is removed from the list of
filters to avoid a duplication of the filters in the search panel.
task-2939207
closesodoo/odoo#97773
Related: odoo/enterprise#30358
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Major changes:
- converted list view to owl
- merged menus
- added CREATE REPORT button on hr.expense that reports either
ticked draft expenses, or all the draft expenses for the user
- added dynamic buttons on expense.sheet list view
- added searchpanel on expense.sheet for team approvers and above
- moved (and changed) expense categories from demo to data
- added support on drag'n'drop while in list and kanban view of
expense for quick upload
task - 2831036
closesodoo/odoo#93802
Related: odoo/enterprise#28474
Related: odoo/upgrade#3778
Signed-off-by: Kevin Baptiste <kba@odoo.com>
This is an oversight of odoo/odoo#95729
In a database with multi-uom disabled,
when attempting to create an expense choosing a product
with a different unit of measure than the Unit(s)
a ValidationError was raised to the user
regarding an UOM incompatibility
e.g.
- Create an expense
- Set the product "[MIL] Mileage", using the uom "km"
- Save
-> ValidationError about UOMs
This is because the above mentioned PR makes the
`product_uom_id` completely removed from the view,
and the onchange no longer set the uom correctly within the form.
Solve this by setting `precompute=True` on the UOM field,
and the other fields using the same compute method.
In addition to solve the issue, it also allows to create
more easily expenses from the XMLRPC API:
Before, when creating an expense for the product "Mileage",
it was required you set yourself the uom correctly
in your API call,
even if multi UOMs was disabled in your database.
After, it's no longer mandatory to pass the UOM to use,
it is correctly computed from the product directly,
by default.
closesodoo/odoo#98662
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
- A user has accounting permission but no employee permission, when that user register payment in spending it gives an error that does not have access to the bank_account_id field
- This commit allows the user to read the bank_account_id field when register payment
Original PR: odoo/odoo#98432closesodoo/odoo#98485
X-original-commit: 35e07de192dfeba0979170ba8421e4a61c5a483b
Signed-off-by: Kevin Baptiste <kba@odoo.com>
The mistake was made in odoo#81904
Instead of 'default_partner_bank_id' we have 'partner_bank_id' in the
context of action_register_payment.
In this commit, we undo that mistake and also backport the change to v15.
task - 2774594
closesodoo/odoo#97886
X-original-commit: 5c8b74bb3bddd67b5a76d37f7d97a1d5d77c00c4
Signed-off-by: Kevin Baptiste <kba@odoo.com>
TLDR:
* invoices are implemented using computed methods instead of onchange
* the synchronization only happens when switching tabs in the Form view
to improve perfs.
_______________________________________________________________________
The whole engine of the synchronization of Invoices to the Journal
Entries has been refactored
* by using computed fields instead of onchange functions
* by synchronizing only from invoice to journal entry in `create` and
`write`
* by saving when switching tabs on the Invoice form, to synchronize
before showing the values
This comes with numerous advantages:
* no need to call the onchange methods manually
* no need to use the Form emulator to build invoices (i.e. EDI, OCR,
intercompany, ...)
* the performance for invoices with many lines improves drastically, going
from 2 minutes to 4 seconds to create an invoice with 500 lines
* the model is more declarative, we can now see how the values are computed
instead of having the values being copied from various places.
* remove the hack in `onchange` that disabled the recursivity of it,
which was unexpected and needed to be managed manually in all the
onchange methods
This means that:
* Some fields need to be exclusively computed on journal entries values
or invoice values, more specifically the Tax Summary widget.
It is now
- computed from entry lines, when opening the view
- computed from invoice lines when changing those, because the tax lines
will need to be recomputed anyways, erasing previously set values
- set with an inverse function when saving; after the sync has been done
* Some possible operations previously possible have been dropped.
(i.e. look at the removed test test_in_invoice_line_onchange_accounting_fields_1)
This is because such a behavior was undefined (how is changing the balance going
to affect the unit price? How is the amount currency going to affect it?)
_______________________________________________________________________
Implementation Details
----------------------
The "dynamic lines", meaning the payment terms and the tax lines are now
only created in the `create` and `write` functions.
In order to reduce code duplication, it has been implemented using
context managers used in both `account.move` and `account.move.line`
These context managers help comparing the values before/after, acting
like a local `onchange`, but getting benefit from the dirty flags from
the `compute` dependences.
This is relying on computed fields on the move (`needed_terms`) and on
the lines (`compute_all_tax`) which contain the values needed for the
related move.
Depending on the needed values and the existing values (`term_key` and
`tax_key`, respectively) the context manager will determine what needs
to be created/updated/deleted.
Some related changes are to produce a `dict` instead of a `str` for the
`tax_totals` (previously `tax_totals_json`) fields, by simplicity to
reduce the complexity of IO, and simplicity of debugging, because the
logic of the field needed to change (cannot be computed at the same time
anymore since it needed the lines to be synced)
By simplicity, and also because it makes more sense, some boolean fields
have been merged into `display_type`:
* `is_rounding_line`
* `exclude_from_invoice_tab`
* `is_anglo_saxon_line`
The `price_unit`, `quantity` and other "invoice fields" are now not set
anymore on lines that are not product lines since it didn't make any
sense to have it.
Performances
------------
You have to keep in mind that a simple `create` didn't compute a lot of
fields, for instance not taxes were set, no payment terms,...
Now it does.
```python
import random
from timeit import timeit
from odoo import Command
domain = [('company_id', 'in', (False, self.env.company.id))]
products = self.env['product.product'].search(domain).ids
partners = self.env['res.partner'].search(domain).ids
taxes = self.env['account.tax'].search(domain).ids
def create(nmove, nline):
self.env['account.move'].create([
{
'move_type': 'out_invoice',
'partner_id': random.choice(partners),
'invoice_line_ids': [
Command.create({
'name': f'line{i}',
'product_id': random.choice(products),
'tax_ids': [Command.set([random.choice(taxes)])],
})
for i in range(nline)
]
}
for j in range(nmove)
])
# After | Before
print(timeit("create(1, 1)", globals=globals(), number=1)) # 0.11 | 0.09
print(timeit("create(100, 1)", globals=globals(), number=1)) # 2.76 | 2.50
print(timeit("create(500, 1)", globals=globals(), number=1)) # 14.56 | 12.34
print(timeit("create(1, 100)", globals=globals(), number=1)) # 1.03 | 5.52
print(timeit("create(1, 500)", globals=globals(), number=1)) # 3.99 | 125.02
print(timeit("create(50, 50)", globals=globals(), number=1)) # 19.44 | 79.55
```
Another metric that can be used is running the test suite with
`--test-tags=/account` (only `account` installed)
* before: 404s, 267127 queries (366 tests)
* after: 318s, 232125 queries (362 tests)
Why this commit title?
----------------------
Someone told me that this was the perfect way of naming your commits.
c04065abd8
task-2711317
closesodoo/odoo#96134
Related: odoo/upgrade#3715
Related: odoo/enterprise#29758
Signed-off-by: Laurent Smet <las@odoo.com>
This commit aims at removing unuseful help message to:
1/ reduce translators work, to focus on more useful translations
2/ not sending unuseful information in load_views
3/ reduce help message to useful messages, so that we can mark
fields having a tooltip in the future UI.
4/ some cleanup of existing messages too
The main use cases:
- REMOVED: help redundant with the field name, providing no extra info
- MOVED TO COMMENT: technical help messages, that should not be in UX
closesodoo/odoo#97279
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
Scenario:
Open expense, choose product with cost, set quantity to 5, now choose
any 0-cost product. Save the expense.
Behavior: quantity is 5
Expected behavior: quantity should be set to 1
Implications: As a result, in the list view on expenses, we see incorrect quantity.
Moreover, in SO, price_unit will be incorrectly computed.
task - 2867723
closesodoo/odoo#96732
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Task: 2856281
- Remove user_type_id, account.account.type model, internal_type
- Add account_type that is a simple selection field
- Move internal_group and include_initial_balance to account.account
- Because of these changes, type_control_ids on account.journal is also removed
closesodoo/odoo#93212
Related: odoo/documentation#2223
Related: odoo/upgrade#3595
Related: odoo/enterprise#28205
Signed-off-by: Cedric Snauwaert <csn@odoo.com>
In case we change the employee on an expense and in case expense has
sheet which has only one expense_line_ids, then changing the
expense.employee_id triggers changing the sheet.employee_id too.
In case there are more than one expense linked to the report, then we
unlink the expense line from sheet, (so that the user can create a new report).
task - 2890095
closesodoo/odoo#94424
Signed-off-by: Kevin Baptiste <kba@odoo.com>
In expense flow the taxes are calculated as included in price.
Prior, to guarantee it, we had domain - ('price_include', '=', True) on taxes.
That could be inconvenient from user's point of view, as they first needed to
define taxes with price_include = True. That led to users duplicating taxes
between included/excluded just so that they could use taxes in expense.
Now we force taxes to act like price_include = True. This way, user does not
need to define taxes just for expense's purposes and still taxes will be calculated
as it supposed to be - included in price.
task - 2850882
closesodoo/odoo#94392
Signed-off-by: Kevin Baptiste <kba@odoo.com>
The string concatenation would fail on False help_message.
Closes#93036closesodoo/odoo#94505
X-original-commit: 97e066b4cfda8ac34208f84753a40c10524ae989
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Purpose: Before it was hard to view expense attachments from sheet record.
To do so, the user should have gone through clicking on each expense first and
checking attachments, or could have clicked on a attachments smart button on embedded
expense table, which is redirecting to another view that only displays attachments for the one expense only.
Thus, checking all the attachments from sheet was an tedious task.
After this commit, the user can see in the sheet attachment preview all the associated expenses' attachments.
To make it possible, we ovveride 'mail.thread' method that is called to
fetch the data for the chatter. In the override, we fetch extra, associated expenses' attachments.
task - 2320177
closesodoo/odoo#92724
Signed-off-by: Kevin Baptiste <kba@odoo.com>
In case hr_expense_extract is not installed and we click
'Attach Receipt' on hr_expense form view, we get a traceback.
task - 2870500
closesodoo/odoo#92761
X-original-commit: 8593decb2fe6820cfc6f043cb3458f43dd635c87
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Purpose: Sometimes, taxes are distinct on parts of the expense
(for example alcohol and food).
Therefore the expense should be split in two.
In order to split the expense, we added an wizard.
When creating a new expense from the split, we also
copy the attachments.
'hr.expense.split' has to have the similar logic and dependencies between
the fields as 'hr.expense' does. For example, in case we change the
product_id to the product that has cost defined on it, it should have
the same behavior as expense has. In particular, the 'total_price'
will be set and the user should not be able to modify the amount.
Similarly, if we change the product_id to the one that has no tax defined
on it, then split tax_ids should be cleared out and be set to readonly.
Similar logic goes to sale_order_id (Customer to Reinvoice'),
we should not be able to set it, in case the product can not be re-invoiced.
All of the above constraints leads to the amount of similar code to to the 'hr.expense.split' side.
But it could not have been avoided, if we want the smooth flow.
task - 2831024
closesodoo/odoo#90770
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Steps:
- Go to Expenses
- Reporting/Expenses Analysis
- List View
- Remove every records
- The no content help text is broken
To fix this we have to Markup the second part of the noContentHelp
opw-2862056
closesodoo/odoo#92532
X-original-commit: e2d20c97f2a9da0d2f357f1caa08c0e9632c1bcd
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Achraf <abz@odoo.com>
There were inconsistencies in the calls to `_render`.
* the view context could contain information that misled developers.
Indeed, the context and value of the view are not supposed to be found
in the rendering. Thus by calling `ir.qweb` with the name of the
template, we ensure that there is no unwanted information and in
addition the cache key is that of the name of the template which saves
a query.
* the context used for rendering was modified by a method on
`ir.ui.view`, except this is not information used by this model. There
is now a `_prepare_environment` method residing on `ir.qweb`. This
method allows to modify the value dictionary as well as the context in
which the rendering will be done. This preparation of the data as well
as my security check is done only once per rendering. This also saves
some queries
* Freeze options for rendering were inconsistent. It could be that
options on which rendering depends were not part of the cache key. Thus,
depending on the user who generated the generation of the rendering
function, there was or was not information in the template. For example
for automatic branding. This is no longer possible, because it is the
context that is used. The options serving as a cache key are only
recorded for information (for the profiling system for example). A
simplification of the `ir.qweb.field` models could be made.
The report rendering and call `ir.qweb` instead of `ir.ui.view`.
Part-of: odoo/odoo#85110
This commit modifies most of the usages of read_group and uses
_read_group instead. _read_group doesn't join automatically on the
many2one fields when no order_by is specified, making it more performant
when the "name" of the many2one is not relevant, which is the case for
most back-end cases
closesodoo/odoo#84908
Task-id: 2479334
Related: odoo/enterprise#24877
Signed-off-by: Raphael Collet <rco@odoo.com>
1) Now report manager (user_id) (with Team Approver rights) can't see the report.
Here we grant him the same rights as the manager (on employee app)
of the employee will have. Moreover, he can approve the report as well.
2) Purpose: accountant, manager, should be able to edit expense_line_ids
for expense report not only in draft, but also for submitted and approved states.
On the other hand, employee can only edit his expense report only in draft state.
task - 2768700
closesodoo/odoo#84978
Related: odoo/upgrade#3274
Related: odoo/enterprise#24579
Signed-off-by: Kevin Baptiste <kba@odoo.com>
When we are setting currency_id, if we delete it altogether,
we get a traceback.
Task - 2704297
closesodoo/odoo#84741
X-original-commit: 870577981e02fce4a3b1b1df200d2a81c814f5e8
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Miquel Raïch