Before this commit, it was possible for one to post
multiple reviews when all the already posted reviews
had the 'Employee Only' state. A traceback was also
thrown when trying to update an 'Employee Only'
comment. It was also possible to edit a log note.
This commit fixes all these issues.
Task-2810085
closesodoo/odoo#121052
X-original-commit: 2e4f8ff553b11ecae444933aa2b9fab6175e64ef
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
*: test_website, website_blog, website_crm, website_hr_recruitment,
website_mass_mailing, website_sale, website_sale_wishlist,
website_slides
This commit creates a new util which clicks on edit and waits for the
edit mode to be started. This way, we make sure that the edit mode is
enabled before testing the next step of the test. This avoids race
conditions during tests.
This commit replaces all the uses of the old util with the new one, it
also removes the steps that are waiting for the edit mode to start.
Finally, from [this other commit], we can start a tour in edit mode. For
these tests (which have `edition: true`), it is useless to check if the
edit mode has started at the beginning of the test because this check is
already done by default. This commit removes unnecessary / duplicated
steps.
[this other commit]: https://github.com/odoo/odoo/commit/99b50d18e220aedf14de806f4bf1b2d35c32de35#diff-c7720501ec33f5f92c907d8bb41de50edd832a4564317073e801a6915796a6bdR278
task-3203820
closesodoo/odoo#120481
X-original-commit: https://github.com/odoo/odoo/commit/9fd5d25f59578abc9c608578a7d2e2953880b582
Related: odoo/design-themes#656
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Guillaume-gdi <gdi@odoo.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>
The mock server implementation does not exactly match the actual orm
implementation. It is not really a big deal, but it makes the test suite
less useful.
In particular, the onchange call should return a value for all fields
when we are creating a new record. Also, the default get implementation
was not exactly correct.
The motivation for this change is to prepare the future relational model
refactoring.
closesodoo/odoo#117434
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When uploading an image or a pdf content to a course, it was not uploaded. When
viewing it, as nothing was uploaded:
- for image, a default one was displayed
- for pdf, it kept loading for ever
This fixes the problem.
We also add tests checking the upload of a new image and a pdf.
Technical note: The file to upload is converted to base64 when the upload input
is changed and stored in file.data. When the user submit the file, it is that
preprocessed data that is being sent to the server. Following 542cb1dc,
nothing was assigned any more to file.data when the input field was changed so
submitted file was then always empty:
- for image, before this fix, undefined was always assigned to file.data
because the "dataURL" was split in 1 element and the second element was taken
for file.data. The submitted file was then always empty.
- for pdf, before this fix, only the preview was generated and file.data was
not assigned. Before that commit (542cb1dc), the file was read twice, one for
assigning the base64 content of the file to file.data and one to render the
preview. Here we read it only once in base64 to store it in file.data and then
convert it to binary for computing the preview using atob.
Task-3178726
closesodoo/odoo#117293
X-original-commit: 8a7453d9fc43cde13e2e07697e0b0b104a537b93
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
* The tours are now run by the `MacroEngine` defined in `macro.js`.
* This is accomplished by converting (at runtime) the user-defined tours to
`Macro`s. See `tour_compilers.js` for the step (and tour-to-macro) compilation.
* API is kept the same as much as possible. Basically, declaring tours stayed
the same with some exceptions:
* `allowInvisible` can be provided in a step to allow consuming the trigger
element even if it is invisible.
* `isCheck` can now be used to replace the no operation `run` that is
traditionally signals the runner to only perform a check.
* Before, multiple `run`s can be called simultaneously. Now, each `run` method
is awaited before proceeding to the next step.
* If the trigger element is `disabled`, the tour runner will *not* proceed on
calling the `run` method and the runner will stay on current step until the
trigger element becomes `enabled`.
* However, the tour runner is okay with `disabled` trigger element if the step
has `isCheck = true`. As long as the trigger element is found for `isCheck`
step, the tour runner will happily move to the next step.
* Some tours are adjusted to properly run with this new tour runner.
* When the tour failed:
* The dom string is not logged anymore.
* However, a warning message containing the relative location of the step will
be logged. This is better in helping the author in locating the failed step.
**Some guidelines learned during the development:**
* Each step may trigger a dom mutation. It's a good practice to insert an
intermediate step that *checks* the existence of an element that result from
the action of the previous step.
* Refrain from using the `run` method for assertions. `run`, in principle, is
provided to perform actions that are not offered by the helper. Use the
`trigger` for assertions.
* During dev, find `SHOW_POINTER_DURATION` and set it to `250`. This will show
the pointer (pointing to the trigger element) for 250ms when watching the
tour.
closesodoo/odoo#107618
Task-id: 3082036
Related: odoo/enterprise#37560
Signed-off-by: Géry Debongnie <ged@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
According to Wiktionary, French spacing is "the archaic practice (though
still current in French) of inserting a space around colons, semicolons,
question marks, and exclamation marks". This is not standard practice in
English and most languages of the world.
The purpose of this commit is to start purging the code from this typo,
as it may reflect poorly on the software for some people.
closesodoo/odoo#114533
Related: odoo/enterprise#37853
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This is a step closer to a goal of avoiding dependence on asynchronous
modules. Starting from this commit, new tour definition should be
registered to `registry.category("web_tour.tours")` registry.
So, instead of the following:
```js
import tour from "web_tour.tour";
tour.register(name, options, steps);
```
We now do:
```js
import { registry } from "@web/core/registry";
registry.category("web_tour.tours").add(name, optionsWithSteps);
```
Notice the `options` and `steps` params are merged when registering
the tour definition. It should look something like so:
```js
registry.category("web_tour.tours").add("account_tour", {
test: true,
steps: [ ... ],
});
```
And if the `TourManager` instance is needed, one can get it from the
registry like so `registry.get("tourManager")`. Note however that
this instance is only available when the `TourManager` has been
instantiated -- so it's not available at top level of the module.
closesodoo/odoo#111103
Related: odoo/enterprise#36335
Signed-off-by: Géry Debongnie <ged@odoo.com>
When choosing an image url from non-odoo pages, there is an access token
sent at the end of url. Because of this, slide_course_publisher_standard
didn't work as it expected jpg image name at the end. Now it will simply
find a match for said jpg image and won't fail. Also, before this
commit, default image was not editable with website editor.
Task-2908029
closesodoo/odoo#103620
X-original-commit: 00f9fca584f39d028108762dccef11447747b591
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit does multiple things:
- The readonly mode of form view is removed but not for the fields.
it means that the fields in the view are always in edit mode except
if we force them to be readonly.
- The control panel is revamped to take less vertical space and shows now
the record editing (dirtiness)/validity status after editing the record.
- The record is saved only when leaving the view or by clicking the save
button when hovering the record status in the control panel.
- The record can still be discarded by clicking the discard button when
hovering the status text in control panel.
task id: 2822553
X-original-commit: 77824ad44b6945a9811120380747f87ef6362ae2
Part-of: odoo/odoo#101118
Co-authored-by: luvi <luvi@odoo.com>
In the tour course_publisher_standard and course_publisher, the triggers
were not making sure that the url was validated before clicking on the
button, therefore clicking on a disabled button. This resulted in tests
randomly failing on runbot.
This commit adds an extra trigger to make sure the URL has been
validated.
runbot-4060
closesodoo/odoo#100369
X-original-commit: 2795d33d756e3101537c8ed0a017e6cc22afb1db
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
We don't want any padding in those dialogs. The presence of the
padding was a consequence of the rewritte of that dialog in owl.
It is a frequent usecase to remove the padding from the body of
dialogs. We thus introduce a new props on Dialog and when this
props is set to `true`, we do not set any padding on the body.
This commit refactors other usecases to make them use the added
props.
closesodoo/odoo#100045
Signed-off-by: Géry Debongnie <ged@odoo.com>
*: test_website, website_blog, website_crm, website_event,
website_forum, website_hr_recruitment, website_mass_mailing,
website_sale, website_sale_wishlist, website_slides
- Make sure that all website tours reaching the website preview before
their first step use the related website util to register their tour.
- Rename the website util to register a tour starting on the website
preview from `registerEditionTour` to `registerWebsitePreviewTour`.
Having a method using "Edition" in its name and having a boolean
parameter named `edition` was a bit... strange.
- For both non edit mode and edit mode as a first step, ensure the util
sets a high timeout for the first step. Indeed loading both the
backend and the frontend (in the iframe) and potentially starting the
edit mode can take a long time in automatic tests. We'll try and
decrease the need for this high timeout of course.
- Review the implementation of those utils to be more consistent and
also fix one or two mistakes in them.
closesodoo/odoo#100024
Related: odoo/design-themes#588
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
- adapt the html field and mass_mailing_widget to be owl components
- adapt the mass mailing view to be an owl view
task-2898432
closesodoo/odoo#94875
Related: odoo/enterprise#30915
Signed-off-by: David Monjoie (dmo) <dmo@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
* portal, web_unsplash, website_*
This commit renames the `website.group_website_publisher` into
`website.group_website_restricted_editor`.
While the change in itself might look unuseful, it will help the dev and
tech community figuring which group is related to which feature.
Even internally when we discuss specs, we always have to remind which
group is the restricted editor: the publisher one or the designer one?
While it is probably, after all those years, now anchored in some dev
mind, there is no easy way to directly figure which of those 2 groups is
the restricted editor one.
Note that I myself always got confused about it.
Now, the "Restricted Editor" right will be reflected in its technical
name `group_website_restricted_editor`.
Same as for the "Editor & Designer" which technical name is
`group_website_designer`.
As we would like to have a fully working and ready system in v17 for the
community to be able to build themes easily, removing that dubious part
is a nice to have.
Part-of: odoo/odoo#98200
This commit converts the old "slide_category_one2many" field to the new
WOWL field API.
Part-of: odoo/odoo#97984
Co-authored-by: Lucas Perais (lpe) <lpe@odoo.com>
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
> Data attributes for all JavaScript plugins are now namespaced to help
> distinguish Bootstrap functionality from third parties and your own code.
> For example, we use data-bs-toggle instead of data-toggle.
https://getbootstrap.com/docs/5.1/migration/#javascript
Task ID: 2766483
Part-of: odoo/odoo#95450
The createChatterContainer helper was used during tests to mount
a chatter container and test it. However, this approach is not
very realistic and blocks some waiting PRs. In order to get closer
from the reality, let's mount a webClient and open a form view
containing a chatter.
closesodoo/odoo#94175
Related: odoo/enterprise#28684
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
*: website, website_blog, website_crm, website_event, website_forum,
website_hr_recruitment, website_mass_mailing, website_sale,
website_sale_loyalty, website_slides
This commit adds the current website displayed view xmlid outside of the
iframe, on its container, so that the tours registered with
registerThemeHomepageTour can continue to prepend their triggers with
the view xml id.
Introduce registerEditionTour: this function will allow tour maker to
more easily register a tour that needs to start in the iframe's backend
and go in edit mode.
See merge commit for more information.
task-2687506
Co-authored-by: Benjamin Vray <bvr@odoo.com>
Co-authored-by: Younn Olivier <yol@odoo.com>
* hr, im_livechat, mail, sms, snailmail, test_mail_full, website_livechat,
website_slides
PURPOSE:
Creating a record with no values has no sense but is sometimes useful during
tests.
The support should be dropped for `default` parameter in `create`.
SPECIFICATION:
All the occurrences of `create()` have been replaced by `create({})`.
Task-2869394
closesodoo/odoo#93917
Related: odoo/enterprise#28538
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Using lazy values allows you to not do query when the content is not
displayed or if it is already cached. Adding `t-cache` only reduces
render time, but combining it with lazy values saves browses, computes
and query.
Thus for the `/shop` page the page is displayed in 60ms (before: 250ms).
Part-of: odoo/odoo#88276
Purpose
=======
Allow the users to themselves mark their course as "done" or "not done"
Specifications
==============
When the course is a "Training" in fullscreen or in non-fullscreen, or
when the course is a "Documentation" in fullscreen mode, allow the user
to click on the "done" button in the sidebar.
When the course is a "Documentation" in non-fullscreen mode, add a
button "Mark Not Done" when the slide is done.
The quiz and the certification cannot be marked as done manually, the
user has to complete the questions for that.
A certification cannot be marked as "Not Done" (but a quiz can).
In the non-fullscreen view, mark content as done automatically like we
do for the fullscreen view.
Technical
=========
As the fullscreen view and the non-fullscreen view will share a lot of
code, make a common class to avoid redundancy.
Task-2604792
Part-of: odoo/odoo#75561
Purpose
=======
Change all masculine nouns in Odoo's code to neutral nouns (when
possible), making sure that demo data is correctly handled. This is
particularly important since our code is open source, and nowadays lots
of machine learning models are trained on open source repositories.
With this small change we contribute to training more "fair" models, and
teaching models that "employee" or "user" != "he".
This also affects some text visible by the user, hence making it more
inclusive for Odoo users.
Task-2853046
closesodoo/odoo#91292
Related: odoo/enterprise#27302
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Since a recent commit[1], we introduced a standard publisher tour for
the slides. However, it was randomly failing sometimes while trying to
change image of the course. It happened because sometimes the double
click was performed before the page was ready to be edited, and so the
modal to change the image could not open.
This commit fixes the tour by adding extra_trigger in relevant step so
that before double clicking the image, we can make sure that the page
is ready for the edition.
commit[1] - https://github.com/odoo/odoo/commit/1af6dfe47baf1f42865203d0f3edafc6b50bbae8
task-2786661
closesodoo/odoo#87974
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
*: web, website_slides.
Specifying both side of a relation when seeding test data is cumbersome.
Let startServer method handle it.
task-2792108
closesodoo/odoo#86939
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
website_slides was relying on a model that belongs to a module
it does not depend on. This makes the single module builds fail.
Moreover, it appears this model was not even used during tests.
closesodoo/odoo#86876
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Patrick Hoste