Before this fix, a traceback occured when we clicked on the translate icon
in a form dialog.
The `translate` event wasn't stopped and was thus handled by the dialog's form
controller and by the main controller.
Before this fix, multiple records were created if you clicked
on the quick create of a many2one in a modal.
The 'mutexify' event wasn't stopped and was thus handled by
the dialog's form controller and by the main form controller.
* web_editor, web_tour, website_event_track
Before this commit, one JS file was responsible for all the library
extensions and fixes. There were two main problems with this system:
- The file was only available in the backend (as some extensions are
made on backend-only libraries).
- Some other modules were doing library customizations.
This commit creates one file per library to regroup their associated
customization and adds them in the right asset. These are placed in
the web module and every other module should avoid doing customizations.
This allows to have libraries consistency accross all modules and
between the backend and the frontend.
Steps to reproduce the bug:
-Change the default lang on the website to be different than en_US
-Edit the name of a product in the website
Bug:
The name of the product is changed in en_US and not in the language
set on the website. The lang is in fact removed from the context in
function saveElement(in addons/web_editor/static/rte.js).
opw:747084
The module `crm.voip` alters the focusable behaviour of the phone
widget by overriding the `canCall` method.
We thus disable this test if the module is installed.
Creating and editing mass mailing in multiple language is managed with
the change 05daa15.
But currently the language the mass mailing is sent in, is the language
of the "Process Mass Mailing Queue" (root user if not changed) so all
the recipients will receive the mail in the root user language has at
the time the given batch of mails is sended.
So this is different from what someone could expect by it being
translatable. In any case the recipients list could be based on a lead,
a partner a mass mailing contact or other and a language could not be
determinable in stable (a mass mailing contact does not have a language
for example).
If the system worked, there is also a usability downside in the meaning
that someone could duplicate a mail and not check all translation and
not be aware that the mail he see is maybe not the mail that will be
received (if translations have not all been completed).
In stable to have the same behavior in any case and lessen the usability
burden of users thinking erroneously the mass mailing may be sent in
several languages depending on a not-existing heuristic, this changeset
remove the translatability of mass mailing content.
This has the following effect:
no translation editing appear,
the mass mailing is edited and sent in one and the same language,
If someone want to send a mass mailing in several language, currently in
Odoo it would then require to:
duplicate the mass mailing,
change the domains of recipients base on choosen heuristic,
edit the duplicated mass mailing in the choosen language
opw-746445
opw-746776
closes#17718
If the user change the access right to filter some stock location or multi
company, the user can have an access error to read stock pack operation.
opw-747526
Before this the -webkit-text-security CSS property was used. This, as
the name implies, only works in webkit based browsers. Instead we can
just render the PIN code as •'s since the value of the inputBuffer is
used (not the rendered text) when checking the PIN.
Fixes#16458
This patch allow to select several invoices/refunds or bills/bill refunds and launch the contextual action to register a payment for all of them.
Where, before, the system allowed that only if there was a single partner, it will now create and post a payment for each of them.
Was PR #https://github.com/odoo/odoo/pull/15228
Was task: 24014
Purpose
=======
Some field labels are not very explicit
Specification
=============
- Rename "Base Model" into "Model"
- Change "Trigger condition" (Condition Frist char(C) uppercase)
- Rename Domain into Apply on
Rev. https://github.com/odoo/odoo/commit/c5f8f35747b4ca9633c664d6be74614c5ce22fcd
introduced a regression: the input of widgets 'email' and 'url' was not correctly
focused anymore with tab navigation.
The method `getFocusableElement` on their common parent (`InputField`) has not been
correctly overriden because `_super``was not called in edit mode.
Purpose
=======
pro-forma concept is not easy, it is an adjective in english, it should be "Pro-Forma Invoice" to avoid confuision
Rename it everywhere (report, form, settings)
Specification
=============
In Sales/Settings, Sales/Quotations and in the report (.pdf)
In version 8.0, there was a stored field `minimum_planned_date`.
In version 9.0, this field was renamed `date_planned` and loose it
store attribute.
In version 10.0. the field is stored again.
Keeping this `oldname` attribute will lead to reuse old data from
version 8.0 when migrating the database to version 10.0.
Closes#17631
opw-744097
Now, an abandonned cart is:
- a draft quotation
- in a sales channel with type = website
- with a customer set (not public user)
- created more than one hour ago
- removed from_website filter in search view of website sale, added domain in view for display website side sale
- use proper filter for display 'Orders' and 'Orders to Invoice' in dashboard
this commit closes#17383 task-745391
Before this fix, it was possible to set the widget 'pad'
on char fields but it only worked if the current model
inherited from 'pad.common'.
In the other cases, it crashed on closing Studio.
As there is two models only (project.task and
note.note), we decided to remove the possibility to set
this widget in Studio.
opw-745997
During the formating method, the country code
was compared to the country phone code. Indeed,
phonenumbers python lib return a `PhoneNumber`
object having a `country_code` attribute
refering to the country_phone_code, and not
the country_code (like odoo means).
Consequence: changing the country on a lead
did not make the phone validation work.
Thus, it was required to give both code (country
and country phone codes) to the phonenumbers API,
in order to make a correct verification.
When refusing leave, we can not remove linked timesheet,
since they are attached to the leave.
We need to first detach it, then remove the timesheet
entries.
Also, add a test about the removal of linked timesheets.
Let's consider 4 products P0, P1, P2 and P3 where:
- P0 depends on P1, P2 and P3
- P1 depends on P2 and P3
- P2 depends on P3
NB: "x depends on y" means that there is a phantom BOM for x where
y is in a line.
With this example, before the fix, when creating a MO for P0,
the function "explode" raised a user error saying that there
was a recursion error.
Even if in this case there was no recursion.
Now to check if there is a recursion, a graph of the dependencies of
the bom is created while exploding the boms and a function "isCyclic"
is applied on the graph to verify that there is no cycle which means
no recursion in the dependencies.
The algorithm was taken from this site: http://www.geeksforgeeks.org/detect-cycle-in-a-graph/
opw:745453
Purpose:
========
The res.config.settings are quite a mess. The API is not well know and the general usage in the common modules is bad.
Specifications
==============
Clean use of ir.values in models
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- clean use of ir.values -> those should be only real default values for existing fields in other models.
- Use ir.config_parameter or something else if conversion is required
reset values when option is disabled
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
propagate checkboxes in settings. Ex: "use <my feature> opens <feature_value> configuration". Code should handle both <my_feature> and <feature_value>. Unactivating a feature should disable it really.
SALES
default terms & conditions
WEBSITE
Google Analytics
Google Analytics in dashboard
INVENTORY
Security Lead Time for Sales -> reset to 0
Security Lead Time for Purchase -> reset to 0
No Rescheduling Propagation -> reset to 1
MANUFACTURING
Security Lead Time -> reset to 0
clean alias congiguration
~~~~~~~~~~~~~~~~~~~~~~~~~
crm, project: remove unnecessary and unused generate_sales_team/project_alias, conf is done on sales team / project
crm: generate_lead_from_alias cleaned
hr_expense: correctly take into account "Use Mailgateway" settings, reset alias if not set
pos: mutli sales price settings cleaned
sales: multi sales price settings cleaned, default deposit product cleaned
website: has_google_analytics, has_google_analytics_dashboard, has_google_maps settings cleaned
website_sale: multi sales prices settings cleaned
print: default_provider_id
Ease google analytic settings
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
it's hard to get all the google analytics working. Setup steps are still confusing. And if you set up analytics API first (before creating an account), you get a traceback in the dashboard...
review google analytics id wizard
- How to get my Tracking ID
- How to get my API Client ID
- open those links in new tabs
make sure any traceback pops up if the user enter a client ID without a Tracking ID. It is the case for now. One way is to block the
user with a warning: Please enter your Tracking ID.
as soon as an ID is set, activate related features and populate fields in website settings + some changes in labels
only display Google Analytics in Dashboard in website settings if Google Analytics is checked
+ blocking warning if the user enters a Client ID without any Tracking ID
Reorganise files according to the guidelines
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Declare models in camel case, place python files in models, xml views in views...
Remove some useless/unused code
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Some chunck of code are never called or are useless.
Clean ir.actions.todo models
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Remove some useless fields:
- type: Historically we used ir.actions.todo to make complex things. Now we only use them to redirect to a specific action when a module is installed. All our ir.actions.todo type is `automatic`
- Note: Useless
- Group_id: All our ir.actions.todo are launched by the administrator. No need to specify groups on it.
Prevent to be redirected everywhere on update
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Prevent to have more than one open ir.actions.todo. This avoid this use case:
- Install ecommerce, be redirect to the theme selection
- Install note, be redirected to /shop.
We just take the last defined ir.actions.todo into account.
Stay on a config setting form by pressing apply
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If we click on Apply, we want to stay on the config page to see the new fields coming from the module you just installed
Keep the current behavior when installing a module from the App menuitem, which is either jumping to the app switcher or jumping to a specific action if defined on this module
Clean default method to get/set the values on a config form
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Currently there are 4 types on fields on res_config:
- `default_`: These fields should use ir.values and they have been cleaned in a previous section of this commit message
- `group_`: They define security groups
- `module_`: They allow to install/uninstall modules
- Other fields: They are the other fields that are implemented in a quite messy way.
Currently all the methods beginning by `get_default` are used to fetch their default values, usually by looking in the ir.config_parameter table.
Currently all the methods beginning by `set_` are used to set their values, usually in the ir.config_parameter table.
This section purpose is to replace all the occurences of `get_default_foo` and `set_foo`. As these methods won't be called anymore, a warning is logged to notice its deprecation. They are replaced by the generic methods `get_values` and `set_values` that should be overridden to define the behavior of the added fields.
Add a test on res_config on page loading and saving
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Try to create and execute all res_config models. Target settings that can't be loaded or saved and avoid remaining methods get_default_foo` or `set_foo` that won't be executed.
Try to create and execute all res_config models. Target settings that can't be
loaded or saved and avoid remaining methods `get_default_foo` or `set_foo` that
won't be executed is foo != `fields`
Currently, all the methods that start with `get_default_` and `set_` are called on a res.config.settings loading or saving.
This commit purpose is to replace all the occurences of `get_default_foo` and `set_foo`. As these methods won't be called anymore, a warning is logged to notice its deprecation.
The generic method `get_default_fields` and `set_fields` could be improved too. The method names and API are not so good:
Why "default" fields? What you ask for is the current value of the stuff, shown as fields in the model. The values are fed as default values in the wizard, but that's an implementation trick.
Why "fields"? What you ask for are configuration parameters, and such things.
Why passing a list of fields? Its value is never used.
We should further simplify the API of both methods to something like
def get_values(self):
return {}
def set_values(self):
pass
Martin Geubelle