This commit adds a condition to the algorithm that redirects the track viewers
to another talk when the one they looked at ended up.
The next talk must be still ongoing. It avoids to redirect to a talk that
started less than 10 minutes ago but that is already done.
Task ID: 2344522
closesodoo/odoo#58836
X-original-commit: e047fc2c7f5d2440adce30ce81a2c10a3b133083
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit aim to improve the algorithm to select the next talk suggestion
after a track has ended, in order to support small interact between two longer
talks.
Idea:
- all talks that begin less than 10 minutes before (all at same ordering level
whatever actual time)
- then talks beginning in a near future
Task ID: 2344522
closesodoo/odoo#58701
X-original-commit: 7f1e46331aecdaa4e08828240a495923c251c69f
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Clean organization and models linked to Event Online feature introduced in
semi stable saas-13.3 at odoo/odoo@981f95bbf4 and odoo/enterprise@14722028ae
Also clean website event menu not being available in website event but only
in website event track, which implies some extra-code to manage it.
In short: merge website_event_online in website_event, website_event_track
_(online/session) in website_event_track.
RATIONALE
_online modules have been added to extend content of website_event and
website_event_track without having any impact on those module. First step
of cleaning is to move this content directly in base module.
track_session module is mainly a rewrite of track module. Second step of
cleaning is to move its content directly in website_event_track.
SPECIFICATIONS
Move all content of website event track session to website event tracK. It
was mainly of rewriting of views and can now be safely merged into the base
track module.
Update dependencies accordingly.
LINKS
Task ID-2319779
COM odoo/odoo#56067
ENT odoo/enterprise#12520
UPG odoo/upgrade#1654
PURPOSE
Clean organization and models linked to Event Online feature introduced in
semi stable saas-13.3 at odoo/odoo@981f95bbf4 and odoo/enterprise@14722028ae
Also clean website event menu not being available in website event but only
in website event track, which implies some extra-code to manage it.
In short: merge website_event_online in website_event, website_event_track
_(online/session) in website_event_track.
RATIONALE
_online modules have been added to extend content of website_event and
website_event_track without having any impact on those module. First step
of cleaning is to move this content directly in base module.
track_session module is mainly a rewrite of track module. Second step of
cleaning is to move its content directly in website_event_track.
SPECIFICATIONS
Move remaining content of website event track online to website event track.
Agenda notably is completely replaced by the new one developed within
track_online module.
Update dependencies accordingly.
LINKS
Task ID-2319779
COM odoo/odoo#56067
ENT odoo/enterprise#12520
UPG odoo/upgrade#1654
PURPOSE
Clean organization and models linked to Event Online feature introduced in
semi stable saas-13.3 at odoo/odoo@981f95bbf4 and odoo/enterprise@14722028ae
Also clean website event menu not being available in website event but only
in website event track, which implies some extra-code to manage it.
In short: merge website_event_online in website_event, website_event_track
_(online/session) in website_event_track.
RATIONALE
_online modules have been added to extend content of website_event and
website_event_track without having any impact on those module. First step
of cleaning is to move this content directly in base module.
track_session module is mainly a rewrite of track module. Second step of
cleaning is to move its content directly in website_event_trackit.
SPECIFICATIONS
Quickly reorganize some bits of code in website_event_track module to ease
future integration of code from _online sub-modules. It also helps
understanding and finding its way through the module.
Split python files by model: notably event.track sub models inside their own
file to better follow future modifications.
Reorganize templates by main use
* _agenda: agenda view of tracks;
* _list: views of tracks, list-based;
* _page: a specific view of track, page-based;
* move side templates in side files;
* reorganize fields and add separators as this model will soon gain a lot
of fields;
* reorganize controllers to separate them by main use;
LINKS
Task ID-2319779
COM odoo/odoo#56067
ENT odoo/enterprise#12520
UPG odoo/upgrade#1654
PURPOSE
Improve and make color management coherent in event models. Notably consider
colorless tags as being used for internal management only, and not displayed
in frontend.
SPECIFICATIONS
Ensure tags without color are not displayed in frontend for both event and
track models (event main page, track display, agenda). Also ensure a default
random color is given when creating tags so that they are displayed by
default.
When a category used as a dropdown menu has no tags to display hide it in
order to have void categories in filtering section.
LINKS
Related to testing of EventOnline
Task ID-2314778
Fwd port of PR #55625
PR #55642
Purpose
=======
For a tag to be displayed on a kanban card, it needs to have a color set.
We won't be changing that behaviour, since it would mean having
two options > the color, and whether or not to show it in the kanban
The purpose of this task is to set a color on new tags to make the user
save a bit more time, set a color for him as he might not find the feature,
and make sure the tag will be on the kanban cards.
Specification
=============
For each of the following models, at creation, set a random integer between
1 and 11 in field 'color'
Models:
res.partner.category
crm.tag
project.tags
hr.applicant.category
helpdesk.tag
hr.employee.category
event.track.tag
mrp.eco.tag
repair.tags
closesodoo/odoo#49967
Taskid: 2234527
Related: odoo/enterprise#10112
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Commit 397872a07f remove most onchange in event related modules to replace
them by computed r+w stored fields. At that time copy was by default set to
False for computed fields as resulting of standard behavior.
Since 4b274d3b4101fbae154a572cdf40d23838899773 this is not True anymore as we consider those fields are
duplicable. We can therefore remove unnecessary copy=True on fields to clean
their definitions.
Task ID 2228189
Community PR odoo/odoo#48652
X-original-commit: c6b378987bd3351deba7770b51c2a5755f7ff341
* = event, website_event_track, website_sale, website_hr_recruitment,
website_livechat, website_sale, website_slides
The option to sanitize or not the forms was not available, this will
allow better flexibility on whether forms should be sanitized or not on
an HTML field.
Also we use this new param to allow forms to be added on some already
existing html fields where forms where sanitized out.
task-2209554
closesodoo/odoo#47318
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Purpose is to allow the batch create on those models that may be created
in batch, notably through import.
LINKS
Task ID 2212297
Community PR odoo/odoo#47229
PURPOSE
Try to move from onchange / default_get to stored editable computed fields.
Behavior should be the same (computed or set by user), with support of
create / write / onchange field update without additional code.
SPECIFICATIONS: GLOBAL RULES
Update classic fields updated in some cases by onchange and/or default methods
by fields with store=True, readonly=False. It means their value comes either
from manual user input, either from trigger based computation.
Remove onchange and default_get when possible, leading to an unique computation
method and clearing fields definition.
Also clean some fields definition inconsistencies, notably required fields
that should instead be correctly computed or default that have no real meaning.
SPECIFICATIONS: WEBSITE_TRACK(_PROPOSAL)
Keep an explicit onchange for tick / untick of website_track_proposal. Indeed
otherwise you have a loop of dependencies between website_track and
website_track_proposal
* untick website_track: website_track_proposal = False (done in _compute_website_track_proposal)
* tick website_track: no effect
* untick website_track_proposal: no effect
* tick website_track_proposa: website_track = True
It would be complicated to write in computed fields, as they depend on each
other, on cache and current values, ... It is therefore simpler to keep an
onchange: when ticking website_track_proposal set website_track as True in
interface.
LINKS
Task ID 2089156
Community PR odoo/odoo#42911
PURPOSE
Avoid losing contact information. Example :
I set a company that should come and speak to OXP and they have
an email address as well as a phone number set. To prepare the webpage
someone then sets the real speaker who is the person, not the company
=> Contact details are lost on the track and one needs to find
the contact in the repertory to set it back
SPECIFICATIONS
Track name, email and phone of event.track.
LINKS
TaskID 2162438
Community PR odoo/odoo#44476
Co-Authored-By: David Beguin <dbe@odoo.com>
Co-Authored-By: Quentin Mourier <qmo@odoo.com>
PURPOSE
- When creating a talk proposal, the spaces and carriage return were ignored
- Track name change from "Location" into "Room"
- Remove link between image/biography and the related partner and allow the
user to add one when submitting a track proposal.
SPECIFICATION
- Adds the plaintext2html requirement to the controller.
- Adds an input to upload an image on a track proposal.
Task ID : 2093336
PR : #43420
PURPOSE
As event will soon evolve (onchange -> compute, code improvements, addition of
new features) cleaning and improving tests is necessary to help avoid issues.
SPECIFICATIONS
As event model grow in complexity and features, it is easier to find its
way through the application with having registration model lying in its
own file to separate it from event-specific models (event.type, event.event).
Ticket (event_sale) and sponsor (website_event_track) models are also extracted
in their own file.
LINKS
LINKS
Side effect of Task ID 2089156 (event onchange to compute)
Community PR odoo/odoo#43127
Enterprise PR odoo/enterprise#7656
Creating a location without name does not make sense, it is the only
field of the model
Fixesodoo/odoo#38571
Adapt in master to make the field required at the model
closesodoo/odoo#38718
X-original-commit: 0823062efa96c316b9bca743891c8a1c701d130d
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Before this patch, the word "Partner" wasn't specific enough to make the user
know that it was referring to the speaker. This was OK in the form, bug i.e.
in the calendar view it's very confusing.
This change comes from 1e61522d19 and we revert back to Speaker labelling.
Also, in the form view, the partner field was duplicated, contributing even
more to the confusion. It probably comes from c058562d73 that duplicated the field
probably because of a bad conflict resolution.
Now partner is labelled Speaker and multi company domain is correctly taken
into account.
closesodoo/odoo#37781
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
As date is not required, trying to make a new date from it crashes. Let us
set value to False to ensure always having a value (new ORM computed yay)
and avoir crash (woop woop).
Spotted in task ID 2075183 (sms on speakers).
PR #37185
If an event track had a speaker assigned who had an email, and the
email field in the track itself was empty, Odoo was suggesting the
user to send an email to an empty recipient, making an error
Now it only suggests the email if there's one.
Fixesodoo/odoo#35941
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
When the many2xxx field relates to a model where company_id is required, set
this domain [('company_id','=',company_id.id)]
When the company_id field of the related model is not required, set this domain
['|',('company_id','=',company_id.id),('company_id','=',False)]
When setting the domain on a field which is in the treeview of a xxx2many field
evaluate against the company_id of the 'parent'.
Some constraints have been added on sereval models. Take a look at the complete
specification for more details.
TaskID: 2024446
Closes: #35266
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
The following models are already using big images, or they might need big images
in the future:
- partner
- hr employee
- shop category
- lunch product
- gamification badge and karma rank
PR: #34925
image_original => image_1920 (now resized to 1920)
image_big => image_1024
image_large => image_256
image_medium => image_128
image_small => image_64
image replaced by image_1920 (when writing) or by image_1024 (when displaying
what was previously the big size)
+ add new intermediate format:
image_512
PR: #34925
Purpose is to make field use more obvious by correctly stating in the
name it should contain an xml id to a qweb layout used for email
notifications. This renaming is propagated through various calls and
addons.
Related to task 1943901
Linked to PR #32404
Message post should always be called on a record (ensure_one). That way we
ensure posting a message is always done in a record's context with right
values computed (reply_to, followers, ...)
Message_notify can be called on record or on mail_thread and must have
partner_ids. It is based on the recently modified user_notification mechanism
and allow to notify a partner on a record or just to push him a message
(aka, not linked to a record).
Small performance improvement
* browse recipients instead of search in _notify_email_recipients;
* todo in future optimizations: mayybe be improve by searching on ids
and is_blacklist immediately;
Related to task 1943901
Linked to PR #32404
Purpose of this commit is to clean some bits of code, notably calls to
message_post/log as well as notification methods. It will ease performance
improvement work.
Small optimization: account: read content after extension check
Parameter cleaning
* use message log with kwargs instead of args;
* remove message post after hook useless parameters;
* remove _notify_email_recipients useless message parameter;
* remove message_notify useless send_after_commit parameters;
* remove message post params matching default values;
Other improvements
* remove message_post commands support for partners and channels;
* only calls message_post with ids list for channels and partners. We
don't support mix of ids and command anymore to simplify code;
* remove support of private discussion in mail.thread adding partners
as recipients, as there is no use anymore;
Related to task 1943901
Linked to PR #32404
Multi is the default api for methods, it is not necessary to explicitly
decorate methods with it, adds clutter and most people use it because
they see that the rest of the code uses it.
Done with `find . -type f -name '*.py' | xargs sed -i '/@api.multi/d'`
Purpose
=======
Some formviews are useless since there are so few relevant fields https://nimb.ws/1EdMV7
For instance, to create a new lost reason the user is forced to:
1. Hit create
2. Type in the name of the record
3. Hit save
4. Go back to the treeview
While he could simply type them away in an editable treeview.
The goal of this task is to allow for creation/edition of records in such models
directly from the treeview.
Specification
=============
Modify tree views from a given list of models for which the
treeview has to be made editable bottom.
If not specified otherwise, the content treeview should stay the same.
If a field is readonly/required/etc. in the formview, it should be in the
editable treeview as well.
Relabeling has to be done of the field itself, not in the view.
TaskID: 2026126
closesodoo/odoo#34577
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
The old tree views don't really exist anymore, this odd pseudo-flag to
dispatch between "list" and "tree" tree views has no reason to remain.
Task 1937686
closesodoo/odoo#31243
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Purpose: make some methods from mail.thread mixin private and update their
naming if necessary. Some methods prepare data for business flows and deal
with internal information. Public methods should either use of give some
access to those methods. Computation itself should be keps internal.
In this commit we put message_get_suggested_recipients as private. As it is
used in discuss JS we define a controller that controls access to this method.
It explicitly checks for related document access rule and rights before
calling the private method.
Some addons are updated accordingly to the method change.
Related to task ID 1911679
Linked to PR #29483
*: project, crm, maintenance, helpdesk,
It is useless to track fields during create since they
have no initial value and future tracking message will
show changes on tracked field.
We can log a default creation message instead
(as it is now if there is no mail_create_nolog context key)
This change will implies
- less queries when creating record
- cleaner creation messages
- less occurence of mail_create_nolog ctx key
Removing tracking at create could break the creation subtypes
mechanism (example: following task creation subtype on project)
Instead of using _track_subtype to give a subtype at create,
a new _creation_subtype method can be override. If a creation
subtype is set on a specific modlel, creation messages will be
create by message_post instead of _message_log.
We also need to adapt the message_track_post_template in order to
keep this feature whithout tracking.
Task: #1916916closesodoo/odoo#31945
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose is to clean the use of tracking parameters on fields. Parameters are
merged and is now tracking=<int> or tracking=True.
This commit is linked to task ID 1903814 and PR #28430.
Check that it makes custom binary fields into attachment as that's the
main reason for the change: when users create binary fields via Studio,
they're necessarily db-stored (as the interface doesn't allow altering
the attachment attribute and it's unclear how we'd handle users
switching it on/off every time), which significantly bloats their
database (and burns storage & backup space), especially as the primary
use case for binary fields is adding images and documents to records.
* check that binary fields are properly created as attachment=True
* add attachment=False on fields where that seems relevant (most but not
all of the fields previously using the default)
* remove occurrences of attachment=True
closesodoo/odoo#29308
This commit adapts the business code to changes introduced by
the parent commit in order to keep the same behaviour as before.
All readonly=False fields will have to be checked afterwards to confirm
that the business case requires write access to the source field.
Purpose of this commit is to give description more "business oriented"
because those descriptions appears in Odoo Studio which is supposed to be used by end users, not only by developers.
Related Task ID : 37311
Only the add_sign from notif_values is usefull for a resend. We can consider
that a mail on resend can be delete in every case, and we can find the
model_description from model since a resend can only be performed on
message linked to a model.
The other notif_values are now parameter in order to ease the understanding
of what can transit through this flow.
Task: #1860054
PR: #25622
Purpose of this commit is to enhance quality of templates proposed by Odoo
and make them use notification layout when send by emails. Those emails
are cleaner and more up to date compared to other emails.
Including
* registration and reminder templates that are send directly by email
are improved to directly include the notification layout in the body
itself;
* improve layout of badge template;
* use notification layout when sending badge;
* improve layout of track confirmation template;
* use notification layout when sending templates based on stage change;
This commit is related to task ID 51122 (and PR #24052).
Purpose of this commit is to allow to give additional values when rendering
notification emails and to make some parameters explicit.
This commit updates the _notify API. It allow to propagate a dictionary
containing values given to the rendering of the notification template.
This allow to have more complex templates and/or to control the rendering
depending on some parameters. Indeed currently only some fixed values and
values coming form the message to notify are given to the rendering
context.
First use will be soon when pushing notification emails not necessarily
linked to documents. In this process some values will be given by the caller
and not only by the message context anymore.
This commit also moves some context key used to control the notification
process directly in values given to the _notify method. It allows to make
those parameters explicit and rely less on context.
The _notify method now takes a values dictionary that may contain
* add_sign: add user signature to notification email, default is True.
It replaces the ``mail_notify_user_signature`` context key;
* mail_auto_delete: auto delete send emails, default is True. It
replaces the ``mail_auto_delete`` context key;
* other values are given to the context used to render the notification
template, allowing customization.
It allows to remove some context switch notably in the composer. A values
dictionary is computed and given to message_post and then propagated to
the notification mechanism.
Purpose
=======
Avoid having people getting some tasks lost in the "undefined" column. Because they won't understand what it means an how they achieve it.
Specification
=============
Add an "ondelete='restrict'" on the stage field definition.
Purpose of this commit is to add a new parameter to message post that
is the layout used when sending notification emails. It will soon
replace the context use of custom_layout in some case. It will also
allow to control a bit the notification process from the message_post
API in more or less planned future mail updates.
This commit also slightly changes the way notification process handles
deleted or unknown rendering templates. Before this commit any missing
custom template was replaced by the base template. A missing base
template was leading to a crash. Now it simply logs a warning and avoid
crashing.
Purpose
* move notify in message_post instead of always doing it at message
creation
Specifications
* message create should only create a message
* message post should be in charge of calling the notification process
David Beguin