This commit fixes a missing default_partner_id in context of 'Opportunities'
stat button on contact form. It allows to immediately link a new opportunity
to the contact we came from.
Task ID-2343221
closesodoo/odoo#58722
X-original-commit: 77d4ba222630fa0f97351186782d09d2ec59a42a
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
- Create a Contact named "Alpha"
- Create another Contact named "Mister X" with "misterx@alpha.com" as email
- Go to CRM and create an Opportunity for Mister X
- Go to Contacts and open Alpha
The Opportunities smart button shows 0, but when clicking on it,
Mister X's Opportunity is displayed.
The Opportunity smart button displays a "crm.lead" view with a filter on partner_id.
The filter applies an "ilike" with the Contact's name on several fields of "crm.lead",
including "email_from".
As Mister X's email address contains Alpha's name, its opportunity is wrongly retrieved.
opw-2320299
closesodoo/odoo#56667
X-original-commit: 547cc14d7fc4f39a00bf7a05b781c1edfa050cf6
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
Actuin `relate_partner_opportunities` and its window views is not used anymore
in codebase. It can be removed, allowing some cleaning.
closesodoo/odoo#46676
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
=========================
The goal of this task is to set up some kind of guidelines to make
kanban views consistent.
It is fine having different kanban views, but if a UI element is shared
among several kanban views, it should behave/look the same so the user
knows what to expect.
Kanban views can be split into two types:
==> 'documents' kanbans, such as res.partner, crm.lead, etc.
- those records are created/edited often, numerous
- 'opening' the card means accessing the record
==> 'dashboard' kanbans,such as stock.picking.type,account.journal, etc.
- those records are not created/edited often, there are much less numerous
- usually presented as dashboard, where 'opening' the card means
accessing a set of related 'documents' (clicking on a account.journal
to access account.move, or stock.picking.type to access stock.picking)
- configuration of the 'card record' is done through a dropdown to
access configuration
Here are some guidelines for consistency. Bear in mind that those are
not rules, but guidelines for consistency that we'd like to keep in
mind when designing.
==> 'documents' kanbans
- the record is accessed through global click
- the user avatar is at the bottom right
- the activity widget is at the bottom left (in last position if
there are other elements)
==> 'dashboard' kanbans
- the record is accessed through a 'Configuration' option in the card dropdown
- there is no global click, and therefore no focus shadow
- the dropdown icon (o_kanban_manage_toggle_button) is always visible,
with icon fa-ellipsis-v
- the listview counterpart should be presented as a dedicated
configuration menu, and shouldn't be in the 'dashboard action'
- links in the body of the card are structured as follows: link with
<count>+label, then any additional aggregated metrics (not link) to the right
example https://drive.google.com/file/d/1ZP6HDHTtC7cQ6rDWgqLoPs6U8JCeNVkW/view?usp=sharing
==> global guidelines
- the title font color is #212529, with 500 weight
- the subtitle font color is #666666, with 400 weight
- the font size is 1.083rem
- text overflow is handled through linebreak, not ellipsis
- numerical values are aligned to the right
- the kanban state widget is at the bottom right
SPECIFICATION
=================
AS per guidelines Improved follwing kanban/dashbaord view
- hr_job
- hr_department
- hr_work_entry
- hr_appraisal
- fleet_vehicle
- product_template
- sale_subscription_template
- crm_team
- res_partner
- event
- stock_picking_type
- mrp_eco_type
- maintenance_team
- quality_alert_team
- account_journal
Added the department menu on employee with default kanban view
Added sequence in hr_work_entry list view
TaskID: 2206372
Related Enterprise PR: https://github.com/odoo/enterprise/pull/10341Closes: #50536
If a view is present multiple times in the same module, the "last
instance" is going to win (by replacing any previous instance's arch
with its own).
Most cases of duplications are probably views which got moved then
either not removed (from the original location) or revived (through a
forward-port), the first instance can just be removed entirely.
For the few which seemed to be more than just trivial mistakes, merge
the two views instead.
closesodoo/odoo#44463
Related: odoo/enterprise#8107
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
When redirecting to record, the wrong 'form' view will sometimes be
loaded. A 'hack' has been done in crm_lead.py to redirect the user to
the relevant 'form' view based on the value of the 'type' field.
However, this solution is not clean as it does not solve all cases
(multiple crm.lead records loaded from the activity systray, reloading
the page after redirection, etc.)
Goal of this task is to solve those issues by merging crm.lead.form.lead and
crm.lead.form.opportunity form views. That way multi records actions will
always display the relevant information according to record type.
Note: Here some fields used as a twice in the form view just to stay
close to the current design. Still few things which are not possible
here for 'lead' and 'opportunity', that is
* A dynamic 'placeholder' on 'name' field.
* A 'domain' on 'partner_id' field.
* A 'widget' on 'probability' field.
Task 47118
closesodoo/odoo#32248
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
Fields `customer` and `supplier` on `res.partner`
are mostly used in domains of many2x fields.
Those domains can confuse end users because they don't
see the partner they are looking for; and it's not obvious why.
Some identified problems:
1. It can lead to duplicated partners: the user does not find
the partner, so he creates a new one.
2. The user imports supplier contacts in the Contacts app, so they
don't get the `supplier` flag. Then the user wants to make a purchase order,
and cannot find the new suppliers in the list
3. A user removes the customer flag on a prospect, because they don't think
it's a customer yet - except now they can't make a quote for that customer...
Specification
=============
Remove the two mentioned fields.
Since fields `customer` and `supplier` have been removed, all partners
are now shown in many2one dropdowns.
But in some cases, not all partners are relevant or some are more likely
to be relevant than others. e.g. when creating a PO, top suppliers have a
higher priority than other partners.
So, adapt the places where those fields were used with the new mechanism to
display the searched the partners, according to the number purchase/sales
orders they made.
TaskID: 2031147
Co-authored-by: Yannick Tivisse <yti@odoo.com>
Purpose
=======
While cleaning the stat buttons across all modules, we
decided to move the (un)archiving from stat button to
actions in the 'Action' dropdown.
Specification
=============
Remove the 'active' stat buttons in all views
For the model 'crm.lead'
- Rename the action menu 'Send an email' by 'Send email'.
- Remove the action menu 'Mark Late Activities as Done' and
'Mark All Activities as Done'.
- Set 'Mark as lost' menu action only for the list view.
- Remove the action menu 'Assign salesman of assigned partner'.
- Rename the action menu 'Forward to Partner' by 'Forward to partner'
and set it for both form and list view.
For the model 'res.partner', remove the actions menu 'Meetings'.
Linked to task 1984526
Related to PR #33720
Task 1843603
* src_model is redundant with binding_model_id
* multi -> binding_view_types (if empty => all views) (maybe should be
empty by default yo?)
* in convert, type => rec.get(type) but no @type possible on <act_window>...
* removed deprecated auto_refresh & auto_search (not used anywhere (?))
closesodoo/odoo#24738
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
This commit improves the CRM reporting by:
- adding new field on the report model
- providing new predefined filters for users
- renaming labels to be more precise
- reorganizing filter and group by
- remove wrong measure in report (probability and days
to close), as they were not correct when multiple
activity on a lead.
Main purpose is to ease finding usefull KPI for the
user, and make the activity reporting a bit less
confusing and limited.
It also now include all user messages (discussion
subtype) and note from activity (when marking activity
as done) in the reporting, so we can have a complete
analysis of action taken on the leads.
Task-1862209
closesodoo/odoo#27767
The '.badge' elements must now also use the 'badge-pill' class to get
the same style as before as '.badge' elements without it are meant to
replace the old 'label' component.
Purpose
=======
The Contact form is one of the most used/important view. It is quite
important to find the piece of information easily and to navigate in
a few clicks to the related views.
Specification
=============
Stat buttons
------------
- Restructure stat buttons with the following order:
Opportunities -> sales user
Meetings -> sales users
Sales -> Sales users
POS Sales -> pos users
Subscriptions -> Subscription users
Events -> event user
Tasks -> project user
TIckets -> helpdesk user
Purchases -> purchase user
Due -> billing: user
Invoiced -> billing: user
Vendor Bills -> billing: user
Customer/Vendor Partner Ledger -> accounting: billing
Analytic Accounts -> accounting: billing
Credit Cards -> sales user
Direct Debit Mandates -> accounting: billing user
Publish
- Use better/more relevant icons
- Check that the proper access rights are set
- Remove the bank accounts stat buttons and replace it by a one2many
tree on the Invoicing page.
Fields
------
Move some res.partner fields from the "Accouting" page to the
"sale & Purchase" page:
- Fiscal positions
- Payment terms
Miscellaneous
-------------
- Remove dead code.
- Display nothing instead "Please complete customer's informations and email"
on the popup when sending an email to a contact without email address.
Today, Odoo is really tricky to use without seeing the screen, it must be improved to be usable.
This PR forbid to use labels without a "for" attribute, add some title, rule and aria attributes in HTML. With that, Odoo will be fully usable with a screen reader.
* [IMP] Labels must have a for attribute. Improve accessibility.
* [IMP] Better error message when trying to read a missing cached value
* [FIX] Add some aria-label and title attributes for screen readers.
* [FIX] Template name is not included in the error message in case of SyntaxError in QWeb
* [FIX] Improve the Tour failed at step error message to be more explicit.
* [IMP] Add aria-labels
* [FIX] Add missing aria-label on failing test
* [IMP] aria-hidden means hidden. Fix all bad aria-hidden and hide aria-hidden for all.
* [IMP] Color names on kanban views and many2many tags
* [IMP] Add some checks on views for accessibility.
* [IMP] Add `alt` attribute on `img` tags.
* [IMP] Add aria-label and title on non-described icons
* [IMP] Add button role to widgets with btn class
* [IMP] Translate aria and formatted attributes.
* [IMP] Remove wrong aria-labelledby
* [IMP] Add menu role on dropdowns
* [IMP] Buttons must be focusable
* [IMP] Add aria attributes on progress bars
* [IMP] Improve accessibility of basic widgets
* [IMP] Change main layout to more semantic tags
* [IMP] Add menuitem role when missing
* [IMP] Remove wrong role='presentation'
* [IMP] Improve accessibility of tab panels
* [IMP] Add aria-invalid on invalid fields
* [IMP] Add aria-sort on ordered columns
* [IMP] Add role on alerts
* [IMP] Use dialog role, header, main and footer tags for modals
* [IMP] Add labels on o_status
* [IMP] Improve accessibility of kanban view with feeds and articles
* [IMP] Add alerts in case of new messages
* [IMP] Add widget, navigation or img role to aria-labelled items
We would like to make the "no item found" screens more appealing.
Before this commit, it shows a small help tip in the top-left
corner of the screen, just below the "Create" button.
With this commit, these help tips have been replaced by onboarding
screens, which consist of a picture and some text below, both of which
are horizontally centered.
The texts have been slightly changed, so that they are shorter and clearer.
Considered modules:
(A)
account,
account_asset,
account_budget,
account_test,
account_voucher,
analytic
(B)
barcodes,
base,
base_automation,
board
(C)
calendar,
contacts,
crm
(D)
delivery
(E)
event
(F)
fleet
(G)
gamification,
google_drive
(H)
hr,
hr_attendance,
hr_contract,
hr_expense,
hr_gamification,
hr_holidays,
hr_payroll,
hr_recruitment,
hr_timesheet
(I)
im_livechat
(L)
l10n_fr_sale_closing,
link_tracker,
lunch
(M)
mail,
maintenance,
mass_mailing,
membership,
mrp
(N)
note
(P)
payment,
point_of_sale,
post_mercury,
pos_restaurant,
product,
project,
purchase,
purchase_requisition
(R)
rating,
repair,
resource
(S)
sale,
sale_timesheet,
sales_team,
stock,
stock_account,
stock_landed_costs,
stock_picking_batch,
survey
(U)
utm
(W)
web,
website,
website_blog,
website_customer,
website_event_track,
website_forum,
website_quote,
website_sale,
website_sale_digital,
website_slides
Some view extension (in this case mainly counters on partners, like
small Sales Orders counter badges etc.) should not be visible if you
don't have the relevant rights.
Rather adding a group on the view to avoid Access
Error, than adding a try/except catching the
exception for opportunities and mettings count on
partner form view
Aurélien (avd)