Before this commit, translations were edited in a list view with a filter
on the field that needed to be translated.
After this commit, the translations for each fields are translated in a
dedicated dialog. The changes done to the current language are taken
into account immediately, both ways, from the dialog to the form and
from the form to the dialog.
Translating terms is also available in create mode, the user will be
prompted to save before editing a translation
Task ID: 2028152
closesodoo/odoo#36185
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
This prevents a bunch of queries that are useless when creating a
record. Indeed, right after a record has been created, no other record
has a many2one reference to it. In other words, inversing a many2one
field from the record just created always gives an empty recordset.
Those useless inversions generate about a dozen queries when creating a
`res.partner`, for instance.
This saves queries, but not much time.
closesodoo/odoo#36566
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
PURPOSE
Allow auto install of all SMS-based feature. Move partner onchange formatting
directly inside phone validation.
SPECIFICATIONS
Phone validation: set as auto install. Phone validation module is a direct
dependency of SMS which is integrated in more and more business apps. As such
we want sms to be auto-installed, hence making phone_validation auto-install
as well.
Send SMS feature should not be an option anymore. Move SMS settings it to the
left of the Partner Autocomplete one and remove field. Since SMS is now
integrated with several business apps we do not want the user to uninstall that
module "by inadvertence".
Move the onchange on the phone field of contact model directly inside phone
validation to have it available in all SMS based applications.
LINKS
Task 2061765
FP/AJU request
closesodoo/odoo#36481
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Allow auto install of all SMS-based feature. Move partner onchange formatting
directly inside phone validation.
SPECIFICATIONS
Move the onchange on the phone field of contact model directly inside phone
validation to have it available in all SMS based applications.
LINKS
Task 2061765
PURPOSE
Allow auto install of all SMS-based feature. Move partner onchange formatting
directly inside phone validation.
SPECIFICATIONS
Send SMS feature should not be an option anymore. Move SMS settings it to the
left of the Partner Autocomplete one and remove field. Since SMS is now
integrated with several business apps we do not want the user to uninstall that
module "by inadvertence".
LINKS
Task 2061765
PURPOSE
Allow auto install of all SMS-based feature. Move partner onchange formatting
directly inside phone validation.
SPECIFICATIONS
Phone validation: set as auto install. Phone validation module is a direct
dependency of SMS which is integrated in more and more business apps. As such
we want sms to be auto-installed, hence making phone_validation auto-install
as well.
LINKS
Task 2061765
Before that, we relied on the fact the call to super() assigned the attachment_ids field, which was wrong outside mail.compose.message. Hence, we fix that by directly browsing the attachment.
closesodoo/odoo#36552
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
The ORM overrides the default defined programmatically on the field, and
set a default function that retrieves the value in `ir.property`.
closesodoo/odoo#36545
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
There's no readonly possibility on the calendar view so the only way to
prevent updating a done or cancelled transfer is to raise on the write.
We should to raise in the inverse function so that it is possible to
bypass the constraint by writing directly on the move, as we want to
change some date in the demo data.
closesodoo/odoo#36550
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
We got an error before e.g. when we changed the address
of a created company because the company created is not yet
in the allowed_companies in the environment.
Also, it does not make sense that the company of the partner
of a company is that company. When you create a new partner,
partners are shared by default between companies (company_id False).
And in most multi-company situations, operations are made between
them, so it makes extra sense to share their partners.
So, we don't set the company of the partner of a company anymore.
closesodoo/odoo#36510
Signed-off-by: Romain Libert (rli) <rli@odoo.com>
Currently, mailing failures are using 'fa-envelope-o' (light design)
while SMS failures are using 'fa-comment' (solid icon). To align them,
and make the mailing failures more visible, we change fa-envelope-o
to fa-envelope.
task-2063188
closesodoo/odoo#36397
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
In this commit, instead of change the whole button using XPATH
only change the attributes of button.
After this commit, displayed only one 'Update Cost' button.
task-2067787
closesodoo/odoo#36535
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
We display the button on the move if detailed operations is enabled and
if pre-fill detailed operations is disabled. There was a mix of computed
field/conditions in the xml resulting in an always hidden button.
We now only use the computed field.
related to 3520220268closesodoo/odoo#36519
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
These o2m should be full width in enterprise. The only way to make them
full screen is to make them direct children of their tab. Duplicate
detailed operations and switch some field in operations to make it work.
closesodoo/odoo#36518
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
stock.location have a _rec_name to complete_name and an override of
name_get that do not use complete_name
To allow sorting on the name in the webclient, we display complete_name
in the view instead of display_name, we actually get rid of the name_get
and use its implementation in _compute_complete_name.
closesodoo/odoo#36516
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
The ColorPickerDialog lazyloads its template. In the test
environment, nothing was done (except for a single nextTick) to
ensure that the template has been loaded before interacting with
the dialog. This led to non deterministic failing runbot builds.
Also correctly load the signature template before running its tests
instead of doing two chelou nextTick();
closesodoo/odoo#36511
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
PURPOSE
In order to rewrite some tests, remove low-level tests and add coverage
first step is to reorganize a bit test_mail content. Several tests cases
are spread among several files and finding back some feature coverage
tests is not easy.
SPECIFICATIONS
Quickly clean common class and lessen data creation by default. Offer some
tool methods, notably to create portal users used in some tests but not
all, or to create mail templates.
Reorganize tests, notably
* put message_post related test in test_message_post;
* have only composer related test in test_message_compose(r);
* put alias tests in test_mail_gateway;
* put moderation tests in test_channel, except those related to mail
message model that should be in test_mail_message;
* put mail.thread.cc specific behavior tests in mail_gateway for gateway
related tests and test_discuss for recipient suggestion tests;
* put composer with template tests in with composer tests, put post with
template tests with post tests, put tracking multi company test with tracking
tests;
* rename mail-resend to message_management and multi_company to
mail_redirect;
This merge does not change anything functionally. Tests are globally the same.
having better organized files will allow to rewrite and improve them.
LINKS
Task 1958697
closesodoo/odoo#36508
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
In order to rewrite some tests, remove low-level tests and add coverage
first step is to reorganize a bit test_mail content. Several tests cases
are spread among several files and finding back some feature coverage
tests is not easy.
SPECIFICATIONS
Reorganize tests, notably
* put composer with template tests in with composer tests;
* put post with template tests with post tests;
* put tracking multi company test with tracking tests;
LINKS
Task 1958697
PURPOSE
In order to rewrite some tests, remove low-level tests and add coverage
first step is to reorganize a bit test_mail content. Several tests cases
are spread among several files and finding back some feature coverage
tests is not easy.
SPECIFICATIONS
Split cc tests to either discuss or mail gateway tests. It allows to remove an
unnecessary file.
LINKS
Task 1958697
PURPOSE
In order to rewrite some tests, remove low-level tests and add coverage
first step is to reorganize a bit test_mail content. Several tests cases
are spread among several files and finding back some feature coverage
tests is not easy.
SPECIFICATIONS
Reorganize tests, notably
* put message_post related test in test_message_post;
* have only composer related test in test_message_compose(r);
* put alias tests in test_mail_gateway;
* move some discuss tests to post tests as they are linked to notification
details, not really Discuss features.
LINKS
Task 1958697
PURPOSE
In order to rewrite some tests, remove low-level tests and add coverage
first step is to reorganize a bit test_mail content. Several tests cases
are spread among several files and finding back some feature coverage
tests is not easy.
SPECIFICATIONS
* put channel moderation tests in test_mail_channel;
* rename resend to message management;
* rename multi company test to redirect tests:
LINKS
Task 1958697
PURPOSE
In order to rewrite some tests, remove low-level tests and add coverage
first step is to reorganize a bit test_mail content. Several tests cases
are spread among several files and finding back some feature coverage
tests is not easy.
SPECIFICATIONS
Quickly clean common class and lessen data creation by default. Offer some
tool methods, notably to create portal users used in some tests but not
all, or to create mail templates.
LINKS
Task 1958697
This reduces the number of queries by 4 on this route.
Here are the solutions that have been considered on how to share this prefetch.
[0].name
--------
Calling `(first_post | posts)[0].name` does not work because `[0]` is another
prefetch, it still does all the queries.
See `__getitem__` in `models.py`, `_prefetch_ids` is not forwarded, as opposed
to `__iter__`.
.mapped('name')
---------------
Calling `(first_post | posts).mapped('name')` reduces the number of queries by 2
(because it does an iteration = share prefetch, but this is CPU time for
nothing).
The problem is that even in that case, when computing the display name of a blog
for the slug (`slug(blog_post.blog_id)` or `slug(first_post.blog_id)`) if the
posts are on a different prefetch, the query will be done twice because their
m2o (blog_id in this case) will be on a different prefetch each.
.blog_id.mapped('name')
-----------------------
Calling `(first_post | posts).blog_id.mapped('name')`. would be the same as
using `with_prefetch` in this case, but it will be less robust. It is also
slightly more CPU to do the map for no reason, though it is really not a factor.
But the main problem is that it only works because we know `.blog_id.name` will
be accessed, but if the view is changed some day to access a field of another
m2o, this will not be optimized, while `with_prefetch` it is always guaranteed.
In conclusion the solution with `with_prefetch` was used because it is explicit,
more robust, and without any side effect.
Part of task-2061122
closesodoo/odoo#36507
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
When trying to update a BoM from an ECO, `default_product_tmpl_id` is set
in the context. This was mismatching whith the product template of any new
BoM lines writen on the new BoM. To fix this we simply add the field
`product_tmpl_id` in the view of the BoM lines with `force_save` set,
to prevent using the product template defined in the context.
closesodoo/odoo#36469
Taskid: BugsLogistics
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
When creating a scrap, the `scrap_qty` is fixed to 1 in case the product
is tracked by serial number.
Also, pass the company and product ids in case user creates a new lot
number from the scrap form.
* sale, sale_management, sale_product_configurator,
website_sale_product_configurator
1. Product Configurator
-----------------------
- It is now possible to change the quantity of an optional product
- Default optional product quantity is set to its parent product
current quantity.
- The order in which optional products of an option appear when added
to the cart is fixed it will now be displayed below the correct
product even if there are multiple options with the same product
template id.
To achieve this a unique id has been added to the products and
a reference to their parent unique id.
- The way products are given to the backend when configuration is done
has been improved, now only an array with the product and useful info
is submitted.
2. eCommerce in cart review
---------------------------
- It is now possible to change the quantity of an accessory product.
- It is now possible to delete an optional product added through the
product configurator.
- The labels "Option: optional product name" below the parent product
are now removed when a related optional product is deleted.
- The labels "Option: optional product name" are now displayed below
the correct product.
task-1951560
closesodoo/odoo#33002
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
issue: a traceback is faced when configured a journal alias to create
invoice/bill when fetching emails with a pdf file from that alias.
closes odoo/odoo#34740
Task: 34740
Closes: #34740
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
- show period along with 'Tax Report' activity of journals on accounting dashboard.
- added 'Upload Invoices' button on sales journals in Accounting Dashboard.
- added 'New Bill' button on purchase journals in Accounting Dashboard.
Task: 34740
Closes: #34740
Co-authored-by: Hardik Prajapati <hpr@odoo.com>
Adds a domain on quant `lot_id` when user changes quantity on hand of a
specific product, so user can select lot only for this product (or its
product variants if user come from a product template).
closesodoo/odoo#36467
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Before this commit, and since the new orm, we cannot open a record that have
no res_model and res_id.
With new orm, we should return a value for all records.
Now, we can open attachement form view without the error:
ir.attachement(<id>).res_name traceback
closesodoo/odoo#36446
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
In order to improve and clarify the mass-mailing (Email Marketing) module
several changes have been made
1 - Clarify the name of the application:
2 - Prevent the “Quick Add/Create” feature in the mailing kanban view
3 - Label and wording clarification in mailing_mailing form view :
4 - Clarify button names "Send now" ("put_in_queue")
5 - Mailing Form view layout
6 - Clarify the required field
7 - Clarify the readonly field
8 - Wording clarification if scheduling mail in the future
9 - Add a Placeholders tools page in the form view:
10 - Clarify the Campaigns view
11 - Clarify the Action Helpers
TASK-ID : 2046078
closesodoo/odoo#36124
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
We must be able to change the hostname of IoT Box
even if we do not pass him a token.
So we give a default value to 'url' and 'token'
closesodoo/odoo#36428
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Sometimes when using a form view in a modal (e.i.: in a gantt view), we might
want to have some button in the footer. We expect clicking on buttons to close
the dialog but nothing happens, since the webclient does not know that this is
a modal.
To do so, we provide the `close='1'` attribute on the button, in form view.
This will trigger the event closing the modal.
This is done with the benediction of aab-odoo
Task-2024216
closesodoo/odoo#36493
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
When selecting the lang browse record, it can be empty when language is not
activated. As we don't need that lang to be active to translate the
format datetime (lang code is enough for Bable lib), we simply
need to fallback to prevent error.
Removed a browse on partners made in a loop, for a substantial gain of time and DB queries.
Observed gain for a real data DB with 500 partners to print in the aged report:
time (ms) # queries
Before patch 4583 1623
After patch 2932 553
Gain 1651 (36%) 1070 (66%)
closesodoo/odoo#36488
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
This commit tries to fix multi company problem in Expense application. Indeed, no check
were done to ensure this business flow. Some technical decisions were made:
- journal company: the journal define the company in which the accounting entries will be
created. We know ensure with 'domains' and constraints that the journal have the same
company as the expense sheet.
- journal conditionnally required: the journal is only required when posting the expense. It
is set by defaut on creation, but can be modify by accountant users. This is why the expense
company determine the journal and not the opposite.
- company fields required: As we need to use the company from the expense / expense sheet to
determine the journal field and since expense models are business models, we needed to put
company fields required.
Business Flow
When an employee creates an expense, the expense should be in its current company. A
product from any allowed company can be chosen. Only the taxes of the expense company are
applied to compute amounts. Then a report (sheet) can be created. We ensure that the expense
lines of a report belongs to the same company as the report and to the same employee. Once
submitted and approved by manager, the account journal can be set: it is forced to be in
the same company as the expense report. The accounting entries are created in the journal
(and expense report) company. As the analytic account can be shared (company is not set)
the analytic entries will be in the expense company (handle by the accounting module).
The payment is now registered in the expense company.
Migration
As company fields are now required, fill the company fields with the company of the related
employee, or fallback on the one from the journal.
Task-1999686
closesodoo/odoo#36447
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
As we have to set account on product and product category to know in which
account generate some accounting entries in some business flow (e.i.: expense),
we need to keep some consistence with those accounts.
Since those fields are company dependent, meaning their value depends on the
current company, we want to ease the selection for the end user by only displaying
the relation available in the current company. To do so, specific domain are needed.
This guidelines should be applyied on each property fields.
Task-1999686
PURPOSE
Allow the user to enrich a lead based on the domain of the email address of
the client.
SPECIFICATIONS
Following fields will be populated if found using clearbit and if they are
not yet populated :
* description
* partner_name
* reveal_id
* website
* street, street2, zip, city, country_id, state_id
* phone (using the first number found in clearbit)
* mobile (using the second number found in clearbit, else the same as phone)
A message will also be logged in the chatter.
If no data is found using clearbit no credit is used and a message will be
logged. If the user has no credits he will be redirected to buy credits for
the service.
It is possible to enrich using the 'enrich' action in listview or with a
cron that will run every hour on leads not older than 1 hour.
Add a "Lead Enrichment" setting in CRM installing lead enrichment.
LINKS
Task 193185
closesodoo/odoo#36419
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Sébastien Theys