The goal of this change is to allow the user to stay in the form view and edit
the translations in one go.
Generate also English translations to make the source=English a bit less true.
It was already the case for callable translations method
Adapt the test that was ambigious (verified no French translation was duplicated
but an English translation is created)
Purpose of this merge is to prepare upcoming SMS refactoring by
already pushing some tools, cleaning and tests in master.
Contained in this merge
* improvement of phonenumbers library tools and usage in SMS;
* addition of SMS test classes with tools and mocks;
* addition of SMS tests;
See sub commits for more details. Related to task 1922163.
closesodoo/odoo#34516
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose of this commit is to improve and add tools, methods and data to test
mail and SMS features. We also add tests for current implementation of SMS
feature, allowing to better understand future changes.
[ADD] test_mail_full
* have a module depending on mail sub-applications like sms or snailmail.
Its purpose is to check that standard mail features work effectively with
all overrides and extra behaviors activated;
* add a new model specific for SMS gateway, with default recipient
computation;
* add SMS tests for SMS module adding SMS capabilities linked to mail
feature. This commit tests SMS feature before the upcoming refactoring
and improvement of SMS module in community: posting with SMS and sms
composer usage;
In test_mail
* add necessary mobile information on test partners;
* improve assertBusNotification that was not correctly asserting all items
in message of bus notifications;
In sms
* add mock for SMS sending. Purpose is to mock the connection to IAP
services by mocking the call to IAP server. It allows to perform SMS
tests without having to contact (and pay) for this service;
* allow some customization when calling the SMS gateway mock to simulate
errors and test corner cases;
Related to task 1922163
Linked to PR #34516
Purpose of this commit is to support more formatting options in phone tools,
to provide new API methods for phone numbers validatio. It also introduces
a method on sms.api to send SMS in batch. This one uses a new route given
in IAP services that send a batch of SMS instead of sending them one by one.
Concerning phone validation, tools are updated to correctly handle all
format supported by phonenumbers library. Indeed in addition to national
and international formatting phonenumbers library also supports E164
(international without spaces) and RFC3966 (beautification of phone numbers).
Let us support them and ease the use of our small tool methods in various
addons, notably sms.
Cleaning / check tools methods are added in phone validation module. Various
methods allow to sanitize phone numbers according to a context record and/or
some parameters. Those tools will be used in upcoming sms refactoring.
Another purpose of this commit is to add phone_validation in dependencies
of SMS application. Phone_validation module adds tools to parse and format
phone numbers and allow to replace the manual check done currently. Adding
it in dependencies of SMS does not change anything functionally as
* library is still optional. If phonenumbers library is not installed the
features are skipped without crashing;
* no model is modified as it introduces only tools and a mixin. Models are
updated in crm_phone_validation that updates lead and partner models;
Related to task 1922163
Linked to PR #34516
Co-Authored-By: Thibault Delavallee <tde@odoo.com>
Co-Authored-By: Pierre Rousseau <pro@odoo.com>
Purpose is to prepare future improvements in mail and SMS module. In this
commit we apply some guidelines on XML Ids and file naming.
In mail cancel wizard code is separated from the resend one as they have
nothing in common.
More importantly ``sms.send_sms`` model is renamed to ``sms.composer`` to
avoid underscores (which is really really bad, take a look at
ir.config_parameter) and have a meaningful name.
Related to task 1922163
Linked to PR #34516
Co-Authored-By: Thibault Delavallee <tde@odoo.com>
Co-Authored-By: Pierre Rousseau <pro@odoo.com>
Product "Update Quantity" button can open the "Change Product Quantity"
wizard if all advanced stock options (stock locations, assign owner,
tracking by SN/LN, packaging) are disabled.
Task #2006337closesodoo/odoo#33873
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
On editable list quant view, when user come from a single product (one
specific product variant, or product template with no variants), the
`product_id` field is hidden.
Task #2006337
All of those fields `__get__` and method calls have a cost, it is small but when
done for many records it adds up, so they are better not done.
When creating 1000 products without image, this compute takes:
47ms +/- 1ms before the commit
37ms +/- 1ms after the commit
That's around 20% less.
Part of task-1918881
closesodoo/odoo#34294
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
If `self` contains around 1000 records, this reduces the time of the method by
a factor of 10 when `read` is necessary, and by 200 when using the values from
`vals_list` and no additional query is needed at all.
This speeds up the creation of all models using `mail.thread`.
Part of task-1918881
closesodoo/odoo#34274
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Add comment on both methods to clarify their goal.
Remove the unnecessary check. Indeed the `product.template.attribute.value` is
not displayed during the variant set up of the product template so there is no
point to check the context for it.
Update the view to apply the context change also for the search result. Indeed
the context change on the o2m itself didn't propagate so the attribute was
displayed unnecessarily on the search result.
closesodoo/odoo#34187
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Before this commit, during a module uninstall, module data would be
unlinked in a record-by-record basis, this was done this way for two
elementary reasons:
- To guarantee an unlink order, as some module data being deleted
might only be deleted if some other module data has already been
deleted.
e.g. [a, b, c, a] -> we could batch unlink both `a` in the
list, however the second `a` could depend on the unlink
of either b or c, making the groupby erroneous.
- To create a savepoint before every module data unlink (record), so
that in case it fails, we can simply skip it and proceed with the
uninstall.
After this commit, batch unlink of module data is now possible without
losing the aforementioned key features.
- The first problem is fixed by using `itertools.groupby`, which
will group **adjacent** data of the same type and unlinks them all
in batch while guaranteeing correct unlink order.
e.g. [a, a, a, b, b, c, a, c, c, c] -> this will unlink in
batches of [a, a, a], [b, b], [c], [a], [c, c, c]
- The second problem is fixed by making a savepoint per batch, if
a single element of the batch fails and the recordset contains more
than one element, we split the recordset into two and we repeat the
unlink process recursively until we weed out the undeletable record
Real world example: l10n_mx_edi takes 20min to uninstall because it
contains a lot of master data (~55k records), with this patch the
uninstall takes a measly 20s.
It should generally reduce the uninstallation time for all modules, but
those with lots of master data will see greater benefits in terms of
time.
opw-2025895
closesodoo/odoo#34435
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Before this commit, it was impossible to know which view was the one searched
if there was COW views.
Indeed, since multiwebsite, views might get duplicated from one website to
another. Then, when searching for an ir.ui.view in a form view, every
duplicated view would be listed next to each other with the exact same name
without a way to identify which one comes from which website.
This commit will suffix the view name by its website_id if there is one.
To do so, we use the context key that has been introduced with 62d73253f3.
task-1920052
closesodoo/odoo#33307
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
File `calendar_mismatch.scss` was wrongly in a `css` folder
while it should be in a `scss` folder according to the guidelines.
And set the correct `type="text/scss"` instead of `type="text/css"`
for a .scss file.
closesodoo/odoo#34478
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Commit f17655d introduced a new file (`views/assets.xml`) in
the manifest to load a new scss file. But it also deleted from
the manifest an existing file (`views/hr_contract_templates.xml`)
without moving the content from removed file to the new file.
Hence, style defined in `calendar_mismatch.scss` was never loaded.
Purpose
=======
Since the new company switcher, it's now easier
to manage records of different companies.
Specification
=============
Add a multi company `ir.rule` for `fleet.vehicle`.
closesodoo/odoo#34426
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
If we were using Units of Measure before, the pos order line didn't show what unit we were using. Now we display the Units of Measure in the order line if the option is active.
TASK-ID: 2001995
closesodoo/odoo#33915
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
This makes the media easier to sort than manually manipulating their sequence.
task-2029597
closesodoo/odoo#34440
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
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
Let's assume a one2many field in a form view with a default value
with commands 4 (link to). Before this rev., when saving the record,
the BasicModel generated a command 4 and a command 1 (update) for
each record, with the values of the record (directly coming from DB).
This can cause an issue when the related record can't be edited
(e.g. a posted journal entry in accounting).
closesodoo/odoo#33797
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
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
559bdc976 was merged with an extra line of code to avoid a bug as the fix was
merged in lower version (9efc11c8da) and we could not wait for the forward
port.
Thus, we forced the redirect on `/my` after signup. This code should be removed
for the test to really test the behavior.
closesodoo/odoo#34406
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
In case of selection or many2one field, while saving the page, the field
is re-rendered and loses the applied design changes.
This commit fixes the behavior by re-applying those changes on a newly
rendered field.
task-1961733
closesodoo/enterprise#4657
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
X-port/Cherry-pick of odoo/enterprise@298a9b3a94
Let's consider a product P with a unit price = 100€
When a price list PL with a discount of 20% was applied, and
a coupon program CP with a discount of 10% was also applied,
system still calculated the rate based on unit price of the product
and not on the discounted price.
So in this example, the amount of the CP discount was 10€ instead of
8€ because the CP discount was computed on the unit price 100€
instead of the discounted price 80€ (with 20% discount of PL)
opw:2006829
X-port/Cherry-pick of odoo/enterprise@23739e8a71
Before this task, an event out of date was still registrable for a
customer. Now, an event is registrable only if the end date is not out
of date.
task-1973957
closesodoo/odoo#33389
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Purpose
========
Modernize recruitment app, clean of menu, remove resume and letters feature
to integrate it with documents.
Specification
=============
1) Menus
- Applications
-> By Job Positions (current job position menu
-> All Applications
- Reporting
-> Recruitment Analysis
- Configuration
-> ... does not change
2) Remove resumes and letters menus
3) Add a quick search on `hr.job` to "My Jobs Positions" based
on recruitment responsible = user.
Task id: 1965870
closesodoo/odoo#33862
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
* web, base, website_forum, test_website, account, gamification,
iap, mail, partner_autocomplete, point_of_sale, stock,
website_sale_comparison
All rpc errors are now displayed using the notification system recently
updated for website. For the redirections triggering an error that are
currently displayed as a 500 Error with an ugly white page, the error
page will be similar to 404/403 error but with code 400. All
exception_orm are now handled as a 400 except for the AccessError
which is a 403.
The error card on all the Error pages is now loaded on an open state
displaying clearly the reason of the error without clicking anything.
If there is no error message the error card is not displayed and the
traceback is open. The traceback is only displayed if we are in debug
mode. These changes are also effective for the 500, 404 and 403 error
pages.
KarmaError is now an except_orm exception.
Karma error message now contains the required karma.
All the alerts in website_forum will use the toast notifications
instead of alerts.
A test tour is located in test_website, visit /test_error_view to
trigger some errors manually and look at the result.
task-1894820
closesodoo/odoo#32132
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Previously the Forum errors were handled with a popover, now the
errors will be consistent with the crash_manager and display a toast
notification via the show_warning method.
Also the KarmaError were previously not displaying the karma needed to
perform the action. Now it will display the amount in the error message.
The CrashManager show_warning method will now take an options dictionary
as a second argument to override it's default behaviour.
Part of https://github.com/odoo/odoo/pull/32132
task-1894820
This code was not used properly and was triggering useless rpc.
This code was used in the deprecated badge system and we forgot to
remove it.
Commit where the code should have been removed:
ec212de5c7
Commit where a quick fix was made:
1e1ea00e66
* = gamification, test_website, stock
- KarmaError is now handled as a 400 exception.
- test_website has been updated.
- NO_POSTMORTEM is now clean it was referencing duplicates as most the
exceptions inherit from except_orm.
- serialize_exception from http.py has been moved to ir_http
to take advantage of the odoo inheritance system. We can then
extend ir_http serialize_exception method to add the KarmaError
logic if and only if gamification is installed.
Places where serialize_exception was previously used are updated.
Part of https://github.com/odoo/odoo/pull/32132
task-1894820
The purpose of these tests is to verify that errors informations
are displayed correctly on the website.
Part of https://github.com/odoo/odoo/pull/32132
task-1894820
* website_sale_comparison
Just removing old "in" class from bootstrap3 wich has been replaced by
"show" in bootstrap4.
Part of https://github.com/odoo/odoo/pull/32132
task-1894820
- The traceback is only visible if in debug mode or if edit mode.
- All except_orm exceptions are now displayed as a 400
but the AccessError wich is a 403. There is now a dedicted page
for the 400 error.
- Errors messages are no longer the exception args but its name if the
exception is an except_orm. Else there is no message since the current
logic override exceptions of type Exception in ir_http thus we have
no message to display.
Part of https://github.com/odoo/odoo/pull/32132
task-1894820
* = account, iap, point_of_sale
Removing the CrashManager templates from base.xml and moving
it to a new file (crash_manager.xml) to allow lazy loading the required
xml only when a crash occurs (necessary for the frontend as no xml is
pre-loaded).
All rpc errors/warnings are now displayed using the same modal system as
the backend (crash_manager.js).
CrashManager will now return the WarningDialog and ErrorDialog
in addition to the CrashManager itself.
In some cases an instance of CrashManager was created just to
display a warning/error dialog.
In the backend all rpc errors but sessionExpired will be logged.
If the exception is a warning, NotFound (403) or except_orm, it will be
a warning log. The rest will be exception log.
In the frontend all rpc errors will be logged using console.debug
instead of console.warn and console.error. This way we can trigger
rpc errors in tests without failing them. If a real error happend
during a test it will fall back on the backend logger to fail the test.
Part of https://github.com/odoo/odoo/pull/32132
task-1894820
Moving the rpc_error binding into the crash manager is mandatory for it
to be used in the website.
Part of https://github.com/odoo/odoo/pull/32132
task-1894820
As some formatting tools already exists, it is time for float_time
conversion to have its own. Purpose is to extract formatting logic
from the float_time qweb widget to tools, in order to reuse it
in mail.template (jinja).
We named it 'format_duration', to follow babel convention. This
can bring confusion with the duration qweb widget, but this widget
should be called 'timedelta', as it is more generic than this one.
Task-2025396
closesodoo/odoo#34417
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
This commit moves formatting helpers method used in mail.template to tools. The goal
is to reuse them anywhere in odoo, and not only in mail templates. Thoses method are
used to format date, datetime, amount, ... according to user localization (currency,
language, pattern, ...).
This commit also improve the formatting methods of 'date' and 'datetime': we are now
taking the 'lang_code' into account. Indeed, as the implementation uses `babel` lib,
it is easy and usefull to add the language option, to display the given dates into a
particular language. This parameter is optional to keep compatiblity with existing
code.
Task-2025396
Code Courtesy of @tde-banana-odoo
Purpose
=======
Having some usability check to be sure to make the pay
for everyone, and don't loose contracts.
We would like to remove incoming and to renew columns in
hr.contract and replace them by a kanban state. In employee, we would
like to add warning on the kanban to warn the hr responsible there
is no contract or a contract is about to expire
Specification
=============
hr.contract kanban:
- add a kanabn state
- it becomes red automatically when the contract is in running and expire in 7 days
- add aquick search in filter to filter on expered soon
- the kanban state can be changed manaually (in case of there is several rh)
- sort by contract end date set first (more close of today first)
Employee kanban
- add an red icon if there is no contract in Runnig status OR there is a
kanban state red in their contract (whatever the status).
- add a quick seaach on employee with warning
- State pending + green = incoming
- State confirmed + red = about to expire / to renew
closesodoo/odoo#33489
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Martin Trigaux