These changes are made as a result of simplifying attrs and 'states' in
views. However, they should have remained in a separate commit. When
applying the script making the xml changes (used later for the migration
script), the script checked the definition of the python fields in order
to convert the information into a python expression. Therefore, this
commit is not applied when the script is applied to xml changes.
During this attribute deletion pre-existing errors were found. Part of
the code was using the boolean values of 'states' and another part of
the code was not. The behavior could therefore be different (in cases
where readonly on the field had the same value as the ballan in
'states').
Following the deletion of 'states' and without the application of the
view migration, the js tests (tower) were no longer functional. Tests
using the Form view suffered the same effect. There are few tests that
had to be adapted, including two tests in business accounting (updated
by the accounting team). A test for column_invisible did not work. Test
checking if the test system triggers an error if we try to write on an
invisible field. It turns out that Form was testing on the value of
invisible but not taking into account if the column was invisible. The
test system fix is applied separately because there were a lot of tests
that were incorrect.
Part-of: odoo/odoo#104741
RATIONALE
Simplify field management for mail / phone / sms flows. Make it working out
of the box, easier to use and tweak.
SPECIFICATIONS
Add a '_phone_format' tool method on BaseModel. It allows to format a number
either directly, either from a field available on the model. It allows to
ease number formatting. It uses available helpers to find numbers using
'_phone_get_number_fields' and '_phone_get_country_field'. With default
generic behavior this allows to simplify most calls to phone number formatting.
Having it available at BaseModel level allows to remove some custom code,
calls to phone_validation API, ...
Task-3422449 (Mail, Phone: Move and improve field helpers)
Part-of: odoo/odoo#130468
ISSUE
SMS reminders are not always correctly sent, as people fill form using local
numbers. When scheduler run the number is not always recognized to be
formatted using E164 format. We should try to normalize numbers when possible.
SPECIFICATIONS
Try a sanitize: format number based on event country (or partner if set).
If formatting it works, use the given number, otherwise use the original
number.
Do it at registration creation, as classic flow is the frontend where customers
give numbers used to create registrations. When the number is coming from the
partner through the compute, do not do anything and keep current behavior
which copies partner number if not given directly on the registration.
Add an onchange to try to format the number in the form view, like what is
done on leads. Do not automatically do it at write as it is not really
required currently from business point of view, it is more an helper for
frontend registration.
Task-3342820
closesodoo/odoo#128118
X-original-commit: 94fa8d962535a754c9fb26997a38cc8b51b8974e
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Rationale
=========
Since v8, the `display_name` field is present on all models. By default,
`display_name` uses `name_get` which has pretty much the same purpose
(return record name used by the web client). Gradually, many (backend)
developers (and the ORM: https://github.com/odoo/odoo/commit/6da1c3ac4c036eac289597602976538e243cb939)
started using `display_name` (more convenient than
`record.name_get()[0][1]`) but it still had the `name_get` override.
It becomes more complex than necessary and poeple start to misunderstand
the two (and sometimes override both, leading to inconstiencies between
`display_name`/`name_get`).
To simplify the ORM and the API, we decided to keep only one of them,
the `display_name` field:
- It is much more convenient from a backend point of view
(`record.name_get()[0][1]` vs `record.display_name`)
- It is cached during the same transaction (and invalidated if
its dependencies change)
- It can be overridden like any other compute field (override
`_compute_display_name` with any extra dependencies)
- `name_get` is replaced by `read(['display_name'])`
(API perceptive), which can actually be more efficient
(if `display_name`'s depends are correct, the ORM will only fetch the
fields it needs instead of every prefetchable field)
Changes
=======
- Deprecates `name_get` for the v17 and based the method on
`display_name` (the opposite of before)
- Converts all usage of `name_get`
- Overrides of `name_get` are now overrides of `_compute_display_name`
- For `res.partner`, rename the field store `display_name` into
`complete_name` because `display_name` context-dependent and it makes
no sense to have a compute store that is context-dependent.
- Previously, it was possible to return multiple names for the same
record with `name_get`, but it was tricky and most of the usage of
this `name_get` didn't take this into account. The only example of
this is the `name_get` of `product.product`
(now use `", ".join(<names>)`).
Part-of: odoo/odoo#122085
This commit changes the way the identification questions (name,
email, phone) are asked when registering to an event. They aren't
hardcoded anymore and can be created per event the same way other
questions can be. They can be set as mandatory or not and the order
can be changed. One can now also ask for the attendee company name.
Task-3056380
closesodoo/odoo#112164
Related: odoo/upgrade#4313
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
RATIONALE
Improve usage of composer in comment or email mode: support batch-posting in
comment, support more configuration from templates, improve global model.
SPECIFICATIONS
Support a real res_ids field on mail.compose.message model. Instead of relying
on active_ids from context, store it once for all at composer level and use
it in code. Active_ids usage is still done at default_get level, using it to
populate the field.
Improve usage of domain, renamed to res_domain to match other document related
fields naming. Add support of a res_domain_user_id field allowing to set the
user from which the domain should be evaluated.
Composer now runs on a list of IDs. Mass mail mode and comment mode are now
distinct from running on a singleton or on more records. Rendered or raw
mode is not triggered by
* mass mailing mode: always display raw mode, whatever the number of records;
* comment mode: display rendered mode when having a single record (like the
previous comment mode). Display raw mode when having either no records
either at least two records.
Task-3035101 (Mail: Support batch-posting from composer)
Part-of: odoo/odoo#99482
All emails sent from the chatter start with "Re:" followed
by the name of the record. The name of the record alone is sometimes not enough for
the followers to understand what the mail is about.
Additionally, "Re:" does not make sense when starting a conversation.
This commit gives better default subject
for event registrations and allows thread models
to override the default subject of messages.
This also removes "Re:" from default mail subjects.
Task-2833215
closesodoo/odoo#95817
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
Steps to reproduce:
1. Delete the mail.template "Event: Registration Badge".
2. Go to any event.registration record.
3. Click on Send by Mail button.
closesodoo/odoo#93090
X-original-commit: 373a838d2df05b8be9a89a933b291492ba6052f0
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
With stored computed seat attributes, the database can be flooded with update
queries for the stored values for the event (ticket) seats computations (such
as reserved, expected, and available seats).
This can especially occur when a communication is sent to many people about
an event with a registration link, many users may want to register at the same
time, possibly resulting in concurrent_update errors.
In this commit, we remove the `store=True` attribute of those fields, and
therefore remove the Reporting/Event feature depending on them and rewrite some
domain searches and _compute fields in the event and event_sale modules.
This also impacts the way constraints are enforced on the number of
registrations vs defined maximum as no stored value is directly available.
For performance reasons, all events and tickets are now shown on backend form
views, with seat availability added in their displayed name.
Misc
To avoid delaying the inevitable, the Event configurator modal/wizard now
validates event/ticket consistency at closing.
The UI of the RegistrationEditor wizard is also improved:
* A warning alert will tell users that free registrations were not confirmed
because of insufficient seat availability.
* A first step to better explain the consequences of the actions taken on the
modal was to be taken, here via the description and buttons wording.
Tests
Query counts are (indeed reduced) and updated. However, as local testing with
`test-tags=/test_event_full` ("tef_only") is currently not reliable, these
values were updated by applying the same change from the commit as the one seen
for the runbots, while a "?" is appended to show this uncertainty.
Task-2654816
See odoo/upgrade#3118
Part-of: odoo/odoo#81583
Globally ease event registrations followup by improving the related search
views and by allowing a quick access to statistics.
Specifications:
1) A stat button has been added on event that go to attendee reporting filtered
on the event
2.a) in the attendee reporting, the text search has been modified as follows:
- order: first search on event
- order + added: then search on responsible
- order + added: then search on organizer
- order: then search on participant
- then other field already present
2.b) still in the attendee reporting, filter "archived" has been moved as the
last filter
2.c) still in the attendee reporting, group by for campaign, medium and source
have been added
3) link to confirmed and expected attendee in the kanban view box now redirect
to the new stat view with the suitable filter
Technical remarks:
- view for a specific event launched from the event view uses a specific
search view which doesn't include search on event (name, organizer, ...).
Task 2761011
Part-of: odoo/odoo#84546
* = website
Change the wording of the sms reminder template to make it sound friendlier and
more complete. The sms will include the event address if it is defined.
Otherwise, it will link to the event page if website is installed.
A one line-formatted version of the venue is added to the model to be used in
the template and other places.
This required to update `event_registration.get_date_range_str` to not include
the time when describing an event happening more than a month from the current
date, which makes sense as there is no reason to specify the time only in that
case, and we add the time somewhere else when it's useful anyway.
For consistency, Wembley Stadium is updated to London timezone in the demo
data.
Task-2777183
closesodoo/odoo#85664
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The possible index names have been renamed "btree", "btree_not_null"
(instead of "not null") and "trigram" (instead of "gin").
Task 2742526
Part-of: odoo/odoo#83274
Three supported types:
- btree (default for index=True)
- btree not null (when >90% of the data are null)
- gin trigram search (for char fields)
Review of indexes on all objects.
closesodoo/odoo#83015
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
When an attendee's registration was archived, their seat was still
considered taken, which could be problematic such as in cases of
limited seat availability.
Only non-archived registrations are now counted as seats. The same
error as with regular registrations will be raised if there are not
enough seats available to un-archive a registration. These ValidationError
messages now show the name of the fully booked event.
A few python tests are included to verify the impact of (un)archiving on
seats availability for events and for event tickets.
The appearence of archived registrations was also not different in form
and kanban views, which is somewhat confusing and inconsistent with the
aspect of archived records in Odoo. Actions buttons are not available on
archived records.
Filtering in the archived records needed to be simplified from a "Custom
Filter" to a one-click feature, already available for many models.
Task-2646298
closesodoo/odoo#77715
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
In this commit we have changed some order of fields in
attendees form view, changes are listed below,
- moved `partner_id` field next to `event_ticket_id` and
made this field editable and trackable, this change had done because
currently this is the first field you see and it currently
looks like this is the person that's coming.
- moved `visitor_id` field below `mobile` field, so that even
in debug mode, Attendee Name is the "primary" field.
Apart from that right now if there are attendee data (name/email/phone)
and when we update the partner_id these attendee data will be erased
and updated as the new partner's information.
In this commit we are improving this, if there is any attendee data
it will not get erased while partner_id is updated. Attendee data
will get updated only if name/email/phone fields are empty.
TaskID-2670765
Part-of: odoo/odoo#79166
In this commit we have removed the `date_open`
field from the model `event.registration` as it
is a duplicate of the `create_date`.
TaskID-2670765
Part-of: odoo/odoo#79166
RATIONALE
Currently we can specify email used for notification layouting through context
use in mail composer. It is then propagated to message_post, stored on
mail.message and used to encapsulate emails sent based on posted messages.
SPECIFICATIONS
Get rid of context usage (``custom_layout``) and use a real field on composer
model: ``email_layout_xmlid``. Use now a default value coming from context
(default_email_layout_xmlid) instead of custom_layout.
Support old context key in composer for backward compatibility, working like
a default value for the field itself.
Task-2621326 (Mail: add 'view' button in 'light notification template')
Task-2647302 (Mail: add layout field in composer)
UPG odoo/upgrade#2829
Part-of: odoo/odoo#76418
Oversight of odoo/odoo@d9ffbe9e89 a valid template_id was incorrectly converted
into a reference field, used in event automated communication (which is not
the case when sending badge).
Task-2488019
PR odoo/odoo#68901
This commit introduces a new badge report displayed on a full A4 page.
This report is meant to be printed for the attendee and contains more
detailed information that the existing "badge report", which is only meant to
be folded and used as a badge.
We use a lot of custom layout and classes to create a "ticket-feeling" to the
report and make it look good visually.
We also introduce a new field that allows easily customizing (outside of
studio) this report by adding "extra instructions" (how to use your ticket /
directions on how to get to the event / ...).
Side note: scss disclaimer
As the reporting engine does not allow complex class/rules building, we had to
implement this nice layout using very well placed background-image and
"pixel perfect" sized elements.
LINKS
ENT PR odoo/enterprise#19349
UPG PR odoo/upgrade#2599
Task-26779
Purpose
=======
A new module "Event Social" will be added in the enterprise PR. This
new module will use a new template type, the "Social Post Template"
adding one more column in the communication tab...
We want to have only one column to select the template (Mail, SMS or
Post template) and therefor we need to use a reference field.
Technical
=========
As we can not set a domain on a reference field, we added a context key
and in the `_name_search` of the `mail/sms.template` we filter with the
domain we want if the key exists.
Links
=====
Task-2127615
See odoo/odoo/pull/46304
See odoo/enterprise/pull/7701
See odoo/upgrade/pull/848
Event users cannot unlink registrations. To help them in their daily job
we added an active field on registrations allowing to archive them
without unlinking them.
Task ID-2204364
COM odoo/odoo#57022
ENT odoo/enterprise#13984
UPG odoo/upgrade#1897
Purpose of this commit is to remove the "done" field computation. Indeed
it is based on either
* mail_sent field if scheduler is global to the event (before or after
event). This computation is light as this field changes only once
when emails are scheduled and sent;
* status of event registrations compared to all sent communication on
those registrations. This is costly as adding a new registration changes
In this commit we therefore
* rename ``done`` to ``mail_done`` to ease grep and understanding;
* remove ``mail_sent`` as it is integrated within ``done``;
* manually update ``mail_done`` when updating schedulers instead of doing
it through a compute method;
Some code cleaning is performed to make it clearer and easier to understand.
LINKS
Task ID-2414658
COM PR odoo/odoo#63093
UPG PR odoo/upgrade#2014
Due to ACLs it is currently impossible for event users to confirm a draft
registration if schedulers are involved. Indeed it implies updating the
scheduler which is not do-able for them.
In this commit we sudo the update of schedulers, as this is a technical
object and access is granted through registrations.
Related to Task ID-2414658
COM PR odoo/odoo#68158
X-original-commit: 73d09268922a7d242af85e36a3d81ed25ab4ca33
RATIONALE
Stored editable fields receive their values either from compute either from
user input. If a user input is given to create / write compute method is not
called. If multiple fields are computed through the same method giving one
field value discard call to compute method and other fields are not called.
SPECIFICATIONS
Split ``_compute_contact_info`` compute method so that partner related fields
are independent.
LINKS
COM PR #65688
Task ID-2455165
X-original-commit odoo/odoo@dfc319f584
X-original-commit: c251048cfead27d12117557fe4b6601bef39e8e1
Avoid concatenation of translated strings & raw values and/or other
translated values, and use the new _ API (by providing the formatting
values to ensure the fallback on the english terms in case of wrong
translation).
By including the expected values inside the string to translate, we
ensure that the formatted values are included at the right place in the
resulting translated text.
This also provides more information on the string to translate to
the translators, s.t. the chosen terms for the translations can be more
adapted to the translation context.
closesodoo/odoo#54635
Related: odoo/enterprise#11925
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Bug
===
Register to an event with a public user.
Sometimes an ACL error will be raised.
Technical
=========
Before flushing the environment (after the creation of the event
registration in the endpoint `registration_confirm`), the ORM will
recompute all needed stored fields. As we didn't write on some of them
(`date_closed`, `utm_campaign_id`, `utm_source_id`, `utm_medium_id`)
they are in the list `Environment::all.tocompute`. So, the ORM will recompute
the fields even if the state didn't change (this behavior can be verify
in `BaseModel::recompute`). This is done after the "create" call of the
event registration and so without the SUDO flag.
Task-2299227
closesodoo/odoo#54624
X-original-commit: 38f37cd483b7907b20171e2c44e14e69e3e00596
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Prevent to unlink tickets when having registrations by adding an ondelete
restrict attribute. Otherwise billing information may be lost.
Task ID 2244487
PR odoo/odoo#52998
FwdPort of odoo/odoo#52923
X-original-commit: 5322d76d378e4bd88a42dc0e4b01bb46c7b3546a
PURPOSE
Introduce a clearer way of handling registrations for multiple events occurring
at the same time and place by
* improve attendess kanban view;
* introducing a Registration Desk menu item;
SPECIFICATIONS
Introduce a computed "payment_status" selection field, allowing to display
status of a registration, based on its SO and ``is_paid```field. It is better
fro UX and display. It is not stored as currently stored fields are sufficient
for current requirement.
Add it to the kanban view.
Prepare barcode improvements by improving _get_registration_summary returned
data dict, adding some information to display in event_barcode. Reorganize
registrations actions, and prepare a generic one leading to attendees kanban
view for registration desk.
LINKS
Task ID #2214290
Community PR odoo/odoo#47511
Enterprise PR odoo/enterprise#9190
PURPOSE
Introduce a clearer way of handling registrations for single / multiple events
occurring at the same time and place by
* improve attendees kanban view, notably by better supporting mono and multi
event (hide unnecessary information);
* introducing a Registration Desk menu item to manage multi-event mode;
SPECIFICATIONS
Improve attendees kanban view, notably due to the following issues
* event_ticket_id as char field is hard to recognize. Notably with attendees
with same ticket directly in the kanban view;
* missing explicit icon/button of the event registration state;
Handle mono-event (coming from an event) / multi-event (global attendees
view) modes.
Replace "event_ticket_id" text by colored badge (random color on each
"event.event_ticket_id.id"). Move this field directly into event as now
tickets are supported in event, not only with event_sale.
Add button or text linked to the registration state.
Kanban card structure is therefore
-----------------------
Attendee Name
Event Name (if in multi mode)
Booked by partner_id.display_name ICON/BUTTON
Ticket in a tag format
-----------------------
Buttons and icons, if registrations is
* canceled (nothing to do in Kanban, open the form view) => Canceled text
* unconfirmed and is awaiting confirmation => Attended text
* confirmed and is awaiting attendance confirmation => Button
* done, end of the flow => Icon
Mobile specific: put button as big buttons on the right of the card, ensure
all cards are displayed using same height and display correct.
LINKS
Task ID #2214290
PR #47511
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
PURPOSE
Change seats_availability selection field into a boolean field
and rename it to seats_limited for consistency.
SPECIFICATION
Change all the tests accordingly.
Task ID : 2198660
PR : #46659
PURPOSE
Allow to use UTMs directly in event, notably to be able to sort or make
statistics on registrations.
SPECIFICATIONS
Move all UTMs fields definition to event. In base event module they are
set by hand or through links (when using mass mailing for example).Shared
links with utm bits defined in it allows to track marketing statistics
on registrations.
In event_sale registrations can be linked to a sale order. UTM information
are copied from the sale order to the registration itself. Order defined utm
always erase default one coming from event.
LINKS
Task ID 2212297
Community PR odoo/odoo#47229
Related: odoo/upgrade#913
Signed-off-by: Thibault Delavallee (tde) <tde@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
Origin is a char field holding the registration "source name". Its only use
is to copy the sale order name when registration is linked to a sale order
in event_sale. As we can filter / group / search on sale order or sale order
line directly instead of the origin there is no need to keep this char field.
If necessary to some internal reasons it can simply be added through studio.
LINKS
Task ID 2212297
Community PR odoo/odoo#47229
RATIONALE
Manual onchange is necessary because you spot an issue (or customer complains).
Automatic update through computed feild is only there to try to add missing
pieces of information but cannot decide which is the correct field value to keep.
SPECIFICATIONS
Keep an explicit onchange on partner_id. Rationale : if user explicitly
changes the partner in interface, he wants to update the whole customer
information. If partner_id is updated in code (e.g. updating your personal
information after registeration in website_event_sale) fields with a value
should not be reset as we do not know which one is the correct one.
How it should behave as following
* computed fields based on partner_id should only update missing
information. Indeed automated code cannot decide which information
is more accurate;
* interface should allow to update all customer related information
at once. We consider event users really want to update all fields
Tests are added to ensure behavior is not modified without notice.
LINKS
Task ID 2089156
Community PR odoo/odoo#42911
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: REQUIRED FIELDS
As computed fields are computed after create required attribute cannot be
respected without computing them beforehand. That is why we have some custom
code to compute required fields if not given at create and update the creation
values accordingly.
SPECIFICATIONS: MAIL SCHEDULING
Mail scheduling on event type is modified in this commit. Previously checking
the use_mail_schedule radio button had no effect on event_type_mail_ids field.
It is now reset if unchecked. It is therefore coherent with use_ticket and
event_type_ticket_ids field behavior.
LINKS
Task ID 2089156
Community PR odoo/odoo#42911
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
Co-Authored-By: Michaël Mattiello <mcm@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
- 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
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
=======
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
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
Gorash