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
We want to activate product variant by default for testing product configurator.
Otherwise Odoo want to de-install the whole module due to dependency chain.
Task-2677144
closesodoo/odoo#79466
X-original-commit: 63211eb48d3ac54e22dbee48f3131bd46aea5599
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The license is missing in most enterprise manifest so
the decision was taken to make it explicit in all cases.
When not defined, a warning will be triggered starting from
14.0 when falling back on the default LGPL-3.
closesodoo/odoo#74245
Related: odoo/design-themes#48
Related: odoo/enterprise#19862
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Users may want to be able to have transactions coming from multiple
payment acquirers to be registered in the same journal.
This will allows that.
Task id #2414749closesodoo/odoo#67331
Related: odoo/upgrade#2500
Related: odoo/enterprise#17258
Signed-off-by: William André (wan) <wan@odoo.com>
The "Accept Terms & Conditions" toggle had been mistakenly removed from
the "Customize" tab by commit 573ed74.
task-2494916
closesodoo/odoo#71102
X-original-commit: b64519c1cb15540db5343f69be501e7a6d507b06
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
Conversion of all modules to the new manifest assets declaration.
Part of task: 2352566
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Simon Genin <ges@odoo.com>
PURPOSE
Before this commit, the "payment from odoo" flow (direct) required
tokenizing a payment method before processing a payment, rather than
directly processing the payment, and eventually tokenizing the payment
method later. In practice, this often meant that a 'validation'
transaction had to be processed and immediately refunded in order to
generate a temporary token. Then, a second "payment by token" flow had
to be executed to process the intended payment.
This implementation was too rigid for most modern payment providers'
APIs. Indeed, they mostly expect single processing for a given payment
and usually offer the possibility to tokenize the payment method after
the payment, rarely before. Because of this, the implementation of many
providers was either difficult, limited, or even impossible.
Among the various incompatibilities, we find: support for direct
payments but not tokenization, lack of support for authentication during
tokenization, absence of hosted page dedicated to tokenization, etc.
As another cascading consequence of this implementation choice, several
providers could not be migrated to newer APIs after that the ones
implemented in Odoo were deprecated.
The goal here is thus to 'invert' the payment flow implemented in Odoo.
As this means re-writing most of the payment module and of its provider
implementations, the opportunity is taken to deeply clean and document
the code of the impacted modules.
SPECIFICATIONS
- Lift the limitations listed above by inverting the generic direct
payment flow to first create and process a transaction, then tokenize
it if requested.
- Remove the `payment_flow` field on `payment.acquirer` and let the
acquirer choose the appropriate flow according to the use-case.
- Filter acquirers offered to the customer based on the use-case.
- Add overridable hooks at key steps of the payment flow to allow
implementing new providers with minimal effort (both in Python and
JavaScript).
- Move all module-specific logic and fields to where they belong (e.g.
let Subscriptions filter out acquirers based on their support for
tokenization, move `qr_code` in `payment_transfer`, ...).
- Homogenize the inheritance strategy of acquirer modules.
- Standardize the implementation logic in other modules' controllers.
- Improve the traceability of payments through stored fields and logs.
- Remove the public read right on `payment.acquirer` and enforce the
use of access tokens in all modules' flows.
- Fix all bugs that were inherent to the old implementation.
- Replace the previous testing suite (which was mostly commented-out for
years) with a new one that allows testing of both routes and flows
with different test configurations (user, transaction context, ...).
LINKS
Enterprise PR: https://github.com/odoo/enterprise/pull/12528
Upgrade PR: https://github.com/odoo/upgrade/pull/2291
task-2085989
closesodoo/odoo#56187
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Co-authored-by: Antoine Vandevenne <anv@odoo.com>
Co-authored-by: Victor Feyens <vfe@odoo.com>
Co-authored-by: Arnaud Joset <arj@odoo.com>
Co-authored-by: Kevin Baptiste <kba@odoo.com>
Co-authored-by: Barad Mahendrasinh <mba@odoo.com>
Co-authored-by: Prakash Prajapati <ppr@odoo.com>
Co-authored-by: Adrien Horgnies <aho@odoo.com>
This commit replaces the old online payments API of the `payment`
module with the new one and adapts to it all the implementing modules.
See the merge commit for more details.
task-2085989
task-2119838
task-2165982
task-2289255
Co-authored-by: Victor Feyens <vfe@odoo.com>
*: website_sale_product_configurator,website_sale_stock,
website_sale_comparison,test_website_slides_full,
website_sale_delivery,website_sale_coupon
The goal of this commit is to add a new option within the settings
to "keep the same page" when a product is added to cart.
This option is website related and the "Stay on page" behaviour
is the default one.
In this commit, the following changes have been made:
1- Tweak the method 'cart_update_json' in website_sale controller
to make it suitable for adding products to cart in the same page
(as in 'cart_update' method but without redirection).
2- Update 'WebsiteSale' widget to stay on page on addition to cart:
2.1- The '_onClickAdd' method handles click events for:
- "Add to Cart" & "Buy Now" buttons on product page.
- Optional Add to cart button on products grid.
With This change, the "Buy Now" behaviour will stay the same as before.
2.2- "Add to cart" code moved to 'website_sale.utils' to be used on other
widgets (e.g. ProductComparison).
3- The new "add to cart" scenarios should be updated to work with
'website_sale' related tours by adding a new 'goToCart' step.
task-2411759
closesodoo/odoo#63300
Related: odoo/upgrade#2321
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
The goal of the draft state on survey is to have the survey under edition
mode before before sending it to participants. Under this mode:
- the responsible can test it (can be done with "In Progress" mode)
- the survey can't be answered (same as the state closed)
The risk that the survey can be leaked before being ready is really
limited. If it's a live survey, participants will have to guess the
4 digits access code and wait for the host to go to the next question.
Else, participant will have to guess the token.
Considering these facts, the use of the draft state is very limited so
'draft' state can be dropped. If we do so, we are left with only two
stages that are 'open' and 'closed'. But whether to consider survey
open or closed can be simply achieved with active field we already
have (if active=False, survey is closed, otherwise it's considered
as open).
So with this commit, we remove the state field from survey and thus
simplify the flow. It means that we no longer require 'Start Survey'
button, and so that button is also removed, and for the closed surveys,
instead of the button 'Set to draft', now we have a 'Reopen' button
which will activate the survey. And instead of displaying few buttons
after saving a record, we now display all the buttons from beginning.
Task ID-2389434
COM PR odoo/odoo#62712
ENT PR odoo/enterprise#15217
UPG PR odoo/upgrade#2006
Purpose
=======
The current kanban view is messy. It is difficult to identify which
apps are installed or not. The user can completely miss a module
that might have interested him. A search panel would make things way
more readable.
closesodoo/odoo#44401
Taskid: 2181557
Related: odoo/enterprise#8144
Related: odoo/upgrade#879
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
In this commit, all the questions type have been redesigned to look more fancy.
(impacted question types : radio and checkboxes, text boxes (textarea and text
inputs, date and datetime inputs and matrix)
For radio and checkboxes, both design have been aligned to work the same way
(except checkboxes can still have more than one selected option).
Selection by key have been applied on those two question types if the number of
option is under 26 (to use all the alphabeat character for selection). This
selection by key is only available on page per question layout.
Tests have been adapted accordingly to the redesign (typically for choice and
matrix inputs)
* Progress Bar
This commit adds a progress bar to the survey to inform the user
where he is in the survey filling process.
There are two progress modes:
- Number : will display the number of the current page on the total number
of pages (or questions if layout mode is question_per_page)
- Percentage : will display the percentage of page or question already done
So this leads to, on last page:
- in Number mode :
the progress bar div is 100% filled 3 / 3 pages [===]
- in percentage mode :
the progress bar is aligned to percentage 66% completed [== ]
* Print Widget
A widget is added for survey print mode in order to resize all textarea to fit
their content, instead of showing a scroll bar. This can be usefull if user
wants to print the results. He will get the entire content of the 'textarea
answers' instead of only the two first lines.
* Misc
This commit also :
- adds background image to survey.
- redo quizz correction and add some data to illustrate non scored
questions rendering in print template
- review breadcrumb style
Note : readonly data option on survey form widget is not set anywhere yet but
the usage is done in prevention of the future work on presenter view for survey
session mode.
Task ID: '2150291'
PR #43237
PURPOSE
To have a better UX, the transition between questions in a survey should not
be done by loading another page, but by loading next questions in AJAX.
This will allow to fade out / fade in the next question and improve the user
experience, as well as prepare the work for the complete survey redesign.
SPECIFICATIONS
General
=======
This commit refactors the way the questions are loaded.
To go to next question(s), instead of redirecting to a new page containing
the next question(s), the submit process is loading the next question(s)
using ajax. The template of the question is prepared at server side and is
given in html string to the client that display the next question in a smooth
transition (fade in / fade out).
This commit includes also the start and the end screen of the survey inside
the survey form in order to perform smooth transition between start screen
and first question(s) and between last question(s) and end screen.
Only one master template (survey form) is now used to display every part of
the survey : start + questions + end screens.
The answer_done error is now handled by the _prepare_survey_data itself.
If the user wants to display an already_done survey, the returned template
is the end screen.
This commit handles page transition for the survey results. When submitting
survey, the survey result widget is initialized and attached to the survey
result section.
A new route has been added : /survey/begin/.
If the user arrives on start screen, the state is 'New'. Once the user clicks
on Start button, an rpc call is made to survey/begin that will call the
survey_prepare_data to render the first question page and set the state to
in_progress and the start_datetime of the answer.
Validation
==========
Add the validation of all types of questions directly in the frontend.
This allows to reduce the latency before the survey is validated and was
necessary to go along with our new fade out / fade in mechanism.
The client does not need to wait the validation answer from the server to
display validation error messages.
The current questions are only faded out if the frontend validation has passed.
The server still makes this validation before submitting answers and loading
next question(s) to avoid direct rpc calls that would mess up the answers.
Error messages are now displayed with a slide down transition, for a wonderful
wow effect !
Timer
=====
As the survey form works with ajax to display start screen, question(s) and
end page, the timer has to be started only after the start screen.
This commit display and start the timer only after start survey button is
clicked.
Breadcrumb
==========
As the survey form now works in ajax to display in same page start screen,
question(s) and end page screen, the breadcrumb has to be controlled not only
on page loading but also manually between transition from a screen to another.
To ease the breadcrumb management, breadcrumb is now a widget that will reload
a js template, mainly depending of the current page id.
The js form initialize or update this widget giving this new page id.
On breadcrumb item click, the widget triggers a onclick caught by the form
that calls the submit with the given target.
This commit handles page transition for the breadcrumb. When going forward or
backward (next or previous page), the breadcrumb activates, deactivates and
links elements are reinitialized depending of the target page.
LINKS
Task ID: 2152223
PR #41453
Co-authored-by: Aurélien Warnon <awa@odoo.com>
This commit prepares the complete redesign of survey.
Simple choice question type will only use the radio button display mode.
So the dropdown display mode is deleted.
Task ID: 2152223
PR #41453
PURPOSE
As new features are about to land in survey, notably live interactions [1]
and new survey building [2] performing a pre cleaning is necessary. In this
PR we clean survey models by: removing unnecessary fields, cleaning some code
and finally renaming models.
SPECIFICATIONS
To better understand question type and their input type, we update some of
``survey.question`` ``question_type`` keys :
Type----Old type-----New type
text----free_text----text_box
char----textbox------char_box
Untouched question types: ``numerical_box``, ``date``, ``datetime``,
``simple_choice``, ``multiple_choice``, ``matrix``. Those are already
understandable.
Then ``survey.user_input.line`` ``answer_type`` keys are also updated to
match their question type counterparts
QuestType--------Old type-----New type
text_box---------free_text----text_box
char_box---------text---------char_box
numerical_box----number-------numerical_box
Then ``survey.user_input.line`` fields used to store the value are updated to
propagate the new naming
AnswerLineType----Old field----------New field
text_box----------value_free_text----value_text_box
char_box----------value_text---------value_char_box
numerical_box-----value_number-------value_numerical_box
Untouched answer types and field storing value: ``date``, ``datetime`` still
refer to same question type and use value_date / value_datetime fields.
``simple_choice``, ``multiple_choice`` and ``matrix`` still use ``suggestion``
answer type and ``suggested_answer_id`` (+ ``matrix_row_id``) to store link
to ``survey.question.answer`` records.
LINKS
[0] Related to Task ID 2061901 (survey models cleaning and preparation)
[1] Task ID 1972640 (live interactions)
[2] Task ID 2119587 (new frontend for building surveys)
PR #40765
PURPOSE
As new features are about to land in survey, notably live interactions [1]
and new survey building [2] performing a pre cleaning is necessary. In this
PR we clean survey models by: removing unnecessary fields, cleaning some code
and finally renaming models.
SPECIFICATIONS: RENAME THANKS_YOU_MESSAGE ON SURVEY.SURVEY
On survey.survey, rename thanks_you_message to description_done
In this commit we rename thanks_you_message field. Indeed for certifications
or recruitment form, "thank you" is not really the unique content you
would get in a post-survey message. We therefore rename it to description_done
to better indicate its use.
SPECIFICATIONS: RENAME CERTIFICATE ON SURVEY.SURVEY
On survey.survey, rename certificate field to certification
All certification related fields on survey model begin with certification_ .
Only the boolean one telling if a survey is a certification or not is called
certificate. In order to ease grep and ordering it is renamed to certification.
SPECIFICATIONS: RENAME PASSING_SCORE ON SURVEY.SURVEY
on survey.survey, rename passing_score field to scoring_success_min
``passing_score`` field name is not really the best name we could find.
Renaming the field using a ``scoring_`` prefix allow to know this field
is linked to the scoring mechanism.
LINKS
[0] Related to Task ID 2061901 (survey models cleaning and preparation)
[1] Task ID 1972640 (live interactions)
[2] Task ID 2119587 (new frontend for building surveys)
PR #40765
PURPOSE
As new features are about to land in survey, notably live interactions [1]
and new survey building [2] performing a pre cleaning is necessary. In this
PR we clean survey models by: removing unnecessary fields, cleaning some code
and finally renaming models.
SPECIFICATIONS
In this commit we rename the long standing ``survey.label`` model. Indeed
a label is something before a question, like an input label. Labels in survey
are used for suggested answers and sometimes as rows for matrix answers.
After much thoughts we rename ``survey.label`` to ``survey.question.answer``.
It indicates this model holds answers. Moreover it is namespaced within the
``survey.question`` model name to avoid conflict with user input / user answer
model.
As model naming changes, some fields also evolve. In survey.question model
* ``labels_id`` is renamed to ``suggested_answer_ids`` to indicate it is
used to display suggested values to the user;
* ``labels_id_2`` is renamed to ``matrix_row_ids`` to indicate it is used
to generate the rows of the matrix-type question. A matrix is therefore
done using ``matrix_row_ids`` for rows and ``suggested_answer_ids`` for
columns which seems easier to understand;
In survey.question.answer (old survey.label) model
* ``question_id_2`` is renamed to ``matrix_question_id`` to ease its
understanding, notably that it is used for matrix questions;
LINKS
[0] Related to Task ID 2061901 (survey models cleaning and preparation)
[1] Task ID 1972640 (live interactions)
[2] Task ID 2119587 (new frontend for building surveys)
PR #40765
There is no unique constraint on the properties to avoid having two
properties for the same field, company and res_id.
Having two properties for the same field, company and res_id, leads to
inconsistencies through the code, as reading a company-dependent field
nondeterministically returns one of the available property value.
So now, before creating a property, we have to check that there is not
already a value for the field, company and res_id and write or create
depending on if it is already exists.
The properties of specific records already satisfy the constraint thanks
to the implementation of company-dependent fields that use the method
`set_multi`. We added a method `set_default` to set generic properties,
and its implementation does the right thing. It also simplifies the
code to set such properties, by the way.
closesodoo/odoo#40473
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
When loading a page on an existing starting database, registry is not
fully loaded causing potential error when trying to access model
existing in database (views, menitem, ...) since model added in last
loaded module does not exist in registry.
Thus, executing browser js test may lead to errors when executed during
an update on a database with other modules installed.
HTTPCase should be executed post_install to ensure that registry is
fully loaded to avoid this problem.
Since HTTPCase are slower than other test, it is also a good idea to
execute them at the end, in order to prioritize fast fail.
With this commit, a warning is isued if such a test class is tagged to
run at install time.
While at it, remove deprecated at_install and post_install helpers and
remove the deprecated phantom_js alias.
closesodoo/odoo#39462
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Since admin is responsible of all created demo channels and then re-added
manually as member in demo data of slide.channel.partner he is actually
twice member of some channels. This commit fixes that by resetting its
membership status before adding membership demo data.
PR #36756
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
This commit adds a new module whose purpose is mainly to add tours on a
full eLearning configuration. It depends on
* website_sale_slides: eCommerce integration with checkout process and
on-payment channels support;
* website_slides_forum: forum integration in eLearning;
* website_slides_survey: certifications support in eLearning;
This module adds a first test tour that tests the certification course.
It is composed of a single certification lesson customers have to buy.
Failing and being removed as well as succeeding and gaining completion are
tested.
LINKS
Task ID 1937768
Aurélien Warnon