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
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.
When several user run a production on a workorder, things go awry.
For example the end of the "productive" production is computed based on
ProductiveStartTime + DurationExpected - Duration
so if the duration was bigger than the time expected, we easily get a
productive end before the start, and start of the "reduced speed" before
the production actually happened.
eg:
productive time is 30 minutes
user A: start production at 10:00
user B: start production at 10:10
production is set to done at 10:50
=> result before the patch:
user A has been productive from 10:00 to 10:30
user A has not been productive from 10:30 to 10:50
user B has been productive from 10:10 to 10:00
user B has not been productive from 10:00 to 10:50
this is totally erroneous.
=> result after the patch:
user A has been productive from 10:00 to 10:30
user A has not been productive from 10:30 to 10:50
user B has not been productive from 10:10 to 10:50
this is a measure of right, we could argue about wether one or the other
should be productive or not but this is anyway an edge case.
In master we are considering only allowing one user to run a production
at a time but we prefer not to change such a behavior in stable version.
opw-709223
closes#17528
The tab navigation was only working in edit mode. Entering a readonly form
view with input fields was causing a traceback.
As the default browser behaviour has been overriden with custom navigation,
we need to specify which widget can be focused (e.g.: url, many2one, etc.).
In an empty kanban view, when moving a freshly created record from
the second column to the first one, then moving it back again in to
the first one, the record was mysteriously duplicated.
When moving the record, it should be removed from the old column.
In this case, the second column was not found (and thus the record
not removed) because the iteration was on `parent.count` (which is
the count of records in this datapoint (1 in our case)) and not
parent.data.length (the number of columns).
The mentioned commit exposed a `Dialog` instance thanks to a return and
an event triggering. The forward-port failed in saas-14 as the code
landed in the wrong function.
As the event trigger seems to be useless code without any context and
that this code has been hugely refactored in recent versions, this
commit simply removes it.
Feel free to expose variables again in version 11.0.
opw-748027
* 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.
Goffin Simon