in method `button_confirm_cash` of `account.cash.statement`
The check was verifying that the profit/loss account
was set on the journal, and if it was, it raised that it
wasn't, which is obviously wrong.
This was solved in Odoo 8.0 by replacing the code
by something more readable in 9dc9169, and the same
logic to check that the profit/loss accounts are
set is still there.
Closes#2924
Permission error on survey update
The user who answer the survey may not have delete permission for the user_input_line
In a survey, for a survey user (!= manager),
When browsing previous pages of anwsers,
the user wasn't allowed to change his answers
regarding simple choice, multiple choices and matrix
questions, as this kind of answers changes leaded to an
unlink operation, not allowed for survey users.
Closes#2901
Optimize registry.setup_models() such that some fields can be reused between registries. This happens when a model has the same base classes as another model.
This reduces the registry setup time.
On the runbot, this reduces the total execution time by ~20%.
When a model is set up, it can retrieve fields from a similar model (with the
same base classes). Only proper (not inherited), regular (non-related) fields
can be shared that way, since other fields may depend on other models.
Avoid this reference from a field to a model class; this will allow the sharing
of fields across model classes. Use `getattr` on class instances instead.
Split the methods `_setup_regular` and `_setup_related` in `base` and `full`
parts, such that the `base` part is done in `setup_base()`, and the `full` part
is done in `setup_full()`.
This optimizes the setup of models during the installation of modules: regular
fields are not set up again from scratch. Only related fields (which are less
common) are always set up from scratch.
The method uses the costly `inspect.getmembers` to retrieve the fields defined
on a model's classes. If the model is not modified by a module installation,
we simply reuse the fields retrieved in a former model setup.
The API of those method has been modified to take a recordset instead of a class
as parameter:
field.set_class_name(cls, name) -> field.setup_base(model, name)
field.setup(env) -> field.setup_full(model)
The recordset gives access to an environment, and will ease code reorganization
in the field's setup methods.
Converting the following class methods to model methods will make them more
flexible for changes, in particular by making the environment available:
- `_add_field`
- `_pop_field`
- `_add_magic_fields`
- `_init_manual_fields` (renamed to `_add_manual_fields`)
- `_inherits_check`
- `_init_inherited_fields` (renamed to `_add_inherited_fields`)
Make an explicit distinction between both semantics of `_attrs`:
- the parameters given to `__init__` in `args`
- the non-slot attributes (memory optimization) in `_attrs`
Making a distinction between the column from which the field was created, and
the one created from the field, allows to keep the second one from a registry
setup to the next one. This opens a door for optimizations: the column may not
need to be recomputed.
- Add nocontent tip in kanban view of project documents and remove create button.
- Hide a lot of noisy fields from attachment form view in technical group.
On the `categ_ids` fields definition on `crm.lead`,
a domain has been added in order to prevent
the use of a sales tag belonging to another
sales team.
As the domain was overidden in the form views,
with a different domain, it was allowed
to use a sales tag from another sales team.
Besides, the domain applied in the form views,
`[('object_id.model','=','crm.lead')]`
is included in the domain applied in the fiel
definition.
Closes#2898
Force the 'uom in the context to False on the field 'product_id' in the popup
form view "sale.order.form.sale.stock", to force the non-propagation of the
context. To avoid using the uos in function "_product_lst_price" when computing
the public price of a product.
opw:646880
When placing an order in the ecommerce, it's
seems obvious that the partner is a customer.
Nevertheless, It wasn't flagged as such in
its partner from, preventing
to see him in the customers list
Fixes#2422Closes#2881
As the run method was optimized to assign and execute multiple procurements
at once in purchase, the method for creating purchase requisitions was not
triggered anymore. It is solved by inheriting from make_po instead in purchase_requisition.
Former implementation used ir_values to retrieve the dashboard action id from
its menu id. Using ir_values to do that doesn't work anymore since the
cleaning up of rev. e7e452f.
We now retrieve the action id from its xmlid directly in the controller.
The start field is a computed field but it doesn't have any inverse function
(write() is overridden in calendar.event to, among other things, play the
role of the missing inverse function). It is thus automatically set as
readonly, and the events can't be dragged and dropped in the calendar view,
since rev. d6d3d098 in which we start checking if the start_date is readonly
or not before allowing the drag and drop.
This rev. simply adds a "do_nothing" inverse function so that the date field
is not readonly.
In web_calendar, the date_start attribute is mandatory so fallbacking on
date_end and date_delay is unnecessary.
- correctly compute the invoice and its lines, in order to trigger the
computation of the membership_state on the partner
- correctly compute, using a true multi returning correct values, the
various dates of membership
- use the sequence of function field to ensure that the dates and state
are computed in the correct order; otherwise some states are not
reachable
- various fixes in the computation
tests crash and that there is a mismatch between the tests and
the module. However as the tests were badly written the asserts
did not fire.
Now the tests crash as they should be doing since a long time.
[CLEAN] membership: dead code / tests cleaning
Removed dead code, unnecessary comments in membership.py. Also added the
use of server datetime format instead of custom one.
Also slightly cleaned the tests. No change, but use data created for the
tests instead of relying on existing demo data, probably modified by
the user and difficult to track.
Removed marketing_user and marketing_manager groups, replaced by more
specific groups. Those are lead_automation_user and manager groups.
Previous commits have removed the use of marketing groups in other
modules (event, mass mailing, utm, ...). Those groups can now be
safely used in lead automation modules.
Christophe Simonis