Adds some python tests for the is_ongoing field and search filter.
LINKS
Task ID : 2190611
PR : #44651
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Dealing with newId is sometimes difficult.
closesodoo/odoo#46560
X-original-commit: 416d5ae6f7753c413b6981f9de3d24913943e9c2
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When being in edit mode attendees count may be reset temporarily to 0.
Indeed when user change the event_type linked to the event it triggers
the computation of seats. Among those fields seats_expected is used to
display the attendee count in event form view.
In this commit we rewrite the computation in order to work in onchange mode.
It correctly update record in cache instead of rebrowsing event in a compute
and correctly support newid by checking _origin id.
This behavior is probably present since a few versions but as it is not
critical we target the last stable-saas.
closesodoo/odoo#46444
X-original-commit: f858f0432abc97a805e24674990acac510b45e9d
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
In various views, the min width of some columns is too short for the label of
the field. This task aims at fixing this by increasing some minimal widths
and relabeling some fields.
SPECIFICATIONS
crm
* in view_crm_lead2opportunity_partner_mass, view_crm_lead2opportunity_partner
add date widget on create_date and remove the phone field in the inline
treeview of opportunity_ids;
event
* in view_event_form set width of boolean field 'done' to 70px and in
view_event_mail_tree set string of field 'mail_sent' to 'Sent'
* in view_event_form_inherit_ticket set string of fields seats_max to
'Maximum', seats_reserved to 'Reserved', seats_unconfirmed to 'Unconfirmed'
and set width '100px' in the inline treeview of event_ticket_ids;
gamification
* in challenge_line_list_view and challenge_form_view set string of field
'target_goal' to 'Target' in the tree view and inline treeview of line_ids
LINKS
Task ID 2166865
PR #43401
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Indeed this field is notably based on tickets availability. Reading tickets
products is not necessarily granted to everyone. People reading events should
be able to know if the sale is available or not independently of their access
on product model. Let us therefore use a compute sudo.
Task 2188857
PR #44545
X-original-commit: cfabf12ef888a9dac48cbb19763740e2c65225d5
In the event form view, when only community is installed, kanban state
is not on the right part of the form.
Moreover it should have a default value.
Task 2188857
PR #44545
X-original-commit: 1813f064bdcbc09131197484ed3c075dcba8bcb7
PURPOSE
Update tree view to add optional fields to make it easier to read.
SPECIFICATION
Modify the event_views files to add some fields (optional or not)
It add some more informations about the seats, the tracks and sponsors
and if the event is online or not.
LINKS
Task ID : 2192652
PR : #44938
Related: odoo/upgrade#801
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
This field is deprecated. Since its usage was to trigger a warning when
trying to confirm an event and confirming an event is not done anymore,
it has become obsolete.
SPECIFICATION
remove seats_min field and usage from event.event
remove default_registration_min field and usage from event.type
LINKS
Task ID : 2192652
PR : #44938
This commit removes the field twitter_hashtag from event and event_type.
The justification behind this change is that it has been made obsolete
by our social marketing app and our website builder.
Task ID 2191921
Community PR odoo/odoo#44715
Upgrade PR odoo/upgrade#764
Related: odoo/upgrade#764
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
RATIONALE
Mail template model holds a field telling odoo mail engine to automatically
add the current user's signature to the body. Its use depends on the use
case
* using the template in the composer on a single record: it is displayed
in the rendered template in the composer, meaning people could change it.
This behavior is interesting as it allows to see the email content;
* using the template in the composer in mass mail mode: it is not displayed
as only the raw jinja is displayed. It is therefore not obvious that it
will be appended to the body of the mail. People could add it manually and
have 2 signatures as a result;
A mechanism automatically adding a signature to sent emails when posting a
message is already implemented and is based on template existence. If a
template has been used when posting, no signature is added in sent emails.
Otherwise it is automatically added. This behavior should not change.
Behavior will therefore be
* use a template -> specify signature usage in it manually through jinja;
* do not use a template -> signature added in sent emails;
SPECIFICATIONS
Remove user_signature.
Update template body accordingly. In customer oriented templates that are using
it and do not already contain it, manually add a call to user.signature within
the jinja code. When set to False, just remove its declaration.
Quickly clean some signature integration.
LINKS
Task ID 2089252
Community PR odoo/odoo#39482
Enterprise PR odoo/enterprise#6459
Upgrade PR odoo/upgrate#761
Related: odoo/enterprise#6459
Related: odoo/upgrade#761
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Michaël Mattiello <mcm@odoo.com>
Co-authored-by: Thibault Delavallée <tde@odoo.com>
PURPOSE
When the auto confirmation flag is set on an event all registrations
must be confirmed by default.
When the auto confirmation flag isn't set the registrations will be
confirmed as soon as the related invoice is paid.
SPECIFICATION
Add a is_paid field in event.registration which will be updated in a
method as soon as the related invoice is paid. This field is used to
display a ribbon on the registration to emphasize its payment status.
LINKS
task ID : 2093336
PR : #43420
PURPOSE
Improve the integration between event and sale, by adding additional information
on both the sale order and the event registration views.
SPECIFICATIONS
- Add a stat button on the registration form linking to the related
sale order instead of a link in the form itself.
- Add a stat button on the sale order showing the registrations count
related to this sale order.
- When changing the ticket type on an attendee it displays an exception
activity on the sale order in order to warn the responsible for taking
action about it.
LINKS
task ID : 2093336
PR : #43420
PURPOSE
- In order to get an overview over events, add a graph view grouped by
event name and measure by seats available.
- Before this commit you had to install event_sale to see the popup window
in the barcode interface when scanning an attendee. With this commit you'll
see the popup even when event_sale is not installed.
SPECIFICATION
- Add the minimal information about the registration in the event module
and overrides it in the event_sale module to add the necessary informations.
That makes the window popup appear everytime when scanning an attendee.
- Add a "is_ongoing" field on event model to use it as a filter in
event_barcode.
LINKS
Task ID : 2093336
PR : #43420
Enterprise PR : odoo/enterprise#7760
Bug
===
Typo error in the name of the action.
Introduced in e2f16573d257257198b1fabb9fe5f619614fb1cf
Task 2186587
closesodoo/odoo#44333
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Event holds a description field that is not displayed nor editable in
frontend. IN this commit we display it in backend form view, allowing
to edit it.
With the upcoming facebook synchronization it allows to directly populate
it with facebook information. See Enterprise PR odoo/enterprise#8058 .
Task ID 1999230
Closes PR #44359
Related: odoo/enterprise#8058
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
This commit is part of ticket model support directly in event application.
SPECIFICATIONS
Some demo data is updated in order to be able to show directly tickets
feature in event, with some registrations already configured. Some basic
demo for questions is also added on first event demo in order to have a
complex event usable in demo mode.
LINKS
Task ID 2177281
Community PR #43488
PURPOSE
This commit is part of ticket model support directly in event application.
SPECIFICATIONS 1: remove date fields from event.type.ticket
Coming from old ticket implementation there are several unused fields on
event.type.ticket, notably dates about selling. Indeed tickets defined on
event.type are templates and should not be time bound.
Previously those fields were available on event.type tickets but not propagated
to the event tickets. Now they are not available anymore, simplifying models.
We therefore remove them from event.type.ticket model.
SPECIFICATIONS 2: propagate seats definition from ticket template to tickets
Previously to the global feature this commit is a member of, only ticket name,
product and price were copied from event.type to its events. Description has
been added in a previous commit. In this commit we also propagate maximum
seats availability.
Use case is linked to event.type defining a recurring event in a given
location. As seats availability is known it can be copied on all events
linked to this event type.
SPECIFICATIONS 3: improve naming of event tickets
Before this commit, all tickets of an event were labeled the same way
by default, using simply ``<event_name>``. This is annoying when
having several tickets as they had all the same name.
In this commit we fix that behavior by setting the name
* directly from the ticket template when tickets come from an event.type.
Configuring Standard and VIP tickets on an event type will therefore
give Standard and VIP tickets on event;
* generic 'Registration for <event_name>' when adding manually a new ticket
for an event;
LINKS
Task ID 2177281
Community PR #43488
PURPOSE
This commit is part of ticket model support directly in event application.
SPECIFICATIONS
In this commit we add a description on event.type.ticket and event.event.type
models. Its purpose is to have a description to use notably in frontend
(website_event and website_event_sale).
Currently a ticket description is available only in website_event_sale and is
the description_sale field of the ticket product. As we now have tickets
independent from products, we introduce a real description field on ticket
that is either put by hand (event), either coming from the product with
event_sale.
Field is therefore also copied from event type tickets configuration to its
event tickets.
Naming on sale order does not take into account ticket description as we
consider this fields as being used for front-end mainly. SO line descripiton
is now updated as the following
* either we have a description_sale on the product, and SO line description
is 'product.description_sale \n event.display_name';
* either not and SO line description is 'ticket.name \n event.display_name';
LINKS
Task ID 2177281
Community PR #43488
PURPOSE
Integration between event and eCommerce is required only when users handle the
entire selling process online. However users may require ticketing support
while managing payments outside of Odoo. Purpose of this commit is to support
tickets directly in event application without need of sales.
RATIONALE
Remove the need to have event_sale installed to manage basic multi ticket
event type. Integration with eCommerce is needed only when one wants to handle
the entire selling flow online, i.e. order, payment, ... Integration with
Sales is needed only when one wants to create sale orders linked to attendees.
Many event users do not need all of this. Their attendees pay through bank
transfers or they simply manage payments outside of Odoo while still
requiring tickets management.
SPECIFICATIONS
Remove the need to have event_sale installed to manage basic ticketing on
events.
Move ticket model (event.event.ticket) directly into event, copying most
fields from event_sale. Only sale specific fields and behavior should be kept
in event_sale :
* keep product_id and price information in event_sale;
* keep sales analysis in event_sale;
We also split tickets model used for event type (event.type.ticket) and
events (event.event.ticket). Indeed previously to this commit both are
modeled in the same table, with the following issues :
* tickets on templates use only a subset of fields: name, seats availability,
product, price;
* a ticket has either an event_id, either an event_type_id, and there are
constraints to try to avoid having lost tickets. This leads to a strange
model where m2o fields are required only in some cases with a dual
behavior;
* tickets are not shared between event.type and event.event. They are copied
and having a single model is therefore not necessary;
We therefore choose to have a light model for event.type.ticket. It is linked
to event.type when configuring template tickets. They are copied in the
onchange copying event template configuration to the event itself, leading
to event.event.ticket creation.
Some tests are moved / completed accordingly.
Access rights are copied from website_event_sale to website_even concerning
ticket access for public / portal. Currently they are kept as they are with
some rewording as it is not the purpose of this commit to rewrite them.
LINKS
Task ID 2177281
Community PR odoo/odoo#43488
PURPOSE
This commit is part of ticket model support directly in event application.
SPECIFICATIONS
In this commit we make a quixotic attempt to clean call chain implied by
making registrations online, either in event frontend (website_event) or
with eCommerce inclusion (website_event_sale). Purpose is to get rid of some
preparation and data management methods to handle most of the code directly
at CRUD level whenever it makes sense.
We notably
* move at create and write level support of partner_id update: updating
its name / email / phone / mobile;
* move at create and write level support of sale_order-id update: updating
event, ticket, partner;
Using that and some code cleaning some methods are removed and call chain
is a bit reduced.
LINKS
Task ID 2177281
Community PR #43488
PURPOSE
This commit is part of ticket model support directly in event application.
SPECIFICATIONS
In this commit we move menu definitions in their own file. It eases views
split and move, as otherwise there are dependencies between files that are
complicated to solve. Better to have menus defined in a main file, and updating
them at will afterwards.
We also improve menus sequences and groups, as some were missing or badly
defined.
Registration tree view is slightly updated to include phone and mobile numbers
as those are used notably for communication. They are hidden by default
like email.
Finally a small tweak of event kanban view is performed, notably to have
a better display with dependencies installed. We ensure all cards have the
same height.
LINKS
Task ID 2177281
Community PR #43488
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
Co-Authored-By: Stéphane Debauche <std@odoo.com>
As some event models (event.type and event.ticket notably) are about to
be modified let us add some tests to avoid regressions.
Security tests are also moved in their own file. Some internals tests defined
in event_sale are also moved in their own file. That way we avoid bloating
files with unrelated tests. Future commits will add tests for event and
event.type models.
LINKS
Task ID 2177281 (support tickets directly in event)
Prepares Community PR odoo/odoo#43488
Closes Community PR odoo/odoo#44066
Since 412ff994f1 seats_max field of event cannot be modified as it
is always readonly. It should instead not be readonly as we consider people
could change it whenever they want.
LINKS
Task ID 2177281 (support tickets directly in event)
Prepares Community PR odoo/odoo#43488
Closes Community PR odoo/odoo#44066
Currently when changing category of an event, its category mail scheduling
is copied onto the event even if the category does not enforce its use.
We have to check the category use_mail_schedule field before computing
the new event mail schedulers.
In this commit we also lessen default schedulers from 3 to 2 in order to
still help people using them without bloating too much event creation.
LINKS
Task ID 2177281 (support tickets directly in event)
Prepares Community PR odoo/odoo#43488
Closes Community PR odoo/odoo#44066
In this commit we prepare future event model changes by reordering removing
unnecessary parameters definitions, notably readonly set to False as it is
the default value. Those parameters notably come from 412ff994f1 .
Some reordering is also done in order to better understand future pre / post
change model organization.
LINKS
Task ID 2177281 (support tickets directly in event)
Prepares Community PR odoo/odoo#43488
Closes Community PR odoo/odoo#44066
In this commit we clean some event.type definitions. Indeed there are several
of them without any real use, demo as well as data. It is more important to
have fine-tuned demo and data than a lot of unused or generic demo.
LINKS
Task ID 2177281 (support tickets directly in event)
Prepares Community PR odoo/odoo#43488
Closes Community PR odoo/odoo#44066
Purpose
=======
Improve the attendees management: improve views, actions, (views, actions).
Specifications
==============
In order to allow state management in batch, state field is made editable in
multi edit mode of registrations. That way event managers are able to work in
batch. It required to move some code currently called in custom action-called
methods directly in write. It makes sense to consider that some required code
is called by writing on state field instead of depending on calling the right
method. Indeed there is not much "business" code to move: calling mail
schedulers on confirmation, and putting the closing date when closing.
Event and registration tree views are improved, some fields are now editable
in multi edit mode.
When a user register on a event from website, it will create a sale order and
a partner (the customer of the SO). Set automatically the partner of the
registration to the partner of the sale order.
Task ID 2119333
PR #40949
Purpose
=======
Improve design of the kanban cards in Events.
Specifications
==============
Have more useful information on the kanban record and removed redundant
information
* Display the location of the event
* Remove the duration
* Date should only be in the green block
* Use the same links as before
Task 2170831
PR #43173
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
Use _tz_get for tz-based selection fields from partner as it smartly order
available timezones.
Remove a strange "event.confirm" wizard that calls an unexisting method,
is not reachable and is actually completely unnecessary.
Reorganize ticket fields to ease future improvements and perform some
public -> private method cleaning.
Remove duplicated code in event_sale.
LINKS
Side effect of Task ID 2089156 (event onchange to compute)
Community PR odoo/odoo#43127
Enterprise PR odoo/enterprise#7656
prout
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
Currently event_count is a computed field with a shortcut in computation for
non event user. It is better to directly limit this field to the event_user
group instead.
LINKS
Side effect of Task ID 2089156 (event onchange to compute)
Community PR odoo/odoo#43127
Enterprise PR odoo/enterprise#7656
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
Clean existing tests: lessen data / variables, try to remove unnecessary
tests or merge duplicates.
Add new tests, notably event type configuration copy onto event records
is not well tested. Event computed fields are also more tested.
Some access tests are added, more a base for future addition as only a few
use cases are covered.
LINKS
Side effect of Task ID 2089156 (event onchange to compute)
Community PR odoo/odoo#43127
Enterprise PR odoo/enterprise#7656
Currently an onchange on event type copy the mail schedulers information from
event type to the event. In order to ease inheritance, some white listed
attributes are directly copied using direct getter (line[attribute], see code
for clarity). However mail and sms templates are many2one fields and the
id should be copied, not the browse record.
There is no issue when the onchange is trigered from interface because a
mapping is done. However when calling the onchange in code there is a crash
as the record is directly given to write.
closesodoo/odoo#42990
X-original-commit: 09c6747ea2de108cf512091b7837a71d4ea4662a
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The cron will move every ended events in the next "ended stage"
We inherit from `ir.autovacuum`, so the method `power_on` is called one time per day.
Task #2088538
Kanban view
===========
- add a field ``sales_total_price`` which contains the total sum of all sale order lines (care about the currency)
- this field is used in ``event_sale``
- display the number of expected and confirmed
- when clicking on these buttons, redirect to the tree view with the correct filter
- display this new field in the kanban view
- display the location instead of the country in the kanban view
Form view
=========
Change the order of the buttons in the header of the event form view
Preview Badge > Contact Attendee > Contact Speaker
Add a note field on the model `event.event`
Search
======
Remove the default filter "Upcoming/Running"
Task #2088538
Purpose
=======
Remove the state on the event and add a stage.
So, we can have more control on the event flow, and we will have less constrains.
Website event
=============
Before
------
People can register for an event if "seats are available" and if the state is "confirmed".
After
-----
People can register for an event if `event_registrations_open` is True,
- Event: seats are available and the event is not finished
- Event sale: One or more ticket has `sale_available` set to True
Task #2088538
Without demo data, for the odoo-master transifex project
closesodoo/odoo#41935
X-original-commit: dab7670b73506fb3a835695ee3bd735e0c5e5c2b
Related: odoo/enterprise#7287
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
PURPOSE
This commit 62ac23f0b9 introduced SMS capabilities on for
event.type.mail and event.mail models.
Values of event_type_mail_ids on event.type are supposed to be copied to
event_mail_ids on event.event when changing the event_type_id of an event.
There are however 2 issues with that integration:
- The 'notification_type' field was not correctly set on default
event_type_mail_ids on event.type;
- The 'notification_type' and 'sms_template' fields were not copied from
event_type_mail_ids to event_mail_ids;
LINKS
PR #39892
Task ID 2115792
closesodoo/odoo#41736
X-original-commit: 3fd66d844aa66ca8d54223071c787974e6c88c94
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Followup of a425695e
The terms were back in 12.0
Courtesy of Juan José Scarafía
closesodoo/odoo#41624
X-original-commit: 85d0c7001a997748d7691205bbb8d066597591a5
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Add a domain that limits to the answers belonging an event only on the
attendee form.
Make the width of the event_type_mail_ids 100%
Sort event.registrations by id DESC and Kanban view by name
task-2071337
closesodoo/odoo#37256
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
From now on mail.mail is considered as a technical model. Indeed people should
not really manually craft mails by hand. Instead various functional flows
should either send mails, either craft mails based on some user input.
We therefore make mail restricted to admin users. Flows creating mail.mail
are updated to use sudo, and ensure it was done in a context that makes
sense to delegate this power to the user.
Task ID 1853147
PR #32243
Patrick Hoste