Base render method now calls a prepare_qcontext method used to prepare
the qweb context used for the rendering. Website override of ir_ui_view
now simply inherits this method to add its own set of values instead of
doing strange things with the base render override.
Qweb context should be the same after this commit, i.e. containing a lot
of duplicated things like a copy of the context. The only change is that
user_id and res_company are now directly supported in base rendering
instead of only in website version of rendering. Future commits will
use those values.
-added tour for invoicing
-allow to set easily the number of the first invoice/bill/refund of a journal, from the invoice screen
-small usability fixes and refactoring
PURPOSE
=======
Simplify the way to activate currencies
SPECIFICATION
=============
On res.company :
Currency_id: options={‘no_open’: True}
oe_edit_only on “Activate more currencies”
In the list view of the currencies, replace the checkbox active by a boolean_toogle widger
There is normally a default filter on the currencies list view to only show the active currencies : this filter should be kept except if you arrive on this screen by clicking on "Activate more currencies" from the res.company and from the settings. Only the menuitem Currencies should only show the active ones
Since the previous commit, the `color_field` needs to be explicitly stated
in the options for the tags to be colored.
The previous behaviour (always read the field `color`) was leading to server
warnings if the field was not present on the comodel.
Thìs commit set the `color_field´ for every many2many_tags on fields that have
a `color` field on the comodel.
This reverts commit 1e2e55872f.
In debug mode, there's a checkbox to reload the language and overwrite the existing terms. This previous commit makes that use case impossible.
PURPOSE
=======
When I install a language, I shouldn't have to refresh the page to see the newly installed language.
Example : I install a language, then click on my user (upper right corner) and try to select this language. The newly installed language is not available. I first need to reload my page.
Before this commit, at each partner creation (including data import,
RPC import and tests) Gravatar server was polled, slowing down partner
batch import.
We then enable this feature only where it is needed: when creating a
partner from a view.
When a model contains a field translatable which has a unique
constrain, it is impossible to copy a record. Indeed, the unicity
constrain is always triggered, even if the model takes in charge the
overriding of the copy method to avoid duplication.
Introduced with commit ce7f31b0b0, with the goal to target only
XML/HTML translations. We apply this behavior in case of a callable
translate property, to target only the desired problematic use case.
opw-749481
The "Uninstall" button on the module form no longer changes the state of
modules, so that cancelling the wizard will not unexpectedly perform the
uninstallation. The uninstallation is performed only by clicking on the
"Confirm" button on the wizard.
Moreover, the wizard provides clearer information about the impact of the
uninstallation: what apps/modules will be uninstalled and what documents
(models) will be lost.
When importing translations with a csv, the state of the translations was
always set to "To translate" even if the state was "Translated"
due to function _inverse_source.
PS: Making self.source when self is considered as record set could lead to an error.
The return in this function was not needed.
In old API this function was called just for one record.
So this function expect only one record at each call.
opw:747877
* 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
It calls `onchange_state()` on `res.partner` which was removed on
(24aba60).
It was added to `res.users` long ago (009ea40) to support a `state_id`
field on the view `res.users.simplified.form` that is no longer there
since v8.0.
The method is then never called and was crashing if called.
Closes#17772
Closes#16973
Steps to reproduce:
1) Go to Settings -> Technical -> User Interface -> Views
2) Create a new view and give only name, leave fields View Type and arch_base empty.
3) Exception occures
Current behaviour:
- The user gets an exception with a full stacktrace.
Expected behaviour:
- The user should get a warning
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
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
Thibault Delavallée