This commit aims at removing unuseful help message to:
1/ reduce translators work, to focus on more useful translations
2/ not sending unuseful information in load_views
3/ reduce help message to useful messages, so that we can mark
fields having a tooltip in the future UI.
4/ some cleanup of existing messages too
The main use cases:
- REMOVED: help redundant with the field name, providing no extra info
- MOVED TO COMMENT: technical help messages, that should not be in UX
closesodoo/odoo#97279
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
Current behavior before PR: You have to find the right menu/view and then take
over the ID stored on the activity (through export) to find back the record.
This is annoying, painful and error prone.
Desired behavior after PR is merged: By adding a smartbutton the user can
quick-navigate to the related record in a second. This allows for quickly
finding and opening records which is usually handy when debugging things or
finding back related records.
Task-2868230
closesodoo/odoo#91230
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
There were inconsistencies in the calls to `_render`.
* the view context could contain information that misled developers.
Indeed, the context and value of the view are not supposed to be found
in the rendering. Thus by calling `ir.qweb` with the name of the
template, we ensure that there is no unwanted information and in
addition the cache key is that of the name of the template which saves
a query.
* the context used for rendering was modified by a method on
`ir.ui.view`, except this is not information used by this model. There
is now a `_prepare_environment` method residing on `ir.qweb`. This
method allows to modify the value dictionary as well as the context in
which the rendering will be done. This preparation of the data as well
as my security check is done only once per rendering. This also saves
some queries
* Freeze options for rendering were inconsistent. It could be that
options on which rendering depends were not part of the cache key. Thus,
depending on the user who generated the generation of the rendering
function, there was or was not information in the template. For example
for automatic branding. This is no longer possible, because it is the
context that is used. The options serving as a cache key are only
recorded for information (for the profiling system for example). A
simplification of the `ir.qweb.field` models could be made.
The report rendering and call `ir.qweb` instead of `ir.ui.view`.
Part-of: odoo/odoo#85110
Activity-level feedback method accepts attachment_ids but not its mixin-level
counterpart. This commit fixes that by adding the parameter. The activity-level
action_feedback_schedule_next method now also accepts attachments in addition
to the feedback, making the API coherent through all entry points.
At activity level ``action_done`` now goes through ``action_feedback``. This
means it now has two main methods
* ``action_feedback``;
* ``action_feedback_schedule_next``;
All methods finally end up calling ``_action_done`` and correctly propagate
feedback and attachments. We have a bit less entry points with possible API
changes.
Test mail models are updated to be able to use this small addition.
Task-2710804 (Mail: Clean MailThread API)
Part-of: odoo/odoo#86393
Activities and mailing trace are linked to documents through a model and
a many2one reference field. The latter one is required but is implemented like
an integer field, meaning writing 0 is actually a valid value for 'required'.
In this commit we add a constraint to ensure we never update activities with
a void res_id value. Same for mailing traces. This allows to remove the
required attribute on fields to avoid having redundant sql constraints.
Source: internal feedback about activities with 0 as res_id
Task-2694133
Part-of: odoo/odoo#81292
Accessing `valid_docs.ids` for each activity to check was costly, and in
my example the whole loop took 125 seconds to execute.
By turning it into a set, the same loop takes 0.2 seconds to execute.
When re-constructing the list based on ids to keep the order, using a
set is also faster, and takes another 0.2 seconds instead of 13.6.
closesodoo/odoo#79969
X-original-commit: f994db760b679c8acdaf4245315f89c1d31a9e1c
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Because activities_to_check was assigned in each loop, the result was
only containing the last chunk of 1000 records, instead of the whole
result.
This commit fixes the issue by concatenating into the list instead of
just assigning it.
X-original-commit: c06c96655b88cc4df59b8cdd5f05a2f600255c49
Part-of: odoo/odoo#79969
* = auth_signup, calendar, im_livechat, snailmail_account, survey, test_mail,
web_editor, website_crm_iap_reveal, website_livechat
The aim of this PR is to improve/fix various flaws and limitation of the current
API, to make it easier to use and more efficient.
Notification are now defined with 3 distinct parts:
- the channel determines which client(s) should receive it
- the type determines how it should be handled
- the payload determines any extra information helpful for handling it
Channel
=======
Business code
-------------
- Record channel is introduced for ease of subscribing to and sending
notifications to specific partners, channels, documents, ...
- String channel is still supported (but it is converted internally to the tuple
channel).
- Tuple channel is still supported without any change (but should be avoided
whenever possible due to its complex syntax).
The channel is no longer sent to the client. When the channel was used for
business purpose, the information it contained has been moved into either the
new type, or the payload itself.
Technical note
--------------
All channels are now internally converted to the tuple (db, ...) channel, which
is necessary for the platform code (saas/sh).
Internally, the bus.bus table is not changed, type and payload are grouped
together into what was (and still is) called message.
Type
====
Type is introduced to uniformize the way notifications are sent and handled.
All existing notifications already had some kind of manually-built type in them.
This is now officially supported at the bus API.
In client code this will allow (to be done in future commits) to register one
handler per specific type, instead of having to iterate and to filter all
received notifications on every handler.
Payload
=======
Payload (ex message) did not change, it can still be anything depending on
business needs.
Few adaptations:
- When the type was included on the payload, the type has been moved to the new
type parameter.
- When the channel was used in business code, its data has been copied into the
payload.
task-1891151
closesodoo/odoo#79201
X-original-commit: 543af27c7d6836ffac9e80ff8490b6ddbd849221
Related: odoo/enterprise#21998
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
values for next activities are currently prepared inside the `mail_activity._action_done()` method which makes inheritance very difficult. This commit delegates the value computation to a sub-method and thereby improves the extensibility of the module.
required to support changes to enterprise documents odoo/enterprise#20769
Task-2627837
closesodoo/odoo#77004
X-original-commit: a26e6e954c5e6c773f37e9239138a7b94ded821f
Related: odoo/enterprise#21079
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Reorganize code to ease future additions understanding and setting code
at the right place.
Rename some compute methods to have understandable names.
Remove dead imports.
Fix pytz.utc usage.
No functional change comes with this commit. This is only code move.
Task-2631873
PR odoo/odoo#75571
As mail grows and will continue to grow, ordering imports and having right
files naming as well as right content in them is important to understand
module organization and content.
Containing
* reorder init file to give an overview of models;
* move ResGroups override in its own file, outside of res_users file;
* split file containing MailActivity model and MailActivityMixin so that
mixin is contained in its own file, easing followup;
* split Activity and ActivityType models into two files;
No functional change comes with this commit. This is only code move.
Task-2631873
PR odoo/odoo#75571
Following the removal of read access on ir.model (odoo/odoo#69120),
the mail.activity.type model was not accessible to non-admin users due
to the res_model_id many2one field.
Before this commit, a project user could not access the Activity Type
menu.
Convert it to a selection field with the selection values being
computed in sudo.
closesodoo/odoo#74981
Related: odoo/enterprise#20214
Related: odoo/upgrade#2734
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
When sending an email on an activity or a recovery email it is not necessary
to automatically include all recipients as follower. If they perform an action
on the record they will be added as follower. Same if they reply.
Task-2612911
PR odoo/odoo#60792
Purpose of this commit is to avoid forcing mail_post_autofollow to True when
it is set to False. It eases inheritance and custom behavior.
Task-2612911
PR odoo/odoo#60792
This commit fixes the performance issue in getting statistics for
``activity_state`` (colored clock icon for overdue/today/planned) in
CRM. The query has been tested for several years on a large database
(Odoo's own production database).
Performance test on 29 K crm.lead records (activity_state):
With a filter for 10 records:
```
| measurement | before | after |
|--------------------+--------+-------|
| number of queries | 25 | 5 |
| query time, ms | 12 | 95 | (*)
| remaining time, ms | 32 | 7 |
```
All records:
```
| measurement | before | after |
|--------------------+--------+-------|
| number of queries | 1326 | 5 |
| query time, ms | 1739 | 129 |
| remaining time, ms | 47934 | 17 |
```
As we can see in the last results, the time went from almost 50 seconds
(not responsive at all) to 150 milliseconds (responsive). The time
increase in (*) may be caused by imperfect measurements, which are raw
and not averaged measures.
---
opw-2346901
task-1915411
X-original-commit: 1088e73c9a897902f9d2d70df980fe2a5ed23492
Co-authored-by: Nicolas Seinlet <nse@odoo.com>
Before this commit, suppose we have a scenario like below
Task-A:
Activity-1:
name: Email ( Today )
Assigned to: User-1
Task-B:
Activity-1:
name: Email ( Today )
assigned to: User-2
Activity-2:
name: Call ( Due in 3 Days )
assigned to: User-1
When User-1 goes through the systray 'Today' filter shortcut he gets both
Task-A and Task-B in the list instead of only Task-A. Indeed currently
activities are not filtered based on current user with its deadlines.
However purpose of systray is to indicate activities current user has to
perform instead of global activities.
After this commit activities will be filtered based on deadlines as well as the
current user. In order to achieve this behavior we needed to pass a domain like
[
('activity_ids.date_deadline','=', fields.Date.today()),
('activity_ids.user_id','=', 1)
]
And for that purpose we introduced a non-stored compute field with a search
method.
Task ID-2438822
COM PR odoo/odoo#72219
X-original-commit: f4eaf4d8fb2f97240201104dcd4fc7e2674bce02
This commit adds some tests on mailing.activity to ensure read grouping is only
possible when the user has access to the underlying document.
Task-2272475
This commit adds some tests on mailing.activity to ensure _searching is only
possible when the user has access to the underlying document.
Query count for 'test_adv_activity_mixin' had to be slightly adapted (+1) since
calling 'action_close' in turn calls 'activity_search' that calls 'search' on
mail.activity that now runs an additional query (see '_search' override
docstring).
Task-2272475
* Reorganize and reword some of the fields for the activity form type view
* The fields `force_next` from `mail.activity.type` and its related
field from `mail.activity` are removed.
Instead, a new field `chaining_type`, which is a `selection` will
improve the readability of the activity_type form. (It is made more
obvious that the user has to choose between 2 modes :
- 'Trigger Next Activity': used when the user wants to specify the type of the
next activity, which will be triggered once the current activity is done
- 'Suggest Next Activity': used when the user wants to recommend the
next activity for the user to schedule once the current activity is done
* To be consistent with this change :
- The field `default_next_type_id` is renamed `triggered_next_type_id`
- The field `next_type_ids` is renamed `suggested_next_type_ids`
* The field `default_description` is renamed `default_note` to better match the
`note` field from `mail.activity`
* About the specific case of activity_type.category = 'upload_file' :
An activity which has this type's category is automatically marked as done as soon as
the file is uploaded. This prevents the user from choosing a "next activity type".
As such, an activity_type with this category can only make use of the
chaining_type = "trigger", to be part of an automated process.
An activity_type with this chaining_type should have the
triggered_next_type_id set (usually required in the Form).
But, since it does not make sense to set suggested_next_type_ids in this case :
- chaining_type will stay hidden in the Form
- triggered_next_type_id will always be shown and is not marked as required in the Form
- if triggered_next_type_id is not set, chaining_type will be "suggest"
Task ID : 2410217
PR : https://github.com/odoo/odoo/pull/63370
UPGRADE : https://github.com/odoo/upgrade/pull/2167
In case of bad translation that doesn't contain the placeholder
Context:
A bad Japanese translation was inserted
#. module: mail
#: code:addons/mail/models/mail_thread.py:0
#, python-format
msgid "Create new %(document)s"
msgstr "新しい%(ドキュメント)を作成する"
The translation has been corrected but use the 14.0 syntax of _ method
to include placeholders and fallback on the English source term in
case of bad translation
cf odoo/odoo#52155closesodoo/odoo#65586
X-original-commit: 48cc6b1f2b3208e8affd5f6a261751fe973c2091
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
See merge commit for more details.
Note that mail.alias model will be done in a separate commit.
Task ID-2330149
COM PR odoo/odoo#61246
ENT PR odoo/enterprise#14561
Purpose
=======
Make the "activity_state" searchable on the "mail.activity" mixin.
This field is not stored as it depends on the current time.
Technical
=========
To make the search, we perform a SQL query.
The "activity_state" depends on the state of each activities on the
record. And this state also depends on the timezone of the user of
the activity. That's what made things tricky and we need to make the
conversion in SQL for performance purpose (we can not fetch all records
and compute them in python).
There's a special case, where there's less than 24 hours between the
deadline and the current time but one day of difference. In that case
the state should be "planned" and not "today". This case is handle by
the function "DATE_TRUNC" (e.g. 23h 01/01/2020 & 1h 02/02/2020).
Also for performance purpose, we compute the delay only once and we use
the function "SIGN" so we can use a switch/case instead of duplicating
3 times the expressions.
Task 2354754
closesodoo/odoo#60074
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, when we tried to launch next activity from the already
scheduled actvity's popover on chatter (activity that do have a next activity
set on it), it resulted into a traceback. This was due to a recent commit[1]
trying to set the default activity type.
This commit fixes the issue by improving method setting the default activity
type and thus allowing to schedule next activity from popover.
[1] - https://github.com/odoo/odoo/commit/9a8fdda8ab09e2a8394a2bf3bf7acbc349b112ad
Task ID-2302572
X-original-commit: e341980b191d0b044662b3de5f3bbc78cf3a0876
Currently, activities having blank summary field exported in xls or csv display
False. Instead of that, need to display the activity type like Email, To Do,
Call, Meeting, etc. as its display in the list view.
With this commit, if the activity type has summary then it will display summary
value otherwise it will display the activity type name if summary is not added.
Task : 2254851
closesodoo/odoo#58747
X-original-commit: 811edc466edbe9fc4b22e6f140cb5601612404f1
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
When more than one parameter is present in a message, it helps the
translation to use named placeholder. This way, the order can be
changed. It also helps the comprehension of the message.
PURPOSE
Currently, there is an on-change to set an activity summary to the default
summary of an activity type. This can be useful if types are properly
configured. The problem is, the activity summary will be updated even if there
isn't any default summary on the type. Meaning that it simply removing a
relevant custom summary the user might have already entered.
SPECIFICATIONS
When triggering the on-change on activity_type_id, only update the activity
summary to the default summary if there is a default summary defined on the
activity type.
LINKS
Task-2254825
PR #51373
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
This commit is a significant rewriting of client-side discuss, chatter,
chat window, and messaging menu using OWL. The behavior should be broadly
the same, with some slight functional changes here and there.
From a technical standpoint, the code of messaging is mainly organized in 2
main groups of modules:
- models, which are logical entities that depict the client-side state of
messaging as a whole.
- components, which are in charge of displaying information from models.
This refactoring also introduces new JS guidelines regarding folder structure
(/static) and naming rules for JS modules.
Community PR: https://github.com/odoo/odoo/pull/39023
Enterprise PR: https://github.com/odoo/enterprise/pull/6249
Task-1914207
This PR is a collaborative work by Alexandre, Julien, Sébastien and Xavier,
with the precious help of Lucas to speed it up towards the end.
closesodoo/odoo#39023
Related: odoo/enterprise#6249
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Co-authored-by: Alexandre Kühn <aku@odoo.com>
Co-authored-by: Julien Giannone <jgi@odoo.com>
Co-authored-by: Lucas Perais <lpe@odoo.com>
Co-authored-by: Sébastien Theys <seb@odoo.com>
Co-authored-by: Xavier Dubuc <xdu@odoo.com>
RATIONALE
Activities are a way to organize our daily pipe. Notably in a sales pipeline
salesmen may have multiple leads with activities to perform in the next few
days. We would like to be able to have a list view displaying a list of leads
with "my" deadline, and to order leads based on this field.
PURPOSE
As activities are linked to records through a one2many and as my activities
are only a subset of those activities, it is impossible to store a field
on lead model. Indeed it would depend on the current user which makes storing
it impossible.
However ordering on a column in list view asks for a stored field. As it is
not possible, this commit proposes to hijack the web client and search of lead
model in order to allow it.
SPECIFICATIONS
Introduce a activity_date_deadline_my field, computed and searchable that
behaves like activity_date_deadline. It is filtered on current user activities
instead of being global to the record activities. "My" deadline is the earliest
deadline of my activities, even in the past.
Ordering through web client calls search_read with an order parameter set.
Search_read then calls search. In this commit we therefore override search
to intercept a search without count with an order on activity_date_deadline_my.
In that case we do the search in two steps.
First step: fill with deadline-based results
* Perform a read_group on my activities to get a mapping lead_id / deadline
Remember date_deadline is required, we always have a value for it. Only
the earliest deadline per lead is kept.
* Search leads linked to those activities that also match the asked domain
and order from the original search request.
* Results of that search will be at the top of returned results. Use limit
None because we have to search all leads linked to activities as ordering
on deadline is done in post processing.
* Reorder them according to deadline asc or desc depending on original
search ordering. Finally take only a subset of those leads to fill with
results matching asked offset / limit.
Second step: fill with other results. If first step does not gives results
enough to match offset and limit parameters we fill with a search on other
leads. We keep the asked domain and ordering while filtering out already
scanned leads to keep a coherent results.
All other search and search_read are left untouched by this commit to avoid
side effects. Search_count is not affected by this commit.
As web client order availability is simply based on field being stored we
have to allow hijacking its value. A new option 'allow_order' is added that
display the order icon in list view column headers. It allows calling
search_read with an order based on the column but nothing more. Using it
on a not-stored field will give a warning log and ORM ignores it by default.
LIMITATIONS
At least following limitations apply
* search on "my activities" gives a list of ids that is used for searching
and ordering. It means that having too much activities on a given user can
result in poor performances.
-> we consider that activities assigned to a given user should be kept
under control. Leads with activities for a given user should be a small
subset of leads without activities.
* ordering on activity_date_deadline_my always put those records on the top
(deadline asc or desc) whatever the actual ordering of order items given
to search. This is done to avoid complex implementation where deadline
would be used to order records within groups ordered by another field.
-> for example: order = 'priority DESC, activity_date_deadline_my ASC'
actually behaves like 'activity_date_deadline_my ASC, priority DESC'.
WARNING
This implementation is a hack. It has been done by professionals. Do not try
to do it at home.
More seriously this is hackish and should be avoided. IN our case we consider
that the use of activities in sales pipeline is mainly driven by "my activities
deadline", which is not necessarily the case with longer processes like tasks.
Moreover user tests tend to show that this feature could be interesting. It
will improve quality of Odoo CRM and its adoption by improving its daily
use. A framework solution has to be found. Until this is done we keep this
hack and hope it is not duplicated in other applications.
LINKS
Task ID 2276011
Prepares Task ID 2243124 (My activities in CRM)
PR #52232
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Display the activity type through the icon of the widget and change the place to
display to whom the activity is assigned (if it is not assigned to the current
user).
SPECIFICATION
Display the deadline with a prefix as responsible if the activity assigned to
another user than the current one (uid).
Add a new 'activity_type_icon' field to the mail mixin to get the 'icon' of the
type (fa-phone, fa-users, etc...) and for the list_activity widget, display it
as an icon instead of the default 'fa-clock-o' icon.
LINKS
PR https://github.com/odoo/odoo/pull/52252
Task-2267579
closesodoo/odoo#52252
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
PURPOSE
Allow to know if an activity is linked to a customer or a requesting partner.
SPECIFCIATIONS
Add a partner_id field on mail.activity model. It will be used notably in
website slides to know who triggered an "request access" activity. It
can also be used in various business flows when assigned user is different
from the "source" or "requesting" partner.
LINKS
Task ID : 2127364
Community PR odoo/odoo#40708
Upgrade PR odoo/upgrade#1101
PURPOSE
After this commit it will be easier to find all the corresponding automated
activities in a model.
SPECIFICATIONS
Add an activity_search method in the mail.activity.mixin model to ease
the searching on mail.activity corresponding to the model. It is already
inlined in activity_reschedule and activity_feedback.
LINKS
Task ID : 2127364
PR : #40708
- Create a new company in Settings
- Check the created company in systray but keep the default one as selected
- Activate Leads in CRM
- Create a Lead and select an user (User A) who belongs to the default company
but not the new one as Salesperson
- Save the Lead
- In the chatter, schedule an activity with:
* Activity Type: Make Quote
* Assigned to: User A (the user assigned as Salesperson)
The following error will prompt:
"Assigned user User A has no access to the document and is not able to handle this activity."
During the rule check, the context is evaluated
(see commit: https://github.com/odoo/odoo/commit/a5b6f31cf28e5381e1c85f66730bcdb55998e643#diff-15c3e76db5d676523f482df45cf00446R54)
which raises an AccessError for "allowed_company_ids"
(see commit: https://github.com/odoo/odoo/commit/7bfcb53db37f385a99e16b47311b7c09c8da294d#diff-2c418cb78b7c562a79e7032645a537d2R599)
as the context that is used is the context of the current user and not the context of User A.
opw-2264224
closesodoo/odoo#52476
X-original-commit: b28470f2fdbe84f2444533e3936d0af98e051e90
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
purpose : Improve the efficiency of encoding a next activity by pre-filling the next activity type.
Set a value by default in the field Activity Type following this rules :
1) To do
2) first in sequence for this model
3) first in sequence with no model set
task-2177020
Closes#50550
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
Task 2195254 introduced many wonderful widgets to pimp the list view.
This task aims at implemeting them into the Services apps: project,
timesheets, helpdesk, expense, planning and field service.
Remaining days: https://drive.google.com/file/d/1o4Wn47445GxLqBkw-ifH9MgtFU_437xz/view
Avatar: https://drive.google.com/file/d/1yDwJWP0MZCUKZbqCa8hte1ziVTYRMMtb/view
Activities: https://drive.google.com/file/d/1e_rXH50eZq4zY2HOzw7_pfgiD39SoRIl/view
Field-specific decorations: https://drive.google.com/file/d/1WFnqJ-jkyDFftRHxWW4bgomoWrOpOuaY/view
More control on buttons
Specifications
==============
You will find below a list of which widgets to apply to which fields by
model. Some changes have to be done in the form/kanban views as well.
1) project.task
remaining days -> date_deadline -> list + kanban + form views
hide this field if is_closed is true
avatar -> user_id -> list view
activities -> 'next activity' field to be added -> list view
field-specific decorations
https://nimb.ws/ACewrY remove the current orange/red decorations we have
if planned_hours > 0, display the remaining_hours field in (list view):
red if progress is > 100%
orange if progress is between 80% and 100%
green if progress is <80%
display unit_amount in red if > 24:00 -> form view
2) rating.rating
display the rating in:
green = satisfied
orange = not_satisfied
red = highly_dissatisfied
list + form views
3) project.project
avatar -> user_id -> list + form views
4) account.analytic.line
avatar -> employee_id -> list view
display unit_amount in red if > 24:00 -> list + kanban + form view
https://nimb.ws/eIWa7E merge the timer and duration fields together
5) helpdesk.ticket
avatar
user_id -> list view
employee_id under timesheet_ids -> form view
remaining hours -> sla_deadline
activities -> 'next activity' field to be added -> list view
field specific decoration -> display unit_amount in red if > 24:00 -> form view
6) hr.expense
avatar -> employee_id -> list view
activities -> 'next activity' field to be added -> list view
badge -> state -> list view
draft = blue
reported = green
approved = green
done = green
refused = red
combine the unit_amount and the currency_id fields (see the total_amount field for reference) -> list view (idem for the expense_line_ids one2many on hr.expense.sheet)
display the total_amount in bold
move 'company_id' before 'amount'
7) hr.expense.sheet
avatar
employee_id -> list view
user_id -> list view
activities -> 'next activity' field to be added -> list view
badge -> state -> list view
draft = blue
submit = green
approve = green
post = green
done = green
cancel = red
display the total_amount in bold
move 'company_id' before 'amount'
8) planning.slot
avatar -> employee_id -> list view
decoration
display the allocated_percentage field in red if > 100% -> list + form view
display the forecast_hours field in red if > planned hours and if planned_hours > 0 -> form view
display the effective_hours field in red if > forecast_hours and if forecast_hours > 0 -> form view
9) misc
calendar.event -> avatar -> user_id -> form view
mail.activity.type -> combine the delay_count and delay_unit fields together -> list view
note.note -> 'next activity' field to be added -> list view
crm.lead.mining.request
combine the lead_number and lead_type fields together -> list view
display the name in bold
badge -> state
draft = blue
done = green
error = red
planning.slot.template -> display the duration field in red if it is = 0
closesodoo/odoo#51271
Taskid: 2248351
Related: odoo/enterprise#10605
Related: odoo/upgrade#1252
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
render, render_template, load, activity_schedule_with_view,
get_website_pages should all be private:
It should not be possible to render an aribtrary template only with
its name or id
Still need to render some qweb views from js so the method
render_template is kept public.
This explains why the website editor still need read access on
ir.ui.view as we want to allow any snippet to be rendered.
The note content was not sanitized against HTML content.
This is not considered as a security issue as an activity can only be
created by trusted employees, however there is no reason not to
sanitize it.
Courtesy of Lauri Vakkala, silverskin
closesodoo/odoo#48889
X-original-commit: 970b460295c3d33dbb089ef6b7224b472e6b568d
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
"Edition" is a French-English false friend word. "Edition" in English
means "version" whereas "edition" in French means "editing". This commit
updates user facing strings/documents that incorrectly use "edition" instead
of "edit" or "editing". Attempts were made to clean up English around
"edition" usage so please excuse any errors from lack of context
knowledge. Code comments and names incorrectly using "edition" were NOT
updated.
Fine tuning of 1e411e3a6d
- It moves the attachment in the message when we mark an activity as
done.
- It adds a test
OPW-2196668
closesodoo/odoo#47349
X-original-commit: 2033066426a6af6eed5f80f1bcde6e650e998f0d
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Issue
- Install CRM, Discuss
- Have 2 languages (e.g. french english)
- User 1 > French
- User 2 > English
- Create an activity as user 1 for user 2
- As user 2, check discuss > history
Notification received in french
Cause
mail_activity action_notify method uses
the context language which is the active
user language.
Solution
If user 2 has a language set, use this
language for translating body template (self)
and activity type (activity)
OPW-2205409
closesodoo/odoo#46800
X-original-commit: ccfe573b4eee82de92d130addb745f68b3fd3bd9
Signed-off-by: Jason Van Malder (jvm) <jvm@odoo.com>
Steps to reproduce:
- install crm
- go to any lead and schedule an activity in the mail thread
- select "email" as activity type and type some text in the note field
- change the activity type to "call"
Previous behavior:
The text you had in the note field is erased even if there
is nothing set as a default message
Current behavior:
the note field gets erased only if there is a default message set
for the current activity type
opw-2195368
closesodoo/odoo#45603
X-original-commit: 1445b694e6111727d93d548f2830c53180fb9aa7
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
At model level, activity_type_id is not a mandatory field on mail.activity.
Indeed required is added in views, meaning people could have activities
without type.
This make the activity views crash with `TypeError: 'bool' object is not
subscriptable` error when computing aggregated activity data. This commit
fixes that error.
Activities without type are still not displayed in the activity view as
columns are based on available activity types. It means activities without
type have no column to be displayed. As this is a corner case that should
not happen when using activities using the interface this is considered
as a limitation of current implementation.
closesodoo/odoo#42991
X-original-commit: 77f0dd8936df3dddfa3df8041d4b7f7c62595430
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce:
-install projects
-go to projects > configuration > check the sub-tasks option
-create a project with a sub-task and add an activity on the sub-task
Previous behavior:
attempting to mark an activity as done directly from the chatter
will raise an error similar to
"Records does not exist or has been deleted (Record: mail.message (x), User: y)"
Current behavior:
activity can be marked as done trough the feedback button
opw-2126704
closesodoo/odoo#42383
X-original-commit: 06d72a1ab84f3685f547c8a04a2d3e1405e5d188
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
An override of toggle_active was present to ensure that activities
would be removed before archiving records; this commit adapts this
mechanism to take custom active fields into account, since they are
now supported at ORM-level by getting the active field through the
`_active_name` model attribute instead of blindly using the `active`
hard-coded field that was used until now..
closesodoo/odoo#40109
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Fabien Pinckaers