With commit[1], we added `o_text_overflow` classes at several places to avoid
long names going out of the boxes. However, for the name/title fields in the
form views, we should always show the full name.
So this commit replaces `o_text_overflow` class with `text-break` from
name/title fields in the form views to display full string in the read
only mode, but also keep them from going outside of the form view.
Below are the modules affected:
- base
- coupon
- crm
- event
- mass_mailing
- mass_mailing_sms
- project
- sales_team
commit[1] - a0ebb46
task-2889845
closesodoo/odoo#96132
X-original-commit: 4a74c7af6b54bd771f50d3885813f4aae442c9e7
Related: odoo/enterprise#29552
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
In BS5 `$emphasized-link-hover-darken-percentage` was removed, so we use
the new variable but we restore some BS4 values:
- 15% as in BS4
- remove the underline on links as in BS4
Task ID: 2766483
Part-of: odoo/odoo#95450
*base, event, hr_holidays
Before this commit, `<t t-set/>` nodes declared outside the main
div of a kanban card where ignored by the kanban compiler. This
commit fixes that issue. To do so, we refactor a bit the way the
compiler and KanbanRecord handle multiple root cards (typically,
several roots with a t-if/t-elif/t-else, s.t. there's a unique
rendered root), by removing the faulty logic from the compiler
that identified card root nodes (and filtered out t-set nodes),
and introducing a div for the KanbanRecord component on which we
can set classNames, attributes and handlers.
The issue could be observed on the Apps kanban view, as it
displayed the "Install" button, whether the app was already
installed or not.
closesodoo/odoo#95211
Signed-off-by: Géry Debongnie <ged@odoo.com>
This commit makes various adapations in addons with respect to
the introduction of the owl kanban view. Mainly, some selectors
in scss and in tests needed to be adapted. Moreover, in some tests
that we haven't adapted yet, we must ensure that legacy form and
list views are still used (useLegacyViews).
It also contains some adaptations in kanban templates, e.g. the
replacement of moment by luxon, the removal of underscore...
Part-of: odoo/odoo#92475
In a search method, the error comes from the user and thus the error should be an UserError. ValueError should be used for other cases.
closesodoo/odoo#93944
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
For bugfix purposes, app administration groups have been given to
(implied by) the "Settings" group because without those rights,
opening/saving the settings crashed.
1) Do not load hidden view content
This commit uses the conditional inheritance of views
(depending on user groups) to avoid loading unnecessary view
& record content client-side.
This improves performance for admins without the specific application
admin rights, but also fixes the main bugfix problem,
caused by the webclient querying name_get for the records in relational
fields content.
Example:
sale_management adds a res.config.settings field to specify
the default sale.order.template for the current company.
If a 'Settings' user without 'sale.group_sale_manager' opens the
settings, he won't see this setting, but if a default template is
specified for the current company, the webclient will still request
the name_get of this template to the server, because the field
was present in the view, only hidden with a groups attribute.
With this commit change in sale, the field won't be in the view unless
you have the Sale manager group, avoiding the error/traceback/bug.
2) Remove implied application administration groups
Do not force the specific application groups on all 'Settings' user,
they globally do not need those rights, and if they need it, they
can add it to their account themselves.
3) Add a test to make sure settings user are able to manage settings.
4) Enforce 'settings' -> 'access rights' -> 'internal user' groups
As the previous test highlighted some 'false positives' because
it considered a settings user unable to read `crm.team`
and `stock.warehouse` records, we also took the opportunity to enforce
the fact that 'Settings' & 'Access rights' users must be internal users.
It makes no sense for a portal/public user to have access to the
settings, and didn't work anyway.
Part-of: odoo/odoo#91909
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>
As an event manager, it can be difficult to estimate how much of the revenue
was generated by the events. To give clear insights, we will add new reports
to the 'event' module.
With those new reports, the user can group the revenues by event (type),
ticket, product, etc. The user will then be able to quickly see which tickets
and events are the most profitable ones. The reports will be accessible only if
the user installed the 'sale' module.
Task-2679881
See odoo/enterprise#24472
Part-of: odoo/odoo#81583
Co-authored-by: Florian Charlier <flch@odoo.com>
Co-authored-by: Julien Banken <jbn@odoo.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
PURPOSE
This commit allows one to filter the events based on its address
LINKS
Task-2810400
closesodoo/odoo#87678
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Prior to this commit branded UI components were styled exclusively in
raw SCSS using the '$o-brand-odoo' variable.
This leaded to unnecessary code repetitions since, to achieve the same
visual result, each module defined its own classes.
Visual inconsistencies were frequent too since each module defined its
own variations for interactive states (eg :hover).
This commit injects '$o-brand-odoo' into bootstrap's default
'$theme-color' map, allowing the framework to automatically generate
odoo utility/contextual classes.
These classes can be used to handle text, backgrounds, borders and
buttons wherever needed.
Part of the overall v16 SCSS optimization/restyle, task-2704984.
task-2800721
closesodoo/odoo#87448
Related: odoo/enterprise#25700
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Remove most values uselessly specified because giving the same value as
the default one (see _DEFAULT_MANIFEST in odoo/modules/module.py)
* auto_install is Falsy by default
* author is Odoo SA by default
* summary & description are empty strings by default
* application is False by default
* test, demo, depends and data are empty lists by default
This will reduce noise/inconsistencies between manifests specifications,
simplify analysis of manifests content, ...
closesodoo/odoo#90209
Related: odoo/enterprise#26807
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
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
The split allows to:
- have one file per model and shorter files
- ease finding of views
- ease tracking of changes
Task-2761011
Part-of: odoo/odoo#84546
When saving a description the one edited doesn't appear but the one edited
previously instead. This fixes this problem.
Technical note: the default description for a new event was the rendering of
a template. That template was shared between all the events and overridden each
time.
The solution was to strip the identity of the template while rendering it
making it a constant and preventing it from being shared between events.
This could be done by setting rendering_bundle to True in the rendering context
(unfortunately, t-ignore is not a legitimate attributes of template tag).
Note that the same fix [1] was done on `website_hr_recruitment`.
[1]: https://github.com/odoo/odoo/commit/f1ee633f26a78636fede3e2b600c801b5f474a50
Task-2781443
closesodoo/odoo#89520
X-original-commit: 5e8be9024b8fd1cdd7caf3cb711861a4a7bee2c8
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
* = 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>
Cleanup all the places where an hour or a datetime is been used
to display with the date the corresponding timezone.
The goal is to know the timezone used where a datetime is displayed
on the event pages.
task-2458013
COM PR: odoo#78049
Part-of: odoo/odoo#78049
The field prefetching mechanism was poorly customizable. Before this,
we could only tell if a field was prefetched with other fields or not at
all. We have no way to inform the framework, like: "When I need data of
that field, prefetch these other fields, which are likely be used in the
same transaction".
From now on, the `prefetch` attribute is used as a grouping key for
prefetching fields. When a field is fetched, all the fields with the
same value for `prefetch` are taken for prefetching.
For example, consider a small set of fields that are rarely used, except
for one flow A using them. You want to prefetch those fields only in
the flow A, and you want to fetch them in a single query. With the new
feature, simply set `prefetch=A` for some string `A` on those fields,
and they will be grouped for prefetching.
closesodoo/odoo#85220
Signed-off-by: Rémy Voet <ryv@odoo.com>
The field prefetching mechanism was poorly customizable. Before this,
we could only tell if a field was prefetched with other fields or not at
all. We have no way to inform the framework, like: "When I need data of
that field, prefetch these other fields, which are likely be used in the
same transaction".
From now on, the `prefetch` attribute is used as a grouping key for
prefetching fields. When a field is fetched, all the fields with the
same value for `prefetch` are taken for prefetching.
For example, consider a small set of fields that are rarely used, except
for one flow A using them. You want to prefetch those fields only in
the flow A, and you want to fetch them in a single query. With the new
feature, simply set `prefetch=A` for some string `A` on those fields,
and they will be grouped for prefetching.
Part-of: odoo/odoo#83818
Remove `prefetch=True` on fields `legend_blocked`, `legend_done` and
`legend_normal`, because they aren't used a lot and translated fields
have a big cost to fetch (one extra LEFT JOIN by translated field).
Part-of: odoo/odoo#83818
The default group by registration week has been removed in the attendee view because:
- it makes the view impossible to use on mobile (too many columns)
- it makes the navigation on desktop a bit tricky
This reverts a change introduced in odoo/odoo@4bed87d.
Task 2761011
closesodoo/odoo#85113
X-original-commit: 7ebc86fd9202a0023513a2d4535f93a2d3914c1d
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Before this commit the tags were ordered only by their own sequence
making the display quite random when several tags had the same
sequence but belonged to different categories.
After this commit the tags are ordered by their category sequence
followed by their own sequence.
LINKS
Task-2737156
Closes: odoo/odoo#83082
Reduces load_menus answer size by 32% (between 20kb and 200kb savings
for the initial loading of the backend, depending on the number of apps
installed). Support for SVG icons in the web client for menus/apps.
Reduced PNG icons for apps list (8 bits PNG instead of 24 as our icons
don't need more colors as they are flat designs)
closesodoo/odoo#84280
Related: odoo/enterprise#24200
Signed-off-by: Fabien Pinckaers <fp@odoo.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
Issue
-----
Via the field prefetch mechanism, when we need a value of one field
(not in cache of course), the ORM will prefetch all fields
(which has the attribute to `prefetch=True`, the default value of this
attribute is `True`) for all record ids in `_prefetch_ids`.
Then, for each translate fields (where translate is not a callable)
the ORM need to make a `LEFT JOIN` on the `ir_translation` to fetch the
translated value. For big model, it leads to a simple `SELECT` with
several `LEFT JOIN` on ir_translation but each LEFT JOIN have a cost
in the planner time (a small cost in the execution time) of PostgreSQL.
By example, for `product.template` (stock/sale/purchase installed),
there are 6 LEFT JOIN to get all translated fields (5 of this
fields are rarely used).
Proposed solution
-----------------
Deactivate the prefetch by default for all translate fields expect if
this field is the `_rec_name` of the model (which is more likely to
be used).
In the example on the `product.template`:
Without prefetching the translated fields, there is only one LEFT JOIN
(the name, which is translated but is the `_rec_name` of the model).
With the 6 translated fields to fetch, the
query takes 5 ms to plan and 2 ms to execute VS with 1 translate field,
it 1 ms to plan and 1.5 ms to execute.
Side change note
----------------
- All translate of fields of `website.seo.metadata` should be prefetch
to avoid lot of website errors (it is because, website put in cache data
in sudo before reading it without sudo)
- `description` (`mail.message.subtype`), `subject` (`mail.template`),
`body_html` (`mail.template`) should be prefetch to avoid lot of extra
query from mail module.
- `vat_label` (`res.country`) should be prefetch to avoid a extra query
for each website page.
- Increase some queryCount (when it is legit, due to `subtitle` of
`blog_post` or `description` of `event.type.ticket`, etc)
task-2738029
closesodoo/odoo#82896
Signed-off-by: Raphael Collet <rco@odoo.com>
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>
Purpose is to have a common event class for users and useful stuff (customers,
products, ...) but lessen usage of common test data through sub modules.
Indeed having a "global event type" test data updated in various addons is
actually complicated to maintain.
Sub add-ons are updated to use mainly the ``EventCase`` test class holding
users and side data. Data specific to those modules (event type with some
specific configuration notably) is created and used in tests in the given
module only, and not through generic event_type_complex and event_0 test
data anymore.
With this commit tests are more localized to their add-on and modifying data
in a given add-on has less chances to have unwanted side effect in other event
submodules unit tests.
Task-2703285 (Event performance improvements)
Task-2703289 (Event testing and coverage)
Part-of: odoo/odoo#81068
On event model, seats_limited and date_tz are required but are editable stored
fields. An override of create has been added to ensure they have a value as
compute are called after creation which leads to required not being satisfied.
Now that precompute [1] is available this code can be safely replaced.
Performance tests (not yet merged [2]) indicate this has no impact on queries.
What was done manually before this commit is now done directly by the ORM.
[1] odoo/odoo@d04a5b5c8c
[2] odoo/odoo#81068
Task-2702872 (Event precompute)
closesodoo/odoo#80672
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
In this commit we have changed the view sequence of attendees
list view opened through registration desk (`Select Attendee`
button) because registration is more likely to be used on a phone
or laptop at the entrance to register attendances. So we
need to show the kanban instead of list view.
For that we have created new action
`event_registration_action_kanban` and changed the sequence
as kanban first.
TaskID-2670765
Part-of: odoo/odoo#79166
In this commit we have improved some attendee reporting
views, changes are listed below,
- changed the sequence of view, after this commit if we
opens attendees reporting instead of displaying the
stern looking pivot table it will display the graph view.
- added default groupby `state`, `create_date`(day), `event_id`.
- added a new filter `filter_last_month_creation` and made it default.
TaskID-2670765
Part-of: odoo/odoo#79166
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 improved the attendees list
view, changes done are listed below,
- We have changed the cancel button
color to red in attendees list view.
- We have added badge widget for the
state field in attendees list view, the following
states uses these colors,
- draft - blue
- cancel - grey
- open - blue
- done - green
- We have added a `activity_ids` before the field `state`
field in attendees list view.
- We have added the field `registration_answer_ids` with
`many2many_tags` and default hide in attendees list view
just before the status field.
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
Right now, when we opens attendees from an event (stat button or kanban button)
it first displays the kanban view.
In this commit we have changed the sequence of the view and added groupby
create_date (week), after this commit if the attendees opened from stat button
or kanban button it will display the list view with the groupby
create_date (week) before the kanban view, the purpose is that this is not the
path to register or confirm attendance, you just want to keep an eye on how well
your event is filling up and need an overview.
TaskID-2670765
Part-of: odoo/odoo#79166
MAHAMADASIF ANSARI