1/ web: adapt formatDate to handle NaN values
DashboardRenderer might return NaN for `Date` or `DateTime` fields if
their original value is null or incorrect.
2/ hr: add job_title in demo data
3/ hr_recruitment: link employee in the chatter for new recruits
4/ hr: remove employee documents in the model
5/ hr_attendance: improve resiliency of relative_time
6/ hr: display manager on res_users
7/ hr: change Address Book to Employee Directory
TaskID: 2009111
closesodoo/odoo#34180
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Multi is the default api for methods, it is not necessary to explicitly
decorate methods with it, adds clutter and most people use it because
they see that the rest of the code uses it.
Done with `find . -type f -name '*.py' | xargs sed -i '/@api.multi/d'`
Purpose
=======
While cleaning the stat buttons across all modules, we
decided to move the (un)archiving from stat button to
actions in the 'Action' dropdown.
Specification
=============
Remove the 'active' stat buttons in all views
For the model 'hr.expense', rename the action menu 'Submit Report' by
'Submit report' and set it only for the list view.
Linked to task 1984526
Related to PR #33720
Since previous commit moved decimal_precision module's feature into base,
use the new syntax for fields declaration
Remove the imports to the removed module
Remove the module from dependency in manifest
sed -i "s|digits=dp.get_precision('\([A-Z a-z]*\)')|digits='\1'|" **.py
sed -i "/from odoo.tools import decimal_precision as dp/d" **py
This commit merges the following models
* account.invoice and account.move
* account.invoice.line and account.move.line
* account.voucher and account.move
* account.voucher.line and account.move.line
It was the opportunity for a big cleanup of the code, so it also restructures the whole account module, its different models/fields, the tests etc. for a better world and a better code readability.
==== Rationale ====
The rationale of this huge change is that we want journal entries / invoices to be easily edited, and changes reflected in the other model. It's a HUGE feature and very strategic for the fiduciary companies. For example, changing the account of a journal entry needs to be automatically reflected on the related invoice.
The same reasoning applies to sale/purchase vouchers.
==== Changes made in features =====
When creating an invoice, you are now creating a journal entry directly.
--> The object account.invoice no longer exists.
In the same fashion when creating an invoice line, you're now adding journal items directly in the journal entry representing the invoice. If this invoice line has some tax, it may create additional journal items as well.
--> The models account.invoice.line & account.invoice.tax no longer exist
Identically, when creating a sale/purchase receipt with its lines, you are now creating a journal entry directly and there's no more usability difference between encoding a receipt or an invoice.
--> The object account.voucher no longer exists.
--> The object account.voucher.line no longer exists.
--> The whole account_voucher module no longer exists.
Positive side-effects coming from these changes are
* draft invoices/bills/sale or purchase receipts now create a draft accounting entry. Validate these objects now simply post its journal entry. That means that draft invoices/bills/sale or purchase receipt can straightforwardly be included in reporting or budgets.
* opening a journal entry in form view will now always open the correct view: if it's a sale/purchase journal entry we will have a customer invoice/vendor bill view or a sale/purchase receipt view, whatever the menu we're coming from.
* code & business logic simplification. It is also condensed in a single place instead of being partially duplicated on invoices, vouchers and journal entries.
There should be no feature loss, except the one allowing to group multiple journal items together based on the same product during the invoice validation.
==== Changes made in models =====
* account.invoice: model removed. Instead, now use account.move with following mapping
field (account.invoice) field (account.move)
----------------------- --------------------
name invoice_payment_ref
number name
reference ref
comment narration
user_id invoice_user_id
amount_ total_company_signed amount_total_signed
residual amount_residual
state state + invoice_payment_state /!\ selection changed
date_invoice invoice_date
date_due invoice_date_due
sent invoice_sent
origin invoice_origin
payment_term_id invoice_payment_term_id
partner_bank_id invoice_partner_bank_id
incoterm_id invoice_incoterm_id
vendor_bill_id invoice_vendor_bill_id
source_email invoice_source_email
vendor_display_name invoice_vendor_display_name
invoice_icon invoice_vendor_icon
cash_rounding_id invoice_cash_rounding_id
sequence_number_next invoice_sequence_number_next
sequence_number_next_prefix invoice_sequence_number_next_prefix
'invoices' subset of account.move can be accessed by using the selection field 'type' or one of the many helpers like is_invoice()
* account.move: now has a valid state 'cancel' that has to be excluded from all business logic
* account.move: field 'amount' renamed into 'amount_total'
* account.move: field 'reverse_entry_id' renamed into 'reversed_entry_id'
* account.move.line: now has a field 'display_type' that has to be excluded from all business logic, in order to support invoice layouting
* account.invoice.line: model removed. Instead, now use account.move.line with following mapping
field (account.invoice.line) field (account.move.line)
---------------------------- -------------------------
invoice_id move_id
uom_id product_uom_id
invoice_line_tax_ids tax_ids
account_analytic_id analytic_account_id
'invoice lines' subset of all account.move.line from a journal entry can be accessed by using the boolean field 'exclude_from_invoice_tab'
* account.invoice.tax: model removed. Instead, now use account.move.line with following mapping
field (account.invoice.tax) field (account.move.line)
--------------------------- -------------------------
invoice_id move_id
account_analytic_id analytic_account_id
amount price_unit
base tax_base_amount
'tax lines' subset of all account.move.line from a journal entry can be accessed by using the relational field 'tax_line_id'
* account.invoice.confirm: model removed. Instead, now use the 'post()' function of account.move
* account.invoice.refund: model removed. Instead, now use account.move.reversal to reverse the entries with the same options as we had for invoices
* account.voucher: model removed. Instead, now use account.move of type in ['out_receipt', 'in_receipt]
* account.voucher.line: model removed. Instead, now use account.move.line
==== Changes made in functions ====
* on account.move, method _run_post_draft_to_post() renamed into _autopost_draft_entries()
* on account.move, method action_account_invoice_payment() renamed into action_invoice_register_payment()
* on account.move, method action_invoice_reconcile_to_check() renamed into action_open_matching_suspense_moves()
* on account.move, method _get_domain_edition_mode_available() renamed into _get_domain_matching_supsense_moves()
* on account.move, method _get_intrastat_country_id() renamed into _get_invoice_intrastat_country_id()
* on account.move.line, method _get_domain_for_edition_mode() renamed into _get_suspense_moves_domain()
* in account.bank.statement, contextual key 'edition_mode' renamed into 'suspense_moves_mode'
Was task 1917430
Add a boolean field in res config settings to install hr_expense_payroll.
Add demo data to allow expense validation easily without having to create
a journal
closesodoo/odoo#32988
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Now that the multi company mode is much more easier to
activate, it is needed to display this information on the
tree views, to help people to know on which company is
set some records in list view.
task-1997637
Closes: #3397closesodoo/odoo#33976
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose
=======
When an Expense report hits the "Approved" stage, the Accountant can no
longer edit the account / tax / analytic account fields. However, this
information can still be modified from the Expense itself, impacting
directly the related Expense report anyway. In any case, it makes sense
for an accountant to be able to edit this type of information, as it is
likely that an employee or a manager will input the wrong accounts.
On the other hand, once the Journal entries are posted, the Expense
report should not be editable anymore.
Specifications
==============
For the Expense report (hr.expense.sheet model):
If the report is in the "Approved" stage AND the user has at
least the Accounting / Accountant access right level
The following fields should be editable
- Taxes (tax_ids)
- Bill reference (reference)
- Account (account_id)
- Analytic account (analytic_account_id)
If the user has a lower access right level => the fields listed above remain
in read only.
If it is in the "Posted" stage (regardless of the access right level of the user):
The following fields should be in read only:
- Taxes (tax_ids)
- Account (account_id)
- Analytic account (analytic_account_id)
The "Bill reference" (reference) field should still be editable (current behavior).
Based on the Expense report's stage and the access right level of the user,
the fields of the related Expenses should also be editable (or not).
closesodoo/odoo#32918
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Select 2 hr.expense then go to action > submit report
Before this commit, the company currency amount of the first expense line of the report
was equal to zero, always
This is because, when evaluating onchanges, a tree is constructed in the order of the model._fields
which is an orderedDict, filled up when the class is the read
So in python and in the Odoo ORM, the order of field declaration does matter
i.e. a @api.depend fields must come *after* the fields it depends on
After this commit, everything computes as expected
OPW 2008868
closesodoo/odoo#34110
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
The old tree views don't really exist anymore, this odd pseudo-flag to
dispatch between "list" and "tree" tree views has no reason to remain.
Task 1937686
closesodoo/odoo#31243
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
As we now have a new debug mode 'tests' which load a new asset bundle
containing tour-test files, we moved those files to a new folder hierarchy.
That will clean the .js files trees.
Also, those files should be included in the new asset.
Basically, the .js tour files (not test) should be inside /static/src/js/tours
while .js tour test files (test=true) should be inside /static/tests/tours next
to QUnit tests, inside a tours folder.
+ test_new_api: don't run the test in debug assets
task-1934445
Comes with https://github.com/odoo/enterprise/pull/4281Closes#33213
Purpose is to make field use more obvious by correctly stating in the
name it should contain an xml id to a qweb layout used for email
notifications. This renaming is propagated through various calls and
addons.
Related to task 1943901
Linked to PR #32404
- Activate multi-company
- Create a company B
- Switch to company B
- Create an allocation request
An access error is raised.
Commit 7f775f0677 added a `sudo` call in order to prevent an access
error. However, it implies that the fallback value `self.env.user`
refers to the SUPERUSER, not the current user anymore. If the current
user is not in the same company than the SUPERUSER, the multi-company
record rules will be triggered.
The fallback is changed to an empty recordset, and selecting the current
user is done out of the method called with `sudo`.
opw-2003137
closesodoo/odoo#33804
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The goal is to be coherent with the user property.
Actually, company_id and company_ids on the environment are no fields.
Calling env.company_id returns a browse record, not an id.
There was no way to inherit properly action_move_create method.
opw:1974069
closesodoo/odoo#33488
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
oe_view_nocontent_smiling_face does not exists in css
when using this classname, the smiling face does not appear
closesodoo/odoo#33519
Signed-off-by: Christophe Simonis <chs@odoo.com>
Consider the following use case:
- Two taxes:
-A: price included, affect base of subsequent taxes, 10%
-B: 15%, regular
- Create an invoice with a line applying A, then B, for 110€. Post it
- The following move lines are generated:
- base: 100€
- tax A: 10€
- tax B: 16.5€
Before this fix, line "tax A" only had the tax tags of tax A. It should also receive the base tags from tax B, in order to affect its grid total correctly in the tax report.
Also, tax_base_amount field used to be computed, but its computation was too simple, and most of the time wrong when doing advanced use of taxes like the one we defined above. It is now not computed anymore, and directly takes its value from the compute_all's result.
closesodoo/odoo#33420
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
When creating or editing an expense report, we have to select the corresponding
expenses. Since it is constrained that these expenses belong to the same
employee as the one from the report, it is not practical to see other
expenses in the dialog when adding them.
This commit extend the domai of the field in the expense report form so
that it doesn't show expenses from other employees.
task #1999537closesodoo/odoo#33932
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
Kevin Baptiste