Data-only modules imported via base_import_module
do not have fs-backed source files, so the arch_fs
field for views should always be NULL, and the arch_db
version is always used.
Avoid crashing at arch_fs detection during import
via base_import_module.
Add a flag to replace or not the previous product description.
Apply the same logic than in sale. Change the description field on a purchase
line only when the product is changed. opw 620093
Clean the views and replace wrong parameter in warning
Fix kanban:
Move invisible user_id field outside the kanban-box.
Since jQuery migration (1.8 -> 1.11), the function append has not the same behavior.
$([undefined]).append() will crash, so when Odoo whas trying to render the user_ids m2m field in kanban, that crashs.
Anyway, moving the code outside this kanban-box, will avoid to render an invisible m2m_tag.
Misc:
Escape html
concat with %s
[IMP] models: speedup registry loading (25% less time)
The field setup on models is improved: only new-api fields are determined when building the model's class; the final _columns dict is derived from the fields once they are set up. This avoids setting up fields and columns at the same time, and finally overriding columns with the result of field setup.
This branch also fixes the model setup in general: with the former code, a model could be introspected while it was only partially set up, and not all its fields were known.
It incidentally fixes the "loss" of parameter partial that is necessary when loading custom fields. And during a partial setup, one2many custom fields are not introduced if their counterparts (model and many2one field) are not ready.
The model setup sometimes misses entries in _inherit_fields and _all_columns.
This is because those dictionaries are computed from parent models which are
not guaranteed to be completely set up: sometimes a parent field is only
partially set up, and columns are missing (they are generated from fields after
their setup).
To avoid this bug, the setup has been split in three phases:
(1) determine all inherited and custom fields on models;
(2) setup fields, except for recomputation triggers, and generate columns;
(3) add recomputation triggers and complete the setup of the model.
Making these three phases explicit brings good invariants:
- when setting up a field, all models know all their fields;
- when adding recomputation triggers, you know that fields have been set up.
The field setup on models is improved: only fields are determined when building
the model's class; the final _columns is computed from the fields once they are
set up.
1. Remove the mass mailing install checkbox from marketing and sales settings
2. Show the mass mailing settings only when the module is installed
3. Remove the marketing campaign install checkbox from marketing settings
4. Move the marketing_crm module into marketing_campaign
5. Merge the *.po files from marketing_crm with marketing_campaign
a many2many field can open a pop up dialog with different views, such
as form view and list view. when the user click on the create button,
it should hide the list view and display the form view. apparently,
this behavior was hardcoded in the pop up dialog, and broken at some
point between v8 and master.
A proper fix would be to abstract the
view manager behavior as a mixin and use it for the selectcreatepopup
widget, for the one2many view manager and for the viewmanager. But this
will take too much time for now, so a quick fix will do it. (however a
task has been created)
myself.cal_client_id could be False, when not filling in the according field in the general settings screen.
Therefore, trying to strip it won't work, as boolean do not have such method.
Regression introduced during rev. faee926f1b
RPM packages did not pass the tests because the centos prompt changed
and thus did not match the regexp anymore. We now explicitely specify
the prompt in our Dockerfiles to prevent such issues.
has also been added, because the action open_website_url linked to the publish
button is not defined on res.users model (but on its inherited partner).
It now has the method that is routed on its partner.
employees. Website publishers now see all employees + a publish button, like
for other website documents. Other people see the same published employees
as before.
The URL link for employees is not a specific url for each employee but the
about us page.
Also cleaned grade form view and its inheritance.
Now the website displays partners related to all grades (website publisher) or
only published grades (other people). A publish button has been added in the
website for grades, to have the same behavior as for other website documents.
Also added basic controllers on the partner model, allowing to see the public
page of a published partner (or all partners if website manager). The template
was already existing, but the controller was missing. It has been added.
[FIX] website_customer: fix the inheritance of view as the website group has been
removed in the parent view. Also added a breadcrumb fix.
website_hr_recruitment, website_sale: add published mixin on blog / event /
track / job / product objects and update their website url and form view
according to the publish mixin/button refactoring.
and website_url fields. This will allow to remove custom code in every website
addons that redefine those two fields and the URL getter method.
The published button in backend has also been cleaned. It is now a link button
that redirects to the website_url. It does not change the publish status
anymore. Indeed it makes sense publish and unpublish website documents
directly in the website, while checking that everything is correct, instead
of doing it in the backend.
Next commits will update the Odoo addons to use this mixin and the new button
in the form view.
- removed unnecessary More menu entry to see the meetings from applicants
- small wording / display fixes on applicant form view
- applicant graph view tuning
- job form view inheritance cleaning
- labelling
- check_holidays does not raise anymore, the constraint is responsible of doing it
- cleaning of holidays status form view
- number of remaining days on an employee is now in technical feature, leave
summary exist to have statistics