This merge commit has five sub-sections:
1. Rename 'slide_type' and 'datas' fields
To 'slide_category' and 'binary_content', in order to ease the following
changes.
See underlying commits for detailed information about those points.
2. Completely refactor the way we handle external content in the course slides.
This includes both technical (new fields, ...) and functional (forms) changes.
With these changes, we aim to make it much clearer for the end user on how to
introduce new content to its course, both for local files and external links.
3. Introduce support for Vimeo
Vimeo is a platform for professionals that manage video content, similarly to
YouTube.
The changes include allowing to introduce Vimeo links in your slides, correctly
embed the video, automatically set it as completed in the last 30 seconds,
fetch video metadata to autocomplete fields when URL is input, ...
4. Slightly improve e-learning views
See underlying commits for detailed information about those points.
5. Rename 'webpage' to 'article'
Indeed, 'webpage' was confusing because it was leading you to believe that you
would have to link external content from another website.
See underlying commits for detailed information about those points.
LINKS
Task-2510174
UPG PR odoo/upgrade#2498closesodoo/odoo#71477
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit simply renames the 'webpage' slide_category into 'article'.
Indeed, 'webpage' was confusing because it was leading you to believe that you
would have to link external content from another website.
While this slide_category instead lets you build an 'article' with content by
using our website builder.
The changes here are just renaming the slide_category and the labels, there
should not be any functional change.
Task-2510174
Part-of: odoo/odoo#71477
PURPOSE
This commit adds some small UI improvements to the e-learning views.
All those small changes are meant to improve the general user experience when
adding content to a course.
DETAILED SPECS
- Change some placeholders / labels
- Inform the end-user that he can edit his 'webpage' slide using the editor
- Inform the end-user that he can add questions to his 'quiz' slide using the
'Quiz' tab in the backend form view
- Do not update from slide metadata if field value is already set
- Do not allow previews for certifications
- "Allow Download" of slide content is now False by default
As it was nice to have for "Documentation" courses but does not really make
sense for "Training" ones.
- Having a duplicate video id is now informative on the frontend and not
blocking as before (it was allowed in the backend form anyway).
- Show the video title in the frontend preview
Task-2510174
Part-of: odoo/odoo#71477
This commit adds support for the Vimeo provider in the e-learning platform.
This includes managing Vimeo video links and showing the Vimeo embedded player
in the fullscreen and non-fullscreen viewers.
But also managing video events to:
- automatically set the slide as completed when the video reaches the last 30
seconds
- go to the next slide when the video ends (if there is one)
Task-2510174
Part-of: odoo/odoo#71477
PURPOSE
Globally refactor the way we handle external content (YouTube videos,
Google Drive documents, ...) in the course slides.
This includes both technical changes (new computed fields, rename, ...) as well
as visual changes on the form views that allow introducing new content, both in
the backend (slide.slide form view) and in the frontend (course main website
page).
SPECS
TECHNICAL REFACTOR
1. Rework the "url" field
This field was used without any distinction for videos, regular documents and
images, leading to a big confusion both technically and visually.
The urls are now split in separate fields (video_url, document_google_url and
image_google_url), based on the type of slide.
Those fields are implemented as 'related' to the stored 'url' field to avoid
extra storage.
This change globally increases the readability and usability in the code, and
also allows for clear labels on the various views.
1b. Rework the "binary_content" field
The same way as for the 'url' field, the 'binary_content' field has been split
into 2 related fields ('document_binary_content' and 'image_binary_content').
This allows for more readability and also helps in the form view to limit the
file selection to the supported file types.
2. Remove the "document_id" stored field
This field did not have to be stored since it can "easily" be inferred from the
video/document URL with some regex work.
3. Remove the "mime_type" field
This field's value was only determined by an external call to the Google Drive
API. It was inconsistent because not set for manually uploaded document and was
used for some strange checks that seemed to work but did not make much sense.
(e.g: used to make the difference between a Google Drive video and a YouTube
video??).
It has been replaced by a "document_type" field, which is always 'pdf' for
local files (only type we support) and inferred from the mimeType returned by
Google Drive metadata for external documents.
This allows, for instance, to show pretty icons next to every slide based on
their type, "sheet" files (Excel, Google Sheet, ...) share the same icons, the
same principle is applied to "doc" files (Word, OpenOffice, Google Doc, ...)
and finally "slides" files (PowerPoint, Google Slides, ...).
4. Introduce several computed fields
Such as:
- video_source_type
- youtube_id
- google_drive_id
These fields are mostly inferred from the slide type and the related URL.
They are used to make clear checks in the code and ease readability, for
example when constructing the slide "embed code" to insert it in the frontend
full screen viewer.
5. Remove the "presentation" slide_type
The slide type "presentation" was some kind of very confusing type between
image and pdf. It was mostly relying on the fact that the content had a bigger
width than height ('landscape' display).
This lead to a lot of confusion both in the code base and in the various forms
allowing to introduce new content ("what should I choose? document or
presentation?").
In order to simplify everything, we completely removed the slide type
"presentation" and converted all the data that had this type and the various
code checks to the type "document" instead.
Meaning that we end up with the following slide types:
- Infographic - for images, local files + external links
- Web Page - local input only
- Document local files + external links
- Video - external only, YouTube or Google Drive links
- Quiz
FUNCTIONAL
Following the technical changes here above, we can improve the form view of the
slide.slide model as well as the website form that allows adding new content.
1. Slide form view
To make it clear where the source of the document comes from, we introduced a
"source_type" field that is either "local_file", used when uploading a file
from your computer, or "external", used when linking content from Google Drive.
The source_type selection appears when adding content of type "document" or
"infographic" and conditions the display of the file upload button or the
document_url field.
2. Adding content from the website
When adding content from the website, the user is now invited to select from
ALL the available slide type, meaning we added "Infographic" to the selection.
Before this change, if you wanted to link an image, you had to select the type
"presentation" (that has a PDF file as icon...) and then input an image file.
The JS then processed the file type to determine the slide type.
As this was slightly confusing for the end user, we decided to use the same
approach as the form view, meaning you FIRST select the type of slide you want
and THEN input the content as a local file or external link.
Since we now handle all types of documents when using an external Google Drive
link, the various screen and text helpers have been reworked accordingly.
3. Handle more types of slides with the new "slide_type" field
This commit also introduces a new "slide_type" field.
(Don't get confused, the previous "slide_type" field has been renamed to
"slide_category" in an earlier rename commit).
This slide_type is a refined slide_category:
- Videos are split into 'youtube_video' and 'google_drive_video'
- Documents are refined based on the file mime_type if it's external content
For example, if you link a Excel file, the slide_type will be 'sheet'.
If you link a Google Doc, the slide_type will be 'doc'
etc...
(Local documents are only PDFs since it's the only type we support for now)
This small change allows to include minor nice details into views, such as a
refined icon for each slide_type on the website.
LINKS
Task-2510174
UPG PR odoo/upgrade#2498
Part-of: odoo/odoo#71477
This commit simply applies the following renames in the slide.slide model:
- 'datas' is renamed into 'binary_content'
- 'slide_type' is renamed into 'slide_category'
This changes intend to ease the next bug refactoring of the website_slide
module content management.
There should be no functional changes applied in this commit.
Task-2510174
Part-of: odoo/odoo#71477
commit af13e76629
reworked delivery split to add interwarehouse addresses but also
removed the address in a usual case.
opw-2701998
closesodoo/odoo#80609
X-original-commit: 9b9c4a3433d2a052e70e434b11817b791f38e508
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Current behavior :
When installing l10n_de_pos_cert on runbot module you couldn't start a PoS session
Steps to reproduce :
Duplicate runbot database
Install l10n_de_pos_cert
Try to start a PoS session in a german store
opw-2691615
closesodoo/odoo#80608
X-original-commit: 467708cbedfb2b8146c653afc06625dc4af7e893
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Clean the code for onchange method with putaway rule applied, merge
them into one onchange method.
Task-2614519
closesodoo/odoo#80519
X-original-commit: 5f562895c4d2f9beac7e0458fcee493b0141f1af
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Yuchen Huang (yhu) <yhu@odoo.com>
When applying putaway rules, the qty of all existing assigned SM lines are
summed to calculate the incoming qty of the product to determine if the
capacity has been or will be met. When a SM - that a putaway rule will apply
to - is created, then it will have its SM lines included in this calculation when
it shouldn't. In this case, we need to ignore the qty of those lines
Task-2614519
X-original-commit: 14738c7e5ecfba81e7ccbd401e1204d3bac960aa
Part-of: odoo/odoo#80519
Now when apply putaway rule on a package with package type, we calculate
the weight of the package according to the product in that package
instead of using the max weight of the package type.
Task-2614519
X-original-commit: 0281ebec36dbb9effd3d2913c0d38c88f9f19920
Part-of: odoo/odoo#80519
Package won't have a company_id untill the move is validated.
Previously, the package_type_id on package has the check_company to be
true. This forbiden any package type with company_id to be used on a not
validated package. In this commit, we remove check_company to avoid
this.
Task-2614519
X-original-commit: 66cbccb15368713ef04d2ba0f9e8808b72557b41
Part-of: odoo/odoo#80519
Previously when apply putaway rule, we only count the packages in the
location to check if there is enough space the incoming package. Now we
also count all other assigned incoming packages to that location to
avoid overflow.
Task-2614519
X-original-commit: 21373dbc507e57c3a19b415583a5b0595a66c1a3
Part-of: odoo/odoo#80519
When apply a putaway rule to find a putaway location, we only pass the
product and/or package info to _get_putaway_location. This is not
enough since the putaway rule can also be applied to packaging.
X-original-commit: 9f339938aec075c5385dca349dfc6a7c2d43b6ad
Part-of: odoo/odoo#80519
Put in Pack won't trigger any onchange to use putaway rules. In this
commit, we apply putaway rule in Put in Pack when only one move line
is put in pack. We also check if the ml to put in pack are all in same
package type, if so, we set that package type on the package.
Task-2614519
X-original-commit: 023b69ac2ccac2456bcb1a8b1b66b468e213b86a
Part-of: odoo/odoo#80519
We didn't show company_id on package type view, there was no way to
change it. Add it in this commit.
Also made company_id on stock_storage_category form not visible when not
in multi-company.
X-original-commit: 61792e9dc13bf9d326e69eb59efe3a22354f1ca5
Part-of: odoo/odoo#80519
When find putaway location while creating new sml, we didn't consider
the package. Add it back.
Task-2614519
X-original-commit: fcbd4c775248f18c71f9cb0e700ed9934babcdfd
Part-of: odoo/odoo#80519
Previously when the onchange method find a putaway location for a sml, we
find a putaway location of the location_dest on the sml. However, the
location may already be a result of last computation of putaway
location. In this commit, we always find putaway location of the default
destination location.
Task-2614519
X-original-commit: a96fb8e9d2a57b67666ca3b29c9313aba83cdb91
Part-of: odoo/odoo#80519
Until now, stored compute fields were computed after database insertion.
This meant that required fields should not be computed, for instance,
unless some hackish code was added to make it work. Another trick was
to provide some default value, but this actually prevents the field for
being computed after insertion.
This commit provides a field parameter to specify that the field should
be precomputed: adding precompute=True on the field definition force the
method create() to compute its value before inserting the new record in
the database. For the reason explained below, precomputing fields is
not always correct, and therefore the default remains to not precompute
a field.
Some stored fields must be computed after insertion, for instance:
* statistics fields computed with search/read_group/...
* fields referencing the current record (res.partner.commercial_partner_id)
* fields referencing another record that does not exist yet (think about
records created by one2many fields)
* fields depending on the create_date/write_date/create_uid/write_uid
Those fields shouldn't be defined with precompute=True, which triggers
their computation post record creation. This is why, by safety, we
consider the default behavior to be precompute=False.
closesodoo/odoo#80449
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Yannick Tivisse <yti@odoo.com>
Purpose of the commit is to improve the generic UX of task
and project views.
task-2590412
closesodoo/odoo#75509
Related: odoo/enterprise#20423
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Current behavior:
When you try to close the PoS session when there are more than 6 payement methods the footer buttons dissapear
Steps to reproduce:
Add atleast 6 payement methods to any PoS. When you try to close a session of this PoS the footer buttons are out of the popup
opw-2667725
closesodoo/odoo#80607
X-original-commit: 0ae2b65644451efaf77e8bfd2f704055366dff2a
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Add default filters to the Allocations and Time Off smartbuttons on the time off type form.
This is done to avoid having numerous records with time and only show the relevant to approved and approved allocations as well as the time off for the current year.
task-2688122
closesodoo/odoo#79699
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Before this commit, setting a value from the editor did not created
steps but kept the mutations inside _currentStep.
Commands like delete or enter revert the _currentStep.
So each time enter or delete was pressed just after setValue, the
content being set was lost.
Task-2695041
closesodoo/odoo#80597
X-original-commit: 9e9fe73e8124d5d5527f5c5ce205f01f791aac30
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
In Argentinean localization, we are making inactive some document types in a
no-updatable xml view to keep the user configuration when the module is
updated. This fix is to avoid the possibility of inactivating doc types
from other localizations with the same code.
closesodoo/odoo#80593
X-original-commit: b7531c4ed998fb42b280b8847abf4eaee9ad1c45
Signed-off-by: Josse Colpaert <jco@openerp.com>
When adding a google font, the website test if it is valid with an URL
like:
https://fonts.googleapis.com/css?family=Open+Sans+Condensed
but this is only testing the normal with weight 400 version which might
not be available (for "open sans condensed" only 300 and 700 weight is
available).
Instead with this fix we try:
https://fonts.googleapis.com/css?family=Open+Sans+Condensed:300,300i,400,400i,700,700i
which is what is being queried when the font is really used and will
only fail if all types are missing (in which case it is a good thing
that it fails).
opw-2678485
closesodoo/odoo#80564
X-original-commit: 126ccaecb876c17dd6b7e34aef4aa4927d13b8f7
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Steps to reproduce:
- Create a product category for pos with an extremely long name
Results:
- The category name will overflow the edit form.
- In the pos view the categories/products window will be displayed under the cashier window.
- If I select the category I created it will not be displayed in the header.
Changing the category headbar styles in pos.css and adding o_text_overflow in the fields in the category form solved the issue.
opw-2688276
closesodoo/odoo#80520
X-original-commit: b92fe47237390e58bd0e8f744d2fef48bfbb83ca
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
PURPOSE
To improve Event attendees views and reporting for better usability.
SPECIFICATIONS
The goal of this commit is to improve attendees views and reporting in
Event, the changes done are listed below.
- When opening attendees from an event (stat button or kanban button), it will display
the list view (before the kanban one) and group by create_date (week).
- Removed the date_open field from the model as it is a duplicate of the create_date.
- On the attendees tree view, displayed the registration_answer_ids field with a
many2many_tags widget (optional default hide), before the Status.
- Displayed the "X Cancel" button of the attendees tree view in red.
- Moved the partner_id field next to the ticket and kept it editable in attendees form view,
also moved visitor field below the Mobile one so that even in debug mode, Attendee
Name is the "primary" field.
- Added a badge widget on the `state` field.
- Added next activity widget to the field `event_ticket_id`.
While coming to Attendee reporting section we have changed the default view as graph
view instead of stern pivot view and added default groupby `state`, `event_id`, `create_date` and
created a new filter `Last 30 Days` and made it default.
Apart from that we have made `summary` field default hide in Meeting Room tree view.
LINKS
PR #79166
Task 2670765
Related: odoo/enterprise#21976
Related: odoo/upgrade#3066
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.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 made the `summary` field optional
hide from Meeting Room list view because it breaks the
layout due to its length.
Also we have added sum for the field `room_participant_count`.
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
* = project, sale_project
Currently, the header is displayed above every group when the group by is
applied.
In this commit, we move the header with the fields labels at the top of
the table. Also, remove the string before the field indication.
task-2655707
closesodoo/odoo#77408
Related: odoo/enterprise#21989
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Steps to reproduce the bug:
- Create a storable product > add a BOM
- Create a MO> add the product > confirm > Mark as done
- Go to the product form > click on product moves
- The move linked to the MO is displayed
- Add the "Manufacturing" filter
- No move is displayed
Solution:
Display all "stock.move.line" which are linked to a "stock.move" with a "mrp.production"
Bug2:
The "Manufacturing" filter should be defined in the MRP module instead of the stock
otherwise, users who do not have MRP installed will have access to this filter as well
opw-2697254
closesodoo/odoo#80578
X-original-commit: f4ab29a19f0aaac567da27d4c4d5c79119982bc6
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
The browser object is meant to allow easily patching some native browser
behaviour when writing tests. Outside of test code, it should behave
like the corresponding properties on the window object.
Previously, the location property of the browser object held a reference
to the native window location property. While this works perfectly fine
for reading or writing things on the location object, a common use case
is to overwrite window.location with a string to navigate to a url. This
use case was not covered by browser.location
This commit fixes that by replacing the browser.location property with a
getter/setter pair, where setting a value on browser.location will do
the same thing on window.location
closesodoo/odoo#80543
X-original-commit: e838c76b1656dc289ff35e89283b8cc82e636df7
Related: odoo/enterprise#22590
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Previously, it was impossible to patch a property that was defined with
a getter or a setter with a simple value property. This commit fixes
that.
X-original-commit: cd7514e35b458143a948c7b8e73b05760df0a482
Part-of: odoo/odoo#80543
Previously, when an RPC response came back, we would unblock the UI. The
goal of this was to unblock the UI that was previously blocked by a
pending RPC. The problem was that we would unblock the UI even if we
never blocked it (as we wait three seconds before blocking the UI). This
could cause the loading indicator to unblock the UI that was blocked by
unrelated code.
This commit fixes that by only unblocking the UI in the loading
indicator if the loading indicator actually blocked it previously.
X-original-commit: 654688a9d07890ff3e80f2eff07e5de87a5f1334
Part-of: odoo/odoo#80543
When an RPC request is made, we signal it on the bus. This is used,
among other things, to block the UI when the network is unresponsive.
Some RPCs however are meant to be done in the background (eg,
longpolling) and not block the UI as they take a long time by design.
When the response to an RPC arrive, we signal it on the bus so that the
UI can be unblocked. Until this commit, the silent RPCs that never
signaled making an RPC on the bus signal that their response has
arrived, which can cause the UI to be unblocked even though a
non-background RPC was made.
This commit fixes that.
X-original-commit: 695efbfdce200c05b53bc23dc838d81f24589aa3
Part-of: odoo/odoo#80543
Steps to reproduce the bug:
- Create a BOM:
- Set the quantity of the finished product and component as more than 1
- Save > Go to BOM Structure & Cost > the quantity in the input is set on 3
- Print
Problem:
The report generated shows the qty and cost for production of 1 unit of product, regardless of the BOM quantity set in the input
The "_onClickPrint" function tries to get the quantity of the bom in the context,
but since the value of "this.given_context.searchQty" is null, the function will use the default value of 1.
The "searchQty" is only set in the "onchange", so we can manually trigger it when initiating the page so that the "searchQty" is set correctly
opw-2691632
closesodoo/odoo#80524
X-original-commit: dcd3de94f708425ca06527483cf30e21077caab0
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
This commit adds the background per section feature.
If the section to display has a background image configured, the background
will be refreshed using that section background image.
If the section has no background, the survey background is used.
The background is refreshed at the same time that the next question is loaded.
To ease technical maintenance and to keep it simple, the background is always
faded out/in at each page change only if there are some sections on the
survey that has a specific background image. If no background image are set on
the survey sections, the background will never be faded out.
Note: The next section to display depends on free text (section with
description) configuration and on conditional questions.
The next section to display can be the next question's section or directly
the next question itself (if the question is a section).
This section's background image implementation works both for the regular
survey form as well as the "live session" mode of the survey module.
Task-2225393
closesodoo/odoo#79156
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
When going back, after this commit, the last displayed page is saved in order to
reload the survey exactly where the user left it, instead of loading the survey
at the latest question of the survey displayed to the user.
Typically, if the user goes back and leave the survey on question 4, after
reaching the question 7, instead of reloading the survey on question 7,
the survey will be reloaded on question 4, where the user left the survey.
Task-2225393
Part-of: odoo/odoo#79156
Before this comment if a client had no name, false
was displayed instead of an empty string in the
user list.
Steps to reproduce:
1) Take a database with PoS.
2) Change a contact type to Delivery Address and then remove its name
3) Open PoS and click on the Customer.
Result:
- In the name column 'false' is shown instead of ''
If there's no name I'm showing an empty string
opw-2683482
closesodoo/odoo#80557
X-original-commit: 0482c6ffe5fafe9c76debe92ac0b458d36d1ecdb
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
The goal is that the counter on the smart button can display the conmplete
information ("this campaing generated 500k€, no matter if you can acces or not
the records behind this number").
Once the user clicks on the smart button, them can only see the records he has
access to.
Task-2516278
COM PR: odoo/odoo#76934
ENT PR: odoo/enterprise#21055
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
In order to add subtitle to settings subsections,
this commit adds style to h3 in settings style sheet.
Task-2516278
COM PR: odoo/odoo#76934
ENT PR: odoo/enterprise#21055
Right now, in our mass mailing, marketing users refine the audience they are
going to reach with our beautiful domain selector/editor. The problem here
is that the criteria that 'filters' audience can be very common and might be
used in many mailings.
Such filters have to be re-created manually each time they are needed unless
one duplicates a sent mailing. Another possible workaround is to access this
form view while in debug mode so that one can copy and paste those domain
expressions. Unfortunately, none of those solutions are either ideal or
convenient. Especially during the onboarding where new users are not very
familiar with those notions yet.
This commit allow users to save filters on the mass mailings. That way
favorite filters can be re-used on the next mailing. For that, we added
a new model 'mailing.filter'. We do not use existing 'ir.filter' model as
its usage is not completely the same and as we do not want to bloat view
filters with filters created on the fly in marketing application. This new
model contains the following fields:
- name (given by user while saving the filter)
- mailing_domain
- mailing_model_id (m2o for the recipient model)
- mailing_model_name (technical name of recipient model)
Users can create the filters by setting domain and then hitting hollow star
icon next to 'Filter' m2o and saving it with the name they want. Same way
to delete the saved filter, user simply have to click the filled star icon
when filter is already set. This is done through a new widget that adds its
own behavior on top of m2o widget.
The saved filters can be also managed with a new menu named 'Favorite Filters'
under 'Configuration' menu of Email marketing.
Task-2092853
closesodoo/odoo#70859
Related: odoo/enterprise#21049
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Some stored mailing fields should use the real mailing_model_id many2one
field for triggers and not sub-fields of it. As those are not stored this
may lead to unwanted writes.
Followup of odoo/odoo#41877
Spotted during Task-2092853
Part-of: odoo/odoo#70859
Odoo's Mergebot