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
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>
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>
Purpose of the task is, we have added the activities on various
listviews, the goal of this task is to update SO/PO/invoice demo data
with activities and also set tags on sales orders.
So in this commit, We added the activity on several SO/PO/Invoices and
also added the some tags one sales order and set the user as False
where the user is set as 'Odoobot'.
closes odoo/odoo#51799
Taskid: 2254708
Closes: #51799
Related: odoo/enterprise#10743
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
PURPOSE
=======
Since V13.3, the product "Taking care of Trees Course" has a Service Invoicing Policy
configured as "Milestones (manually set quantities on order)".
So, it's not possible to create an invoice from a SO.
SPECIFICATION
=============
The policy should be Ordered quantities
Taks ID: 2248213
closesodoo/odoo#51583
X-original-commit: 4883a4fa14dea966df2469ce6bc6cbc5cf5ee8c6
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
As portal user has access to the "Taking care of trees" demo course, we add
this course to the sale order that already contains the "DIY Furniture".
Since the course is "pay to access", it makes more sense.
LINKS
PR #41972
Task 2045571
PURPOSE
Test frontend and UI tools of eLearning.
SPECIFICATIONS
This commit move commented demo data due to dependency issues (see 9920f20e4c).
Optional products are now installed with the "full elearning setup" module
introduced recently.
LINKS
Task ID 1937768
PURPOSE
Test frontend and UI tools of eLearning.
SPECIFICATIONS
Add some demo data to allow demonstrating various flows: training, lessons,
public, private, quizzes, ...
Also prepare future test tours by improving courses that will be used for
tours, notably the public one.
LINKS
Task ID 1937768
This branch is the combination of several optimizations in the ORM:
* store field values once in the cache: the cache reflects more
faithfully the database, only fields that explicitly depend on the
context have an extra indirection in the cache;
* delay recomputations by default: use method `recompute` to explicitly
flush out pending recomputations;
* delay updates in method `write`: updates are stored in a data
structure that can be flushed efficiently to the database with method
`flush` (which also flush out recomputations);
* make method `modified` take advantage of inverse fields to inverse
dependencies;
* filter records by evaluating a domain on records in Python;
* a computed field with `readonly=False` behaves like a normal field
with an onchange method;
* computed fields are computed in superuser mode by default.
Work done by Toufik Ben Jaa, Raphael Collet, Denis Ledoux and Fabien
Pinckaers.
closesodoo/odoo#35659
Signed-off-by: Denis Ledoux <beledouxdenis@users.noreply.github.com>
* pos_sale, sale, sale_crm, sale_management, sale_stock, website_sale
Purpose of this commit is replace the confirmation date field with
order date from sale. As order_date and confirmation_date of sale order
are having same value so no need to keep two fields, remove confirmation
field and instead use order date.
cretae_date use as order Date and replace the order_date on confirmation
of the order as confirmation date.
task-2027274
closes: #34571
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
PURPOSE
eLearning should have its own application in manager. Indeed this is becoming
a big application and having it embedded inside Website application is not
enough anymore. It should also hold updated and easy-to-use menus,
navigation, actions and views in backend.
SPECIFICATIONS
Remove "Our Documentation" dummy default existing data. It makes no sense
to have void data. Instead just add a small explanation text in eLearning
front-end telling the user to create its first course if he has rights to
do so.
In order to better show the new backend add some demo data for missing
numbers, notably
* sales: add confirmed sale orders in order to have revenues value;
* forum: add some posts and answers;
* quiz: update slide.slide.partner demo data to hold quiz attempts count;
LINKS
Task 1978729
PR #35061
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
Co-Authored-By: Jérémy Hennecart <jeh@odoo.com>
The `website_published` field from the website's mixins is basically a readonly
from `is_published` field.
On read, this field will simply read `is_published` and check if the record's
website_id is accessible (only for the multi mixin).
On write, it will always write on `is_published`.
This commit improves a few things:
- A lot of code was writting on website_published which was just then writting
on is_published. Writting directly on is_published makes more sense.
- Some backend fields would still reference `website_published` instead of
`is_published` which would just go through the related for no reason.
Plus, using `is_published` will make the field tooltip more accurate as we
are not in a website context ('Visible on current website' to 'Is Published')
- Filter and search on tree view were still using the `website_published`
related field, which is just a readonly when we are not in a frontend
context.
- Some create and write function would have security check on
`website_published` value but that was wrong as the user could bypass that by
simply writting on `is_published`. For the write method, check `is_published`
is more accurate as it will cover both case since `website_published` will
then call the write method on `is_published`
image_original => image_1920 (now resized to 1920)
image_big => image_1024
image_large => image_256
image_medium => image_128
image_small => image_64
image replaced by image_1920 (when writing) or by image_1024 (when displaying
what was previously the big size)
+ add new intermediate format:
image_512
PR: #34925
Before this task, when a customer bought a course, he was directly
redirect to the checkout process.
After this task, the customer can either Add to Cart or Buy Now
(if the Buy Now option is activated)
This commit also updated the redirection regex in website_sale_product_
configurator. When a product has an optional product, you have the possibility
to add in your cart the optional product thanks to a modal. Before, the button
"Add to Cart" was only available in the shop (/shop/), but now it is also
available on a course (/slides/). So to be redirected on the cart when we
click on the button "Proceed to Checkout" for a course, we needed to apply the
redirection also for the course.
Linked to task 1974929
Related to PR #34224
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose of this commit is to improve eLearning demo data. Notably links
(links to external resources on a given slide) and quizzes (allowing to
gain karma) are added. Some slides are added. Demo user interaction with
eLearning is also added, such as membership and votes. Finally a channel
is specifically kept specific to 1 single slide of type certification as
its flow has to bypass some screens when selling pure certifications.
Commit linked to task ID 1941250 and PR #31453
Purpose is to ensure more advanced use cases are still supported in new
elearning platform in addition to more public use cases. Fields controlling
access are now
* enroll: who can enroll on course: public (everyone, simply click on join
button), invite (added by already members) and payment (in bridge with
website_sale, if SO with product is confirmed);
* enroll_group_ids: automatically add members of those groups to the channel
to ease having groups for a given subset of users;
* visibility: who can see a channel and its slides: public (everyone, it means
channel is visible on website for example), members (hidden for non members)
* website_published on channels and slides; non publishers cannot see what
is not published, whatever other parameters;
* upload_group_ids: who can upload on a channel;
* download_security on a slide is completely removed as it makes no sense
for most slide types;
To ensure a better user experience responsible of a channel is added in its
members. People uploading a slide are now also allowed to read it to avoid
having inconsistency behavior between upload_group_ids and access rules.
Some tests are added.
This commit is linked to task ID 1942836 and PR #31239.
Co-Authored-By: Aurélien Warnon <awa@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
Pimp my demo data. Purpose is to have some additional informations on demo
data defined in bridge module sale / slides. This one notably defines
a payment-based channel.
This commit is linked to task ID 1936153 and PR #30770.
Purpose of this commit is to rewrite slides demo data. More channels, more
slides, more images, less Odoo oriented content.
Everything is still not completely clean but at least it begins to look like
something we could show to people. Thanks to @awa-odoo who gave some demo
data. No thanks to @xmo-odoo who did not give demo data about the emu war.
This commit is linked to task ID 1936153 and PR #30770.
Co-Authored-By: Aurélien Warnon <awa@odoo.com>
Co-Authored-By: Thibault Delavallee <tde@odoo.com>
Task #1937160
Purpose
=======
This commit adds sale capabilities to a slide.channel. A slide.channel can
now have the 'payment' visibility, that requires a 'product_id' configured
on the channel.
When a customer purchases a product linked to a channel, he is added to the
members of the channel (see slide.channel.partner_ids) when his order is
confirmed.
The feature is added in a new module 'website_sale_slides' that comes as a
bridge auto-installed between 'website_slides' and 'website_sale'.
The final goal is to be able to sell "courses" (see task #1902304).
Victor Feyens