The goal of this commit is to convert a bunch of legacy dialogs into owl dialogs.
closesodoo/odoo#131278
Task-id: 3453920
Related: odoo/enterprise#45484
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
The goal of this commit is to prepare ground to remove
lazytranslate function _lt() and keep only _t()
for a better understanding of the use of the translation function.
In this commit,
the translate function _t() has been updated to return the translation
if they are loaded. If not, it throws an error.
the lazytranslate function _lt() returns _t() function.
Corollaries :
Steps in test tours are now a function that returns an array of steps
to avoid any interpolation of _t in this ones before translations has
been loaded.
Example :
registry.category("web_tour.tours").add("example", {
test: true,
steps: () => [
{...},
{...},
],
});
task-3292454
closesodoo/odoo#124157
Related: odoo/enterprise#43153
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
It's not a specific state, it should be considered separately,
as a boolean.
This allows to reduce code complexity (flows should not rely (much) on
the locked logic) and to have a clearer flow.
Task-3163931
Part-of: odoo/odoo#115871
Currently, only stable releases see their translations updated. This has
resulted in master accumulating outdated stuff for years, which can be
confusing for users testing master on runbot.
This one-shot commit resynchronizes master translations based on the
content from 16.0 and removes empty PO files (i.e. no longer containing
translations).
closesodoo/odoo#121629
Related: odoo/enterprise#41171
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
When one customize a course by adding the 'buy now'
button. Both the 'Add to cart' and 'Buy now' button
doesn't fill the container width.
This commit fix this by changing 'btn-block' class
by 'd-block'.
See commit eee625bbb0
Task-3299234
closesodoo/odoo#120986
X-original-commit: 77d8bc4e9ed5925967294e89440cf667b26b4cbf
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
RATIONALE
Improve and make easier the invitations on courses, whatever the enroll policy.
The goal is to increase the number of attendees easily
PREVIOUS BEHAVIOUR
Before this commit, the attendees of a course were always enrolled.
No distinction existed. Inviting partners meant enrolling them at once, even if
they did not want to join. Also, invitations to a 'members only'-visibility
course were a problem since the invited member could not reach the course page
if not logged in. Therefore the invitation link in invitation mail was often
not usable (403 error). The invitation link did not act as a user creation link
if the partner was not linked to any user
PURPOSE OF THIS COMMIT
After this commit, attendees to a course can either be enrolled (default behavior)
or have pending invitation, allowing to preview the course before joining it.
Also, the invitation links redirect the partner according to their (potential)
linked user, their log in status and the ACL's. All course completion and
invitation status are covered by the new member_status selection field for attendees:
- 'invited' : member with pending invitation
- 'joined' : enrolled member, not started
- 'ongoing' : enrolled member, started but never finished
- 'completed' : enrolled member who completed the course
A) INVITATIONS: ADD ATTENDEES and INVITE
The way to add and invite attendees to a course attendees in now centralized in
two options, the buttons for which being added on the course forms / kanban cards
dot menu. On the attendee list view coming from a course, only the [NEW] button
is shown (= ADD ATTENDEES). Using the buttons will open the invite wizard. (the
same one, the difference being the value of the new boolean enroll_mode)
In both cases, when sending a link to a given partner, it will contain both a hash
based on the couple (partner_id, channel_id) and the value of partner_id. This will
allow giving access to the invited partner even if not logged in and for all visibilities
1) INVITE: copy the course link OR add partners as 'invited' + send them an email
This new option is meant for promotional purposes. It will give a preview access
to potential new members, but will not add them as enrolled. It will send an
email to partners not already in the active attendees, to invite them to check
the course
Clicking the invitation link will lead them on the course page, where a [BANNER]
will explicitely ask the invited partner to LOG IN or to SIGN UP depending on
them having a user or not, and explain them that they must first be logged to
access previews and join / buy the course. Before that, they can only see a
[PREVIEW] of the course: browse the list of contents (i.e. categories are available),
to allow them to see whether the course is of interest (forum / reviews are hidden
too). If they are logged, or once they are logged, they will see the course as if
it were public, no matter its visibility. (they can join - buy - browse previews)
[LOG IN / SIGN UP] links (see /identify route): they will bypass the value of
the 'Free Sign Up' setting and route will 1) check the invitation values
(hash, partner_id), and that there exists a matching attendee for the current
course. 2) prepare the signup / login. This prevents the invited partner from
being locked outside of the course, not being able to join it (as not able to
create user)
ENROLL policies:
-> 'on invite': inviting is considered as granting access. The partner will
not have to ask for access again, but will be able to join in directly.
-> 'on payment': users will NOT be able to join the course without buying it.
The buy button on the course page will be replace by [LOG IN / SIGN UP].
We do not want them to buy a course and potentially be locked out.
(further work should deal with the generic case of this issue.)
2) ADD ATTENDEES: add partners as 'joined' and send them an email
This option is the same as what existed before: partners are added as enrolled
attendees and invited by email. When they click on the link, they will be able
to create an account if they do not have a user, or to log in if they have one,
whatever the visibility, BEFORE being redirected to the course. They are enrolled,
so they need to log in in order to use the course. 'invited' members will also be
enrolled and upgraded to 'joined' and sent a joining email.
3) About (archived) ATTENDEES and COMPLETION:
(From task 2199207 on, attendees are now archived instead of deleted, in order to
keep track of progression. Status and completion updates must be dealt with when
using invitation / adding attendees)
Now, [ONCE 'COMPLETED', ATTENDEES REMAIN SO], whatever slides they mark as
uncompleted / completed or is created / archived on the course. Karma for
finishing the course is won only once. test_attendee_course_completion_values
is added. Even archived, we never recompute completion (remains 100) and status
of 'completed' members. The same is true for 'invited' members, we do not make
any update. This means that archived 'invited' members can have positive completion.
In addition to the obvious (recompute status and completion when completing a slide
as 'joined' or 'ongoing'), we only recompute member_status and completion when
enrolling an attendee as 'joined', in the method _action_add_members with
member_status = 'joined'. We explicitely recompute the values then. This happens
on joining (possibly from an 'invited' state), on adding members as 'joined', or
when unarchiving a record at least 'joined'.
3.1) Archived with progress:
When inviting an archived member with progress, we set their member_status
to 'invited', and unarchive them. It means that completion could be > 0 for
active (or inactive) 'invited' members. When enrolling them, we set them to
'joined' but we need to recompute their completion to update the completion
value (there may have been changes in the contents) and their member_status
accordingly.
3.2) Archived as 'invited' (no progress):
When inviting them, we simply unarchive them. When enrolling them, they are
unarchived and set to 'joined', status and completion being then recomputed.
3.3) A complex and full example.
Attendee A completed the course C, having 4 contents. member_status is
'completed' and completion = 100. Then A leaves the course and is archived.
Later, C gets 1 more content. The member_status and completion do not change.
A is invited. Its member_status is now 'invited', and completion 100. 3 contents
are archived. Again, values do not change. A clicks the link and enrolls. It
is added as 'joined' and _recompute_completion is called. completion is set
to 50% and status to 'ongoing'. As the completion was 100 but is not anymore,
the karma for completing the course is lost. They see the new slide and are
set to completion = 100 and 'completed', winning the course karma back.
B) ACCESS RIGHTS UPDATES
1) PREVIEW:
In order to give access to 'members only' courses even without logging in, we
use the url parameters invite_hash and partner_id. They can access as sudo the
course but _can_publish and _can_upload stay False. Categories can also be clicked.
No slides are accessible, only the course page, checking the access values each time
the channel route changes. See _get_channel_values_from_invite for all the checks on
the direct invitation parameters invite_partner_id and invite_hash)
The breadcrumbs and routes are updated to use channel_id instead of slug (since it
would lead to a 403 error) The course_id routes should only be used in the context of
an invitation. (generic or direct). Also, the main channel route now checks the access
rights to the course and redirect to /slides if the access is not granted, useful for
the generic invitation.
2) ACLS
- Slides: invited members to 'members only' courses now have the same access as
anyone for public courses: previews and categories, once logged in.
- Course: invited members have access to the course
- Self-enroll: 'invited' member can self-enroll to 'on invite' courses, this is done
with a sudo on the /join route.
3) About ARCHIVED ATTENDEES. [FIX] (tests included)
(*) In task 2199207, the ACL's were not updated to prevent archived members to have the
same rights as if they were active. This is because the active value is not tested by
default in rules. It is done by changing partner_ids into a computed field search method.
C) MODELS
1) SLIDE.CHANNEL.PARTNER
- new: invitation_link computed field. It generates invite_hash with course and
partner_id and contains invite_partner_id as well, used for verifications.
- recompute_completion will always recompute the completion %. However, member_status
will only be updated if not currently 'invited' and currently active. One should write
'joined' on attendees before in order to see the status of an 'invited' member updated.
2) SLIDE.CHANNEL
- channel_partner_ids / partner_ids keep the meaning of enrolled attendees/partners.
partner_ids is now replaced with a compute field, and channel_partner_ids has a
domain on member_status. search method is implemented (*)
- new: channel_partner_all_ids / partner_all_ids also includes invited attendees /
partners. partner_all_ids is also a computed field. search is implemented (*)
- new: is_member / is_member_invited are computed fields to indicate the current
user's membership status to the course
- _action_add_member is removed and _action_add_members now centralizes the logic of
adding an attendee. It will now return all NEW ACTIVE MEMBERS for the given status.
The ones unarchived, the ones created, and the ones enrolling from 'invited' state
for parameter = 'joined'. Therefore, reinvitation of 'invited' members in dealt with
in action_invite in slide.channel.invite model as they will not be returned.
3) RES.PARTNER
As a rule of thumb, the fields and display are the same as before. They cover the
courses partner is enrolled to. Changes are done to ease the search on partners:
- slide_channel_ids keeps the same meaning: the courses the partner is enrolled to.
It is changed to a compute field since we do not want to consider 'invited'
members. search method is implemented
- new slide_channel_all_ids contains all the courses: the ones the partner is
invited to or enrolled in
- Most compute methods are centralized in a single method and read_group is used.
D) VIEWS AND OTHER MAIN CHANGES
INVITE WIZARD
- As a course can be only shared via its generic link, the invite wizard now has
a [TOGGLE] 'send_email' that is visible for public courses and allow to either
copy and share the generic link, or, if toggled, show and use the email composer.
- if course is not published, a warning alert message is shown at the top. In
order to have a clean UI, the form is restructured using a sheet
- The course field is now hidden and is directly shown in the title of the wizard
ATTENDEE LIST VIEW
- [NEW] button when coming from a course (i.e. not for reporting), acting as the
[ADD ATTENDEES] button
- new columns
OTHER VIEWS
- Pivot and graph reporting views are added. A default member_status groupby too,
on all reporting views. The % of completed slides is not used as measure on pivot
view. However, it is on the graph view to compare completion of different members
easily. Avg is used as an operator, as sum of percentages does not mean much here
- Attendees kanban view update and new filters / group by's
- Quicksearch 'Tags' and 'Responsible' on slide.channel model
MISC
- Use 'course' instead of 'channel' in readable labels
- Use 'attendee' instead of 'member' in readable labels
- Error mgmt: clicking the invitation link may lead to an error, as well as
accessing a course without the rights. The user will be redirected to the main
/slides page with the appropriate error message
- Add a new template similar to the one used to join a course, but for the
invitation action
- New template for the popup appearing when joining a course. (Login or Signup)
- Use fstrings and t-attf when possible
- Use native js instead of jquery
- New placeholder if no contents on course page in the front-end
- Markup is used when possible
E) Invitation Expiration
As the invitation could be used as a promotion tool, there may be a lot of records
created as 'invited'. In order to monitor that number, we use a garbage collector.
It will remove attendees as 'invited', active or not, with completion = 0 and invited
for the last time at least THREE MONTHS before (at least invited once). Also, an
invitation older than 3 months will become expired and will not grant access to
'invited' members.
In order to track the invitation dates, a new field last_invitation_date is added to
the slide.channel.partner model. Every time one invites an attendee, it is set to the
current date. One can reinvite attendees and send them an email more than once. This
may prevent the invitation to be collected by the GC. If not set, last_invitation_date
is considered as expired.
F) TESTS and TOURS
Extensive tests and tours are added for the different new flows coming from
this new distinction between joined and invited members, and invitation flows.
They test functionality, UI, security (access rights) and model correctness.
--- Links ---
Task-2508019
COM PR - odoo/odoo#70291
UPG PR - odoo/upgrade#2572
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce:
- Install `E-learning` module
- Create a user X with only "Officer" as rights for `E-learning`
- Login with user X
- Go to `E-learning` and open any course
- Ensure that the user X is not the responsible and that the course
enroll policy is set to "On invitation"
- Invite any user not already a member
Issue:
No user was invited (not added as member) and no warning message
raised.
Cause:
Due to the ir.rule "Channel: officer: create/write own only", the
`Officer` user can only edit (and therefore invite members) on
courses where he is responsible.
Solution:
Add a param `raise_on_access` (set to False by default) to the
`_action_add_members` & `_filter_add_members` methods.
In the wizard, call the `_action_add_members` method with the
`raise_on_access` param set to True so that the error is only raised
in this flow.
opw-3133733
closesodoo/odoo#120114
X-original-commit: 515912108aef86376349df5eee51b4a5d664d2a4
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit allows the course manager to add prerequisites
courses to a course so that the final user will be notified
on the frontend he has to take some courses before the one he
wants. He could however request access to the course and
take it without taking the prerequisites before if the access
has been granted.
Task-3213628
closesodoo/odoo#114710
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
This commit converts almost all odoo module by native module.
The goal is to deprecate odoo.define in favor of native module and then
simplify boot.js by removing the regexp that finds module dependencies.
task id: 3162300
closesodoo/odoo#117305
Related: odoo/enterprise#39118
Signed-off-by: Géry Debongnie <ged@odoo.com>
Purpose of the commit is to do the generic improvements for project.
So in this commit did the following changes:
- add a space between 'access to:' and the name of the course in SOL nameget.
- hide the 'remaining hours' value if the nb of 'initially planned hours' is
equal to 0 in task list view.
- hide the 'initially planned hours' and 'hours spent' values if they are equal
to 0 in task list view.
- hide the 'milestone' and 'assignees' fields if they are false task calendar
popover
- hide the 'remaining hours on SO' value if there is no SOL set on the task
list view
- use the progressbar widget for the progress field update list view
task-2949984
closesodoo/odoo#112265
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
The type fields of actions already defaults to
the model name in the base model definition.
Therefore, specifying `ir.actions.server`, `ir.actions.act_window`
& so on as type is useless (and adds noise since it's the same as
the action model).
closesodoo/odoo#114539
Related: odoo/enterprise#37855
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
The `member_values` argument of `action_add_member` is no
longer used in any call of `action_add_member`. We can therefore
remove it in standard, as it's completely unused.
Besides, after grepping the code for all calls to `action_add_member`
to check `member_values` was indeed unused, I saw this method
wasn't used by any views or Javascript code, but only
through Python routes, and therefore it can be converted
to a private method by prefixing it with `_`,
as our guidelines states to make private methods which are not used
by the web client.
closesodoo/odoo#111908
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
before this commit,
the wording of the visibility options can be quite confusing.
after this commit,
- Visibility has been updated
- Visible to all: I see those training to the public
- Visible to logged users only: I am a B2B business, and I do not want the
public to see what I offer + the pricing I have on those
- Visible to members only: I am a school, I want to invite my students but
external visitors should not be able to enroll
- Move the field above the "enroll policy"
- Enroll Policy has been set to invite when visibility is set as a Course
attendee and hide the enroll policy
task- 2862003
closesodoo/odoo#102085
Related: odoo/upgrade#3946
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
Removes the constraint of using a pricelist and makes all sales flows
rely on the currency of the sale order (or repair order)
task-2735672
closesodoo/odoo#84920
Related: odoo/enterprise#24716
Related: odoo/upgrade#3642
Signed-off-by: Morgane Demesmaeker <edm@odoo.com>
*: website_blog, website_crm_partner_assign, website_customer,
website_event, website_event_exhibitor, website_event_meet,
website_event_track, website_forum, website_hr_recruitment,
website_membership, website_sale, website_sale_loyalty,
website_sale_slides, website_slides, website_slides_forum
With commit [1], the "customize_show" options were moved in edit mode.
They were wrongly displayed for non-designer users. Trying to use those
would throw a warning at the user.
[1]: https://github.com/odoo/odoo/commit/17a8a37e9bfc5b787d9666597d43e63f0064919fclosesodoo/odoo#103142
X-original-commit: f2ca62a4a9ccb6713a39c100fc87c112619eac41
Related: odoo/enterprise#32768
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
*: website_event, website_event_sale, website_forum, website_sale,
website_sale_slides, website_slides, website_slides_forum
This commit removes the remaining controllers that are no longer used
since the use of form views on website new content dialogs (following
the website in backend merge at [1] and the many iterations afterwards).
With the website in backend work, a feature was lost for the creation of
events: dummy tickets were created. This commit actually removes the
feature for good. Events default values are managed by templates.
Moreover there are links in frontend to edit the event when being
allowed to edit it (event groups), notably when there is no ticket in
registration page. So it makes no sense to create dummy tickets, without
price, for 1000 seats. Those values are random so they will have to be
edited. Better let users create real tickets if necessary, than editing
and/or removing dummy tickets.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
closesodoo/odoo#102928
X-original-commit: d559ce5d1518ac1293db1c4f52efb8094daf5b49
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
*: website_blog, website_event, website_forum, website_livechat,
website_sale, website_sale_slides, website_slides, website_slides_forum
The goal of this commit is to adapt the website "new content" form
views to OWL.
Follows the merge of the "website in backend" task at [1].
[1]: 31cc10b91d
task-2687506
Part-of: odoo/odoo#96346
The layout of slides needs a little freshening-up.
### Comments and slides
* The ratings are only showed once, and only for "documentation" contents
* Indications of why the user cannot post a comment are added (signing up,
Karma, commenting not allowed), and the portal template is not called if
there is no comment and commenting is not allowed (for user or course).
In addition, the "Comment" tab is never hidden anymore, to not hide
the available/activate-able features.
* Detailed view statistics are now shown only to selected users.
* Slide public views represent views by the public and all users that
are not members of the course.
* When channel/slide images are not set or inaccessible, a default image
is used (instead of plain background or unauthorized requests).
* These images are now editable on frontend.
* The 'Additional Resources' subtitle is hidden from the detailed slide view
for invite-only courses as nothing else was shown with it.
### Misc.
* This commit also fixes the "unresponsive" `total_views` count after public
views, by manually incrementing it too. This is required because `public_views`
is directly updated via SQL query and does not trigger model _computes.
* We also adjusted the test in survey that used a public user while in all
cases users must be logged-in (and therefore get portal privileges) before
they can participate.
Task-2663320
Part of odoo/odoo#79615
Due to the removal of btn-block we need to change the display to grid
> Dropped .btn-block for utilities. Instead of using .btn-block on the
> .btn, wrap your buttons with .d-grid and a .gap-* utility to space
> them as needed
https://getbootstrap.com/docs/5.1/migration/#buttons
Task ID: 2766483
Part-of: odoo/odoo#95450
*: website, website_sale_comparison, website_sale_loyalty,
website_sale_slides, website_sale_wishlist
This commit adapts "customize show" options from website sale modules by
creating new options available in edit mode.
See merge commit for more information.
task-2710582
*: website_blog, website_event, website_forum, website_livechat,
website_sale, website_sale_slides, website_slides,
website_slides_forum
The goal of this commit is to add dialogs to create new website content
using a 'target:new' action on the form view and an overridable
"website" form controller.
See merge commit for more information.
task-2687506
*: web_editor, web_unsplash, website_event, website_blog,
website_event_meet, website_forum, website_links, website_livechat,
website_sale_slides, website_slides
With [1], many files will move as the website UI is moved in the
backend. This commit moves all the static files (JS/CSS/XML) to their
final destination without modifying them, in an attempt to preserve
some history and ease some forward-ports.
After this commit, everything works as before as the files are simply
renamed and the references to them adapted.
However, technically, many files will actually be split into multiple
files by the work made with [1]. While it is theoretically possible to
preserve history over multiples files, this would require inner merge
commits, which does not go well with robodoo. In those cases, the "main"
file of the split was chosen. Mainly, 4 worth-noticing splits were
detected (and so the history moved only to the first file):
move: addons/web_editor/static/src/js/wysiwyg/widgets/media.js
to: addons/web_editor/static/src/components/media_dialog/file_selector.js
- addons/web_editor/static/src/components/media_dialog/search_media.js
- addons/web_editor/static/src/components/media_dialog/image_selector.js
- addons/web_editor/static/src/components/media_dialog/document_selector.js
- addons/web_editor/static/src/components/media_dialog/icon_selector.js
- addons/web_editor/static/src/components/media_dialog/video_selector.js
move: addons/web_editor/static/src/js/wysiwyg/widgets/upload_progress_toast.js
to: addons/web_editor/static/src/components/upload_progress_toast/upload_progress_toast.js
- addons/web_editor/static/src/components/upload_progress_toast/upload_service.js
move: addons/website/static/src/js/menu/content.js
to: addons/website/static/src/components/dialog/edit_menu.js
- addons/website/static/src/components/dialog/page_properties.js
- addons/website/static/src/components/wysiwyg_adapter/page_options.js
- addons/website/static/src/js/website_page_list.js
move: addons/website/static/src/js/menu/edit.js
to: addons/website/static/src/components/wysiwyg_adapter/wysiwyg_adapter.js
- addons/website/static/src/systray_items/edit_website.js
- addons/website/static/src/components/editor/editor.js
Notice that as those moves were made post-work and the rest of the work
(80+ commits) rebased on top of it, some commits may remove more than
they should in a moved file to then reimplement some of what was
removed in a later commit... ideally this should have been avoided of
course but keep in mind that the final files are just entirely rewritten
and split as converted to OWL. It seemed however worth it to keep most
of the inner history of the work made here to see step by step what was
done. [1] will obviously be merged with a merge commit, binding the
whole work together.
[1]: https://github.com/odoo/odoo/pull/89223
task-2687506
Currently, the name of products of the type 'course' in SOL was missing
due to the split by '\n' in name_get.
So this commit fixes this issue and remove the \n if there is
only one payment channel for course.
task-2823432
closesodoo/odoo#93836
X-original-commit: 289c3219b7975ebee8748223a136e1d752da440f
Related: odoo/enterprise#28499
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
When a product linked to a course is unpublished, the course is not
buyable. This commit improves the design in this case.
- Change the text of disabled button into "Course Unavailable"
- Add an alert message to group_website_slides_officer letting them
know that the course is not buyable because the product is unpublished
task-2842624
Part-of: odoo/odoo#90736
Before, each time we created a course "on payment". The product
linked to it was automatically unpublished. If multiple course
share the same product this leads to issues. Indeed, with the
product unpublished all the courses depending on the product are
no longer buyable.
To avoid this, we synchronise the published value when the
course is published which published the product.
If we create a new course or unpublished a previous course linked
to a product, we don't update the published value of the product
unless all courses linked to this product are unpublished.
We also fix a Forbidden error raised when the product was unpublished
but not the course. This was leading to a previous member to not have
access to a course he previously buyed.
task-2842624
Part-of: odoo/odoo#90736
This commit fixes ACLs for slide resources:
* Access to resources should be blocked for non-members (except publishers
for the course: responsible and managers)
* Tests are included
NB: As links are resources from this minor version on, their access
is protected as for files.
Task-2818136
Part of Task-2663320
FwdPort of odoo/odoo#88454
X-original-commit: 075a647d58dc7e817b31a80c2ac804b06c8492bb
Part-of: odoo/odoo#92104
This commit fixes the following fronted bugs:
* One link to "buy course" that was not updated to use the post_link class
* The join course link for "payment" courses after completing the quiz once
logged in.
* The link to resources that became accessible for non-authorized users for
"payment" courses
Task-2818136
Part of Task-2663320
FwdPort of odoo/odoo#88454
X-original-commit: 1a4368b3fce6206da555a1d04751b1aea53c6a29
Part-of: odoo/odoo#92104
Currently when user purchases a course and completes the payment, the
card of the purchased course is shown with 'Start Learning' button.
However, the layout can be improved.
This commit adds the short description of the course, duration and
steps of the purchased course to provide a bit more information to
the user. Apart from that, the title is now clickable and the
information part now occupies a bit more space than the image.
taskId-2790996
closesodoo/odoo#86873
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Purpose
=======
In preparation to the next commit, we split the course sidebar template
to be able to re-use some part of it in other templates.
Task-2604792
Part-of: odoo/odoo#75561
This commit modifies most of the usages of read_group and uses
_read_group instead. _read_group doesn't join automatically on the
many2one fields when no order_by is specified, making it more performant
when the "name" of the many2one is not relevant, which is the case for
most back-end cases
closesodoo/odoo#84908
Task-id: 2479334
Related: odoo/enterprise#24877
Signed-off-by: Raphael Collet <rco@odoo.com>
Before, there was a mismatch between the course's sales smart button
and the reporting it leads to. The amount shown is the total, taxed,
amount. Once in the reporting, the default measure is the subtotal,
untaxed.
This commit harmonizes both as well as course revenue reporting by
replacing the current default measure (price_subtotal) by the total
amount. This measure price_total is used in both graph and pivot views.
Task-2718756
closesodoo/odoo#83184
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Purpose
=======
Hide and rephrase "You have gained access to the following course(s):"
message if the product is not a course when website_sale_slides is
installed.
Task-2737404
closesodoo/odoo#84197
X-original-commit: 91eaa2cdc1a546e5358e19918fdc0ba1a7f498b2
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit makes the reporting courses list view simpler, which now has
following fields:
- name
- user_id
- total_views (updated string to `# Views`)
- rating_avg_stars (updated string to `Average Review`)
- total_time (displays total)
- members_count (displays total and updated string to `# Attendees`)
- members_done_count (displays total and updated string to `# Completed`)
- product_sale_revenues (added from website_sale_slides with monetary widget)
This commit also adds a 'Published' filter to course search view
which is applied by default in report action for the courses.
TaskID-2607467
Part-of: odoo/odoo#76930
Purpose
=======
This commit adds a default product called "Access Course" to the
database when you have the `website_sale_slides` installed.
This commit also starts the transition for courses products
into `event ticket`-like products
Specifications
==============
This product is already created in order to help the users start to sell
their courses.
We also added a new type of product named `Courses`.
This will be used to create courses and easily work with courses products.
The commit adds the list of all the courses that the will gain access to
when he will buy the product inside of the cart and in the right column
whe it appears.
It also adds the same list when the product is inserted into a sales order.
The commit adds the choice of enroll policies in the front-end when
`website_sales_slides` is installed and of the corresponding product
if we are creating a paid course.
Task-2636092
closesodoo/odoo#77990
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Gorash