Suppose you have a record rA of model A, and a record rB of model B
which has a related B.v on field A.x, that is stored and translatable.
Suppose also that user U can write on A, but not on B because of ACLs.
Let U write on rA.x. Then it recomputes the value of rB.v.
Since this directly calls the _write, we check the record rules but not
the ACLs, so U wrote rA.x and rB.v successfully.
Now let U be in another language L.
This means that we go trough translations, which calls _set_ids.
If the translation already exists, then the update is done in SQL so no
access rights are checked.
However if translations do not exist, the translations are created via
the ORM and thus check both record rules and ACLs.
Therefore the operation is forbidden, since by hypothesis U cannot write
on B.
We can skip the check in this case, since we come from either a create
or a write, so the ACLs should already be checked on the original models
as intended (in the case of B, not fully).
Furthermore it removes the incoherency with the update case.
opw 2145738
closesodoo/odoo#41546
X-original-commit: 19d18e81dd9d3dcce1281f662abdaf941c0c357a
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Especially important since all animations are restarted on any change of
a snippet.
closesodoo/odoo#41541
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
* website, website_mass_mailing
Now, when any option method is called (editor left panel), the widgets
related to the targeted DOM is automatically updated. This is possible
to disable for a specific widget with `data-no-widget-refresh="true"`.
This commit also makes the `_refreshPublicWidget` method better handle
its async component: it is now "fully async" so the caller should wait
for its resolution before executing some other related code.
Because the webclient and other higher level components such as the
actionManager are not yet rewritten in OWL, we cannot make a complete
migration of the controller and the model to a more OWL-ish code.
We have rewritten the renderer completely in OWL, it uses more
extensively a template and manages its own state and its sub-components.
We did not rewrite the controller, however we have made it inherit from
`web.ControllerAdapter` which is a thin compatibility layer used when a
odoo controller uses a OWL renderer.
In the tests, the only changes are that all the events triggered by the
test and handled by OWL must be triggered on DOM nodes directly and not
on JQuery elements.
closesodoo/odoo#39491
Related: odoo/enterprise#7135
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
Co-authored-by: VincentSchippefilt <vsc@odoo.com>
Co-authored-by: pro-odoo <pro@odoo.com>
Add a base class for a complete OWL renderer
Add a compatibility layer for a Odoo controller that uses a OWL renderer.
Co-authored-by: Pierre Rousseau <pro@odoo.com>
Changed the triggering of some events to dispatch native events instead of
jQuery ones and extended the api of the keydown helper to support text keys.
In this commit:
- transformed test_utils helpers to always trigger native events
- introduced new test_utils_create helper: prepareTarget
- updated qunit asserts to support Owl Components
- updated all misused helpers that would crash with the updated test_utils
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Pierre Rousseau <pro@odoo.com>
With this commit, we properly introduce the Owl library into our beloved
codebase. More information on the Owl library can be found in the project
repository: https://github.com/odoo/owl/
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Now, if user intends to add a check layout for it's own country then he/she
will need to define a layout template and a report action associated to it.
The xmlID(s) of this report action(s) needs to set as key of
'account_check_printing_layout' selection field after redifining
it in it's own module.
Refer l10n_{ca/us}_check_printing modules.
closesodoo/odoo#35438
Task: 2030714
Closes: 35438
Related: odoo/enterprise#5007
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
This reverts commit e5479fcfdb.
This commit prevented an issue of losing messages on post in case
of connectivity loss. The implementation consists of keeping the
content in the composer until the server acknowledges handling the
message.
However, this solution introduces significant issues. For instance,
sending messages in quick succession will likely loose or duplicate
some content, based on how fast/slow the RPC `message_post` is
resolved. Plus, there was an issue on mobile because the input focus
was lost during the RPC. As a consequence, the virtual keyboard
flickered.
The intent was to fix a rare issue, and since the problems of this
solution clearly outweigh the gain, we decided to revert.
closesodoo/odoo#41544
X-original-commit: 36b2e99e08bfc6d92a821d0346e783695580abf9
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this commit:
If you have not at least the timesheet user right, you can't open
project task as a field in not present in the view.
After this commit:
You can open the task view
closesodoo/odoo#41229
Taskid: 2148606
Related: odoo/enterprise#6984
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose of the task is, clicking on rating from
publicly rating project dashboard it will produce the
traceback.
so fix the traceback by fixing typo in portal rating.
Task-2145507
closes odoo/odoo#41132
Closes: #41005
X-original-commit: 9587ccc716c3e6d6c0a73acd22155b545d1638b8
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Add a domain that limits to the answers belonging an event only on the
attendee form.
Make the width of the event_type_mail_ids 100%
Sort event.registrations by id DESC and Kanban view by name
task-2071337
closesodoo/odoo#37256
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When creating vendor bills, it was considering this two numbers as different but actually are the same invoice number
* 01234-00000001
+ 1234-00000001
To avoid this we remove the zero to the left always if the pos number > 4.
closesodoo/odoo#41436
X-original-commit: 15543ebbdeb7fac2cbf60bdcafef22a84b937bfb
Signed-off-by: Josse Colpaert <jco@openerp.com>
* website, website_mass_mailing
We only have one invisible snippet (newsletter popup) which is handled
by adding a yellow alert in the DOM in edit mode to be able to click
somewhere to open the snippet options.
As we will add some new invisible snippet (generic popup, cookies bar,
and probably more) this needed to be improved.
Now, any snippet having the `o_snippet_invisible` class will have an
entry in the left panel in a dedicated zone to edit itself. This also
allows to get rid of the yellow alert, making sure that "what you see
is what you get" in the editor zone.
task-2150966
closesodoo/odoo#41420
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Introducing a new snippet called Chart.
This snippet uses the lib https://www.chartjs.org/
6 types of graph are possible:
Bar vertical
Bar horizontal
Line
Pie
Doughnut
Radar
task-2092267
closesodoo/odoo#40051
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
followup of rev [0]
If these wizards are called on multiple pickings, display the list of
the pickings that could be impacted and allow to select which one should
be impacted.
We also adapt the sanity checks at the start of `button_validte` in
order to specify the concerned pickings if needed. We do not enable the
multi behavior for batch at the moment, so it's only enabled for the
validate multi in the list view.
[0] 6ab4b0d496
task-2069646
closesodoo/odoo#41497
X-original-commit: ff276c6484b138982f185ec9c832f2dbf25baaef
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Parallax elements are overflow:hidden so that their moving background
does not overflow. This introduces a limitation: no dropdown can
overflow the snippet either.
While a better solution should be found in master, this allows overflow
for the "fixed" parallax which does not use an overflowing background.
opw-2091324
closesodoo/odoo#41492
X-original-commit: 72d3b0161a87dc28049e6595827ce60de998709e
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Writing barcode on a template will only write it on the variants if the
variant count is 1. Make the field readonly on the view according to
this condition.
closesodoo/odoo#41489
X-original-commit: a67ad076f4c079f33602f01ed2b8cbf741aeffc5
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
The wording was "Use" but when you disable it the option, they don't
stop being used.
opw-2152288
closes#41487
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
You can use has_group(employee) instead
+ fix enumerate_page: when you search a page with visibility constraints,
you never seen it even if force was set to True.
task-2091365 again
closesodoo/odoo#41483
X-original-commit: f1c7a34f0b8276895c18ca6c450a142f9a815e3b
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
MAke sure to always set the expiration date of a coupon.
opw-2151284
closesodoo/odoo#41470
X-original-commit: 2e5a66995f2488b99ed1c6d8407235f4fc032e66
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
OPW 2151580
There is a needed font for the swiss IRS report: OCR-B. This commit
ensures it is used.
closesodoo/odoo#41466
X-original-commit: 8f4a390cf3150a65dcdad2687eee1011b32f4fc7
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
This commit introduces a new snippet: Countdown.
The countdown snippet is composed of 4 circle countdown, one for every time
unit: seconds, minutes, hours and days.
When countdown ends, the user can chose between 3 possible actions:
1. Nothing
2. Show message: show a message once the countdown ends.
The message will be displayed bellow the countdown (stopped on 0) or will
replace the countdown depending on the option selected.
The message can be edited through the website builder.
3. Redirect: redirect the user to the chosen URL. If the user is on the page at
the exact moment the countdown reach 0, the user will be redirected
automatically. If the user lands on the page after the countdown has reached
0, there will be no redirection and the link will be shown bellow the
countdown (stopped on 0) or will replace the countdown depending on the
option selected.
The countdown layout can be customized in multiple ways:
1. By choosing to hide some time units. For instance, seconds can be hidden or
only days shown.
2. By changing its size between small/medium/large.
3. By changing its basic design (circle, boxes, clean).
4. By changing its advanced design (shape, background, progress bar..)
task-2093081
closesodoo/odoo#39773
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, the website was given as a parameter of the
_post_copy function which is called after theme install. It was then
transfered through the context when calling the theme sub' post_copy
function.
It makes actually more sense to directly call the _post_copy function
with the right website in the context instead of a parameter. This will
also allow to call enable_view/disable_view in the default post_copy
common to all theme, with the right website.
closesodoo/odoo#41312
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Search bank account with company to handle the case where the res.partner.bank
is defined in several companies. Without this commit, a Value error was raised
because we expect only one record returned.
closesodoo/odoo#41469
X-original-commit: 9be0adb99561c68ea2f2e3e5710f7437ef16d2f9
Signed-off-by: Alex Tuyls <alt-odoo@users.noreply.github.com>
Overwrite the method ``write`` of the model ``product.product``.
When we write on ``standard_price``, if
- the context key ``disable_auto_svl`` is not set
- the ``cost_method`` is not "fifo"
We automatically compute ``stock.valuation.layer``
(before we needed to manually call ``_change_standard_price``)
Task #2031422closesodoo/odoo#41265
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
PURPOSE
Allow some questions to be linked to customer data. We would like to have an
email field filled with user info / updating user info automatically in the survey.
SPECIFICATION
For now, we only want to be able to collect the user email address for a specific
question of the survey. For that purpose, add a ``save_as_email`` field on the
question model.
If this option is checked, the answer to that specific question will override the
"email" stored on the survey.user_input allowing live udpate of user input
based on given information. If multiple questions are marked as such, the
last (not empty) answer will prevail.
If user input already has an email (invitation-based surveys for example)
prefill the answer with the email so that people don't have to retype it.
GOING FURTHER (aka, incoming)
With live mode: maybe some additional fields will need to be saved
nickname
avatar
LINKS
Task 1919290
PR #41429
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Aurélien Warnon <awa@odoo.com>
Co-authored-by: Thibault Delavallée <tde@odoo.com>
From
"Their was an error during the validation of the survey."
To
"There was an error during the validation of the survey."
Some side code linting is also performed because my linter is screaming on
me.
Task ID 1919290
PR #41429
Co-Authored-By: Aurélien Warnon <awa@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
Before this commit, inputs were always a title followed by the <input/>
on the same line.
Now it follows the same logic as we-row elements: title on a line,
<input/> on a new line, except if the 'o_we_inline' class is used.
Part of https://github.com/odoo/odoo/pull/41402
Add the ability for a snippet option's method to target multiple
subelements of the option's $target using the data-apply-to attribute
with a jQuery selector. This is achieved by calling the method on a
proxy of the object where accesses to the $target are redirected to a
different object.
While it may seem preferable to just set the $target before calling the
method and restoring it after the call, as this would be much simpler
code, it is not possible as this breaks down under asynchronous
conditions, hence the need to operate on a proxy such that all
concurrent asynchronous operations have their own independent $target
available for their entire time of execution.
Part of https://github.com/odoo/odoo/pull/41402
Create a new contact (just open the create form)
The "Language" field is missing, because active_lang_count is not
computed before the record is saved, but it is necessary to display the
language field
opw-2149324
closesodoo/odoo#41172
X-original-commit: 4c90fde44e463979de9c6c1f5acb5c5e0c469c21
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
* converts dynamic domain from onchange_department_or_employee_id to a
static domain on the field
* remove the department_id field (and all uses of it), it looks to
never be set and not really be settable: the field is hidden in the
form, doesn't have a default value, does not have anything to
compute it, ...
* remove the onchange itself as it has very little value: it
auto-selects an equipment if there exists a single equipment
assigned to the selected employee or to no employee
Even if we removed the "equipment not assigned to any user"
bit (under the assumption that people would mostly request
maintenance for their own equipment, and that this would usefully
trigger more often) it's unlikely for dedicated users of
hr_maintenance to assign only one equipment per employee. So the
onchange would rarely do any useful work, and what work it saves is
trivial: if there's only one equipment the employee could ask about
for maintenance it's really trivial to do that.
Task 2115472
closesodoo/odoo#40963
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
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
[REF] survey: remove unused or unnecessary fields to clean models. Some fields
are also renamed to better indicate their use.
* On survey.survey, remove question field, unnecessary related on title.
* On survey.survey, remove unused category field.
* On survey.user_input, remove input_type and its garbage collect.
* On survey.{survey, user_input}, remove url fields replaced by methods
* On survey.survey, rename thanks_you_message to description_done
* On survey.survey, rename certificate field to certification
* On survey.survey, rename passing_score field to scoring_success_min
* On survey.user_input, rename quiz_score field to scoring_percentage
* On survey.user_input, rename quizz_passed field to scoring_success
* On survey.user_input, rename token field to access_token
* On survey.user_input, rename question_ids field to predefined_question_ids
[REF] survey: rename some models to ease understanding
In this merge 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;
Main user answer model is ``survey.user_input``. It holds lines related to
answers given to specific questions. In this commit we rename this model from
``survey.user_input_line`` to ``survey.user_input.line`` to be coherent with
general odoo naming guidelines.
[REF] survey: on survey.user_input.line, rename value_suggested{_row}
A new naming recently introduced for ``survey.question.answer`` has been
recently introduced: ``suggested_answer_ids`` and ``matrix_row_ids``. In
this commit we propagate that naming to survey.user_input.line model. New
naming is
* ``suggested_answer_id``: one chosen value for single / multiple choice.
It is also used for matrix columns as those indicates the value to give
on a given row;
* ``matrix_row_id``: the related row of the suggested answer for matrix
questions;
It adds two benefits
* it finishes by _id which is always a good idea for m2o fields;
* it better indicate the use;
[REF] survey: on survey.{question,user_input.line}, make type and field names match
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.
[REF] survey: refactor results page
Purpose of this merge is to globally rewrite the way statistics are
pre computed and used in results page of surveys. Indeed current code is
very complex, having a lot of calls to the same methods while taking only
part of its results. It also have a mix of model and controller methods,
data is computed several times a bit differently, ...
In this commit we rewrite that part. Including
* a simpler code flow;
* a simpler data structure;
* use a better naming for methods instead of "prepare_results" called
randomly within the code and re-using part of its returned content;
* use record sets / records instead of giving sub-elements of a record
like question.title, label.value, ...
Data structure
* simply give a question_and_page_ids to the template that will iterate
on pages / questions;
* have a graph_data, table_data dictionaries available for graph and
table display with simple entries;
* graph_data: holding all necessary but minimalist data for graph display
if question allows it;
* table_data: holding all necessary but minimalist data for table / summary
display;
* hold record sets of done / failed answers and answer lines;
In this commit we also simplify and clean pagination in survey graph results
* remove page_range helper tool that can be inlined in the templates
directly, doing a simple range;
* fix and improve pagination code;
[IMP] survey: improve demo data
Add a new demo survey about a quiz: a survey with scoring but no certificate.
Have almost all possible combinations of questions and options (notably choices
to have a scoring) and answer lines in order to be able to, notably, debug
the statistics / result page.
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 #40765closesodoo/odoo#41198
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
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
Add a new demo survey about a quiz: a survey with scoring but no certificate.
Have almost all possible combinations of questions and options (notably choices
to have a scoring) and answer lines in order to be able to, notably, debug
the statistics / result page.
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
Purpose of this commit is to globally rewrite the way statistics are
pre computed and used in results page of surveys. Indeed current code is
very complex, having a lot of calls to the same methods while taking only
part of its results. It also have a mix of model and controller methods,
data is computed several times a bit differently, ...
In this commit we rewrite that part. Including
* a simpler code flow;
* a simpler data structure;
* use a better naming for methods instead of "prepare_results" called
randomly within the code and re-using part of its returned content;
* use record sets / records instead of giving sub-elements of a record
like question.title, label.value, ...
Data structure
* simply give a question_and_page_ids to the template that will iterate
on pages / questions;
* have a graph_data, table_data dictionaries available for graph and
table display with simple entries;
* graph_data: holding all necessary but minimalist data for graph display
if question allows it;
* table_data: holding all necessary but minimalist data for table / summary
display;
* hold record sets of done / failed answers and answer lines;
In this commit we also simplify and clean pagination in survey graph results
* remove page_range helper tool that can be inlined in the templates
directly, doing a simple range;
* fix and improve pagination code;
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
Nans Lefebvre