The dataset implementation has been improved to handle the result of a `read`
on ids that are already modified in the dataset: the lists `to_create` and
`to_write` are updated properly.
Use `field.convert_to_onchange` to format the output of method `onchange`. By
default it behaves like `convert_to_read`. This is useful for the many2one
case, as the client automatically receives the display name of the record.
For the *2many case, we return a list of dicts values, in recordset order, with
all the known fields in the view:
[{id: 42, name: "Existing record"}, {name: "New record"}, ...]
Each dictionary contains the values of all known fields in the view. The
client is responsible of determining which fields are dirty by computing the
difference with former values.
Since the method `onchange` now uses `field.convert_to_onchange`, the method
`field.convert_to_write` has been simplified, as it no longer needs its extra
parameters `target` and `fnames`.
Titles are now just for contacts (people), not for companies
anymore. For that purpose directly adding the suffix (Ltd, ...)
in the name is sufficient.
The domain field is therefore removed.
Updated data, demo, views, code and res.partner model accordingly.
I do not think portal users need to log the holidays or the see the list of installed modules
Also, I got tired of the generic cube icon for portal in the new design; feel free to change it if you find something more meaningful
- remove public project
- some data was depending on demo data, moved it to demo
- add website_published mixin on projects
- remove project members from frontend view
Since public projects do not exist anymore, project.project objects now have the website_published mixin; any project with the rating activated and published on the website will be visible in the "Project Customer Satisfaction" link for public users
The frontend template has also been modified to remove the team members photo since project members have disappeared as of 9398fe9 by our dear @tde-banana-odoo
[ADD] website_project_issue_sheet: link module between website_project_issue and project_issue_sheet
Frontend integration of issues:
- issues details
- chatter integration
- timesheets
[REM] portal_project: move ALL the things
- move portal access rights from portal_project and website_project_issue to project and project_issue
- move portal menuitems back to their respective module
- remove public visibility of projects
- adapt demo data to have a 'Demo Portal' project
- add correct access rights for account.analytic.line for portal users
- small view tweak (do not display 'timesheet' tab if one can't see antyhing in it anyway)
This dashboard has implied some refactoring:
- the wizard pos_session_opening has been deleted and all the methods have been put inside pos_config
- new fields in pos_config to display some useful informations (closing balance, closing date, etc.)
Removed a code that allows to write a message, using a subtype that
does not exist. This is probably critical for some business, but
as I don't know which ones, let's remove it.
Chatter is sufficient.
Make the function traverse the class hierarchy upwards, retrieve the value of
the attribute, and stop when the value does not satisfy the given condition.
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`
Christophe Matthieu