In P3, random.sample requires that its parameter be a Sequence or a
Set. This blows up _cart_accessories.
So opt BaseModel into both ABC, seems to work fine.
* P3 gets a "proper" arg node
* P3's arguments adds two parameters (kwonlyargs and kw_defaults) for
keyword-only parameters
* P3's ``fn(**bar)`` only works if ``bar`` *only has string keys*,
some of the contexts in qweb passed non-string keys and blew up
* P3's ast.If requires a non-empty body, add ``[ast.Pass()]`` ballback
for non-literal bodies
* Python 3.4 adds new convenient bytecode-inspection API to dis which
is nice, however Python 3.6 also switches from the old bytecode to a
new wordcode which breaks _get_opcodes and *requires* that we use
the new API
* add various opcodes which either were added in Python
3 (CALL_FUNCTION_EX) or were only used for some small corners of
Python 2 but have been expanded or despecialised in Python
3 (BUILD_SLICE)
* 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.
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
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)
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
Method `get_default_fields`
===========================
Currently all the methods beginning by `get_default` are used to fetch their default values, usually by looking in the ir.config_parameter table.
As several methods `get_default_fields` have been defined in res_config classes, it better to define it in base and calling to super to avoid side effects like the following example
- 2 classes that override the same class and define the same method. In that case one method will never be called, as it is ovewritten by the other.
Method `set_fields`
===================
Currently all the methods beginning by `set_` are used to set their values, usually in the ir.config_parameter table.
As several methods `set_fields` have been defined in res_config classes, it better to define it in base and calling to super to avoid side effects like the following example
- 2 classes that override the same class and define the same method. In that case one method will never be called, as it is ovewritten by the other.
Methods `get_default_foo` and `set_foo`
=======================================
This commit deprecates the method starting with `get_default_` or `set_` in the res.config models. A warning is raised in that case.
* Set the blocking warning if the user enters a 'Client ID' without
any 'Tracking ID'.
* 'Google Analytics in Dashboard' field is visible only if
'Google Analytics' is checked in website settings.
* Get/Set the value of 'google_analytics_key' and
'google_management_client_id' from 'website' model instead of
'ir.config_parameter' on 'Google Analytics' wizard.
* If ID is set on 'Google Analytics' wizard then activated the related
features and populate fields in website settings.
It now update the website settings parameter use_google_analytics_dashboard
so that the settings are correctly updated with the user choice.
Implementation is changed so that the dashboard uses a jsonRpc call instead
of directly calling ir_config_parameter set_param.
Fields like `default_foo` still used ir.values although those are system-wide
parameters and should therefore be stored in ir.config_parameter
table.
When no default_model is set on a field, don't prefix it by `default_`.
Fields like `default_foo` still used ir.values although those are system-wide
parameters and should therefore be stored in ir.config_parameter
table.
When no default_model is set on a field, don't prefix it by `default_`.
Fields like `default_foo` still used ir.values although those are system-wide
parameters and should therefore be stored in ir.config_parameter
table.
When no default_model is set on a field, don't prefix it by `default_`.
Also, reset security_lead when use_security_lead is unchecked to avoid it to be used in further computations
Fields like `default_foo` still used ir.values although those are system-wide
parameters and should therefore be stored in ir.config_parameter
table.
When no default_model is set on a field, don't prefix it by `default_`.
Various code using the sale_note field (default terms and conditions)
is updated to check the use_sale_note field that is the setting
enabling it.
This is a preferred solution compared to resetting sale_note each time
use_sale_note is set to False in order to avoid loosing the data
users may have entered in sale_note field.
Fields like `default_foo` still used ir.values although those are system-wide
parameters and should therefore be stored in ir.config_parameter
table.
When no default_model is set on a field, don't prefix it by `default_`.
Also, reset po_lead when use_po_lead is unchecked to avoid it to be used it further computations.
According to usability experts configuring a sales team alias should
be done directly on the sales team view and not through an hidden
and strangely configured settings.
Fields like `default_foo` still used ir.values although those are system-wide
parameters and should therefore be stored in ir.config_parameter
table.
When no default_model is set on a field, don't prefix it by `default_`.
Also, correctly reset manufacturing lead time
Settings now correctly use an ir.config_parameter telling whether to
use or not manufacturing lead time. An onchange is added in order to
ensure that lead time is not still used by code although the settings
is unchecked.
This commit fixes
* `default_alias_email` is now called use_mailgateway to better reflect its use. When
unchecked the alias_prefix value is set to False in order to
reset the alias.
* empty list message displays receipts alias only if the mailgateway
option is activated
* some code cleaning so that get_default_ and set_ methods are put
into a sole method in order to lessen code size
Fields like `default_foo` still used ir.values although those are system-wide
parameters and should therefore be stored in ir.config_parameter
table.
When no default_model is set on a field, don't prefix it by `default_`.
Also, remove deprecated generation of alias on sales team.
According to usability experts configuring a sales team alias should
be done directly on the sales team view and not through an hidden
and strangely configured settings.
* portal, sale
Some primary buttons had both the 'btn-primary' and 'btn-default'
classes, which is wrong. In standard bootstrap, the 'btn-default'
class seems to be masked by the use of 'btn-primary' but it is not
the case in some of our themes.
Xavier Morel