The next action date (date_action) should be red if in the past, not if the
deadline date is in the past.
Introduced at 9f68a37
Courtesy of @sve-odoo 🎅
Accessing the phonecall and the lead do not require the same permissions so
should not be computed in the same method.
The effect of the multi was already lost as the phonecall_count was already
computed in another loop.
Add the phonecall_count button in a second view to make the computation only if
the user has the requried access rights.
Fixes#2458
The onchange on partner field must not fill the company name if
the partner is not a company or not in a company. If the partner
is not a company, the contact name field must be filled with the
partner name.
opw:644878
During tests, some creation of user records would unnecessarily trigger
password reset or set a password, both of which would trigger password
hashing which takes some time (for good reasons).
Fix by:
* passing no_reset_password in YAML tests and some Python tests still
missing it (a number of Python tests already used it)
* removing passwords from YAML records as they're never necessary, the
test user records are not expected to ever log in
The commit 3269ad8f get back the behaviour of 7.0 (which changed in
october 2014) that when a field is overrided via the old api, attributes
of a previous definition of the field are lost.
This fix corrects the case when this behaviour might have had an effect
so specified attributes overrided don't get lost.
related to opw-639712
When a logged call is created from the tree view, the mobile phone of the
partner is not filled in automatically, while it is in the form view.
opw-640549
When an opportunity has a 100% probability, it is regarded
as won. When the opportunity is regarded as done,
there is no more use to show the mark won/lost button.
opw-634420
When opening the list of meetings from an opportunity, show only the meetings
linked to the current opportunity.
Use search_default_ to be able to remove the filter if not needed.
Remove context on meeting button as it's ignored in action_makeMeeting (and
there is no field attendee_id linked to a crm.lead anyway)
opw 614039
Before this commit, it was only visible by the admin user.
I used the crm.phonecall.report rules as an example, but I don't
think either of those or the opportunities ones are actually
used in the case of group_sale_salesman, because the submenu
Sales of the Reporting menu is only visible to the Sale Manager.
Fixes opw 615048.
When converting a lead to an opportunity, there is a difference in
context than when going to an opportunity via the interface.
This leads to a difference when displaying a kanban view.
This commit adds what is needed in the context.
opw-632640
When going to logged calls through opportunities,
and no logged calls were listed,
the mail alias of opportunities was displayed
within the placeholder help message,
wrongly, as we were in the logged calls list.
This was due to a context propagation, due
to have defined empty_list_help_* keys within
window actions. It was the case in several
modules.
Besides, we do not find the usefulness of the
custom_context passed to the get_empty_list_help
method: indeed, none of the methods get_empty_list_help
overriden in modules need any other keys than
'default_type', which do not require an evaluated
context.
We therefore remove the whole code regarding this
custom_context, and we therefore get rid of this
useless context evaluation thing within one of
the most accessed method of the web client.
opw-630673
This wasn't anymore possible to open the Lead/opp
form of a planned call if it was of type opp.
Regression introduced during rev. 81f56c9eda
opw-631807
After commit 0ed63d73a6,
the hack used to detect fields.function is not supported
anymore. Using `isinstance` is safer and cleaner anyway
(performance is not a concern here).
When setting a partner on the lead,
the on_change_partner method retrieves
the various partner field values.
title & function fields were omitted, without obvious reasons
opw-629374
Closes#5388
The creation of a country is not something to create at flight !
The impact could be bigger that what people was expected (no accounting configured, ...).
The bad manipulation is more often the responsible, eg 'Belgium ' was creating a new country with a trailing whitespace, while the user didn't see the difference and use both country withtout making the diff.
- When the partner is a company,
the opportunity count should counts the opportunities
of this company and all its contacts
- When the partner is not a company,
the opportunity count should only counts the opportunities
of this lonely partner.
opw-626609
When converting a lead to an opportunity, and choosing the option "link to an existing customer", the resulting opp wasn't actually linked to the ccustomer.
Before, all crm.lead of the partner were counted, whatever it was a lead or an opportunity, but the button opens the opportunity tree, which has a domain type = opportunity. So leads were not displayed, and the count was therefore misleading.
Besides, the button is called "Opportunities", and it was misleading to count leads for a button with such a name
on_change_user was used to assign the first team in which the user is a member to the lead
When the user does not use the multi sales team, it therefore set a default sales team, but invisible to the user.
Stages displayed in the kanban view are the lead sales team stages. In a non sales team env, only stages with no stages are displayed for new leads
If you added a new stage, in the kanban view, the stage is not assigned to a team
Same problem as before: filters do not compose properly with the implicit
'&', and they are filtering on the wrong model (should filter on probability
in the crm.case.stage model and not on the crm.opportunity.report)
There was two problems:
* it was filtering on the probability of the opportunity, not on the
probability of the stage
* the filters were not prefixed with '&', which means that they gave
weird results when combined in the searchview (in a filter group, filters
are combined with '|', but it breaks when the filters are defined by
an implicit '&')
The old-api model._all_columns contains information about model._columns and
inherited columns. This dictionary is missing new-api computed non-stored
fields, and the new field objects provide a more readable api...
This commit contains the following changes:
- adapt several methods of BaseModel to use fields instead of columns and
_all_columns
- copy all semantic-free attributes of related fields from their source
- add attribute 'group_operator' on integer and float fields
- base, base_action_rule, crm, edi, hr, mail, mass_mailing, pad,
payment_acquirer, share, website, website_crm, website_mail: simply use
_fields instead of _all_columns
- base, decimal_precision, website: adapt qweb rendering methods to use fields
instead of columns
When opening a lead/opportunity from the phonecalls view, we did not open the correct view (always the lead).
This will use the type of the crm.lead to determine which view should be used, opw 608493.
As for the _update_foreign_keys, the _update_reference_fields method may raise an unique constraint when merging two partners.
In such case, the new record is not relevant and can be removed.
When trying to merge partners, an sql error may be violated (e.g. unique constraints).
In this case, catch the error and delete the problematic record as it will no longer be relevant with the old partner and left unconsistant data in the database.
Bug was that when you click on meeting button from a res_partner form (Customers in menu), the button overwrites the context to use the active partner as a default in the calendar meeting. By consequence, the context overwritte the default partner who are the creator. Now the context could be removed from action and that is in get_default for partner_ids (from model calendar_event) that we add the creator AND the active_id if from a model res_partner.
Sometimes, when you send an email in the chatter, a pop-up is displayed to fill the partner details
This case happens when the email address you send the email is not associated to an existing partner
In such cases, in lead, we use the company name and contact name to fill the partner name
* remove old 'day', 'month', 'field' and replace them by the actual
date/datetime field
* remove weird cast to char when creating the view to prevent crash
when grouping on them
* remove duplicates (such as 'creation_date' and 'create_date')
* fix typing errors (field type date defined as a datetime in the
postgres view)
* fix search view definition
opening_date and date_closed were cast to char but are supposed to be
dates. When you try to group crm_lead_report by one of them, postgres
was not happy. Now, it properly tells postgres that they are of type
date.
This was added in master-apiculture at f1f16a8 to
permit special function fields that return
structured JSON-like data.
This is unnecessary and caused typing problems, for
example for the type field of ir.model.fields, or
when you decide to store them.
It is simpler to explicitly declare these fields
as fields.Char and have them serialize their results
to JSON strings, or to declate them as fields.Binary
and return any opaque data they want.
crm claims and helpdesk reports should be in Sales Report menu, not in project
The sales report menu is now defined in sales_team, which is a common dependance between crm and sales, instead of redefining this menu in each modules
Rebranding has been done in:
- data/demo files
- html templates
- help notices
- comments
- logger messages
- and other various messages
(Commit taken from odoo-dev:8.0-improve-openerp-odoo-rlu at rev 7deaa08)
Closes#1260
A squashed merge is required as the conversion of the apiculture branch from
bzr to git was not correctly done. The git history contains irrelevant blobs
and commits. This branch brings a lot of changes and fixes, too many to list
exhaustively.
- New orm api, objects are now used instead of ids
- Environements to encapsulates cr uid context while maintaining backward compatibility
- Field compute attribute is a new object oriented way to define function fields
- Shared browse record cache
- New onchange protocol
- Optional copy flag on fields
- Documentation update
- Dead code cleanup
- Lots of fixes
[MERGP] Inline Searchview
This task split the searchview in two parts: SearchView and SearchViewDrawer. The drawer is displayed inside the main view and the searchview stays in place. It also changes the scrolling behavior of the web client: the main view area can scroll without affecting the UI (so the various menus stays in place)
Because of this, other large changes have been made:
the drawer has been redesigned,
the Custom Filter widget has been split in two (Custom Report and SaveCurrentFilter),
the main view is now scrollable, so the UI stays in place and only the view can change
The text 'Group By...' has been changed into 'Group By' (most addons had to be modified)
bootstrap classes are used when it makes sense (for example, badge)
the left menu is also scrollable (separately from the main view)
It is likely that some stupid bugs have been introduced. Please don't hurt me.
Odoo Translation Bot
Martin Trigaux
Christophe Simonis
Jusab Sida
Goffin Simon
Xavier Morel
Nicolas Lempereur
Nicolas Martinelli
Olivier Dony
Denis Ledoux
David Monjoie
Akash Balar
Rucha Dave
Romain Deheele
Jeremy Kersten
Aaron Bohy
Géry Debongnie
Raphael Collet
Yajo
Simon Lejeune
Martin Trigaux
Ravi Gohil
Antony Lesuisse
Thibault Delavallée
Fabien Pinckaers
qdc
Jérome Maes
rlu-odoo
Christophe Matthieu
rba-odoo
Darshan Kalola
Jaydeep Barot
Fabien Meghazi