Daily updates from Odoo
Navigate
Branch
Thursday, December 5, 2019
28 changes
New functionality added to Odoo
Odoo now includes shared file upload support for view controllers, including progress indicators users can see during uploads. This helps apps such as Manufacturing offer clearer upload feedback similar to the Documents app.
Original PR description
This commit adds mixin to manage file uploads in view controllers and to display progress bars. The first motivation and use case is to allow MRP to manage and display uploads like in Documents. Task: #2074822
Enhancements to existing features
Website editor options can now be applied to specific parts inside a snippet instead of only the whole snippet. This gives page builders more precise control when configuring reusable website sections, supporting richer editing behavior with less custom work.
Original PR description
This is an experimental commit that adds the ability for a snippet option's method to target multiple subelement of the snippets 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.
This update improves day-to-day accounting workflows by simplifying invoice and bill views, making account lists easier to navigate, and improving search and sorting options. It also makes opening balance dates more consistent and adds useful fields to tax report configuration lists.
Original PR description
### List of improvements: **Invoice/Bill** - Hide "untaxed amount" section when there is no tax. - Remove tooltips for tax groups field. - Remove invoice_partner_icon and set this icon in "Vendor" (in a list view) **Chart of Accounts** - Same views for config bar and regulare one - By default don't show deprecated accounts and add filter to display them. - Add some optional fields in list view (taxes, tags, ...) **Dashboard opening balance wizard** - The opening move entry date equals to the opening date - 1 day. **Bank Statements** - Set default order for the list view (by date desc and name desc) **Tax report configuration** - Add 3 new columns for the list view (country_id, code, tag_name) - Add 4 new searchs (name, tag_name, code, country_id) **Task ID: 2048225**
Resolved issues and error corrections
This update removes unintended debugging messages and breakpoints from the web interface. It helps keep the user experience clean and avoids unnecessary technical output appearing during normal use.
Original PR description
Some debugging lines were introduced in https://github.com/odoo/odoo/commit/30cf7bc798ddede8e610001146f4a76352aa582f Those should be removed -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change corrects a small spelling mistake from “udpate” to “update” in several parts of Odoo. It improves clarity in the code and related text without changing how users interact with the system.
Original PR description
Description of the issue/feature this PR addresses: correct typo `udpate` -> `update` -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Code cleanup and technical improvements
This update reorganizes and renames internal survey data models so they are easier to maintain and extend. It removes unused survey fields, clarifies naming around answers, scoring, certifications, and access links, and prepares the survey app for upcoming live interaction and survey-building improvements.
Original PR description
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…
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 #40765The Documents app JavaScript has been reorganized so features that were previously limited to the kanban view can also work in the list view. This should make document management more consistent across views and reduce future maintenance effort without changing the core business workflow.
Original PR description
This commit refactors the JS of documents, allowing all the features that are specific to the kanban view to also be used in the list view. Task: #2074822
Miscellaneous changes
Open Bank reconciliation, deactivate some record (-), go to "Manual Operations" tab, add Nalytic Tags using the "Search More" functionality. Resulting tag will be blank and impossible to delete. This is because when selecting analytic tag(s) this way an array of results is returned but it is not handled correclty by the view. When selecting the analytic tag from the drop down menu a single value '{id: , display_name: }' is returned. opw-2146833 -- I confirm I have signed the CLA a
Original PR description
Open Bank reconciliation, deactivate some record (-), go to "Manual
Operations" tab, add Nalytic Tags using the "Search More" functionality.
Resulting tag will be blank and impossible to delete.
This is because when selecting analytic tag(s) this way an array of
results is returned but it is not handled correclty by the view.
When selecting the analytic tag from the drop down menu a single value
'{id: , display_name: }' is returned.
opw-2146833
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#41319
Forward-Port-Of: odoo/odoo#41300Description of the issue/feature this PR addresses: Fix the issue #34317 by making the payment date to be localized thanks to date widget Current behavior before PR: Payment dates not localized in invoice reports Desired behavior after PR is merged: Payment dates localized as per Odoo settings in invoice reports -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#34324
Original PR description
Description of the issue/feature this PR addresses: Fix the issue #34317 by making the payment date to be localized thanks to date widget Current behavior before PR: Payment dates not localized in invoice reports Desired behavior after PR is merged: Payment dates localized as per Odoo settings in invoice reports -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#34324
When the box is in "access point" it calls the function 'get_wifi_essid' at every ping => ~ 3 seconds. So after a few moments the network card blocks and turns off. Now we redirect the user to the '/steps' route that only executes the function once. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/
Original PR description
When the box is in "access point" it calls the function 'get_wifi_essid' at every ping => ~ 3 seconds. So after a few moments the network card blocks and turns off. Now we redirect the user to the '/steps' route that only executes the function once. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#41397
When the adapation without jQuery promise was done for 12.3 (in bfed574255fc) the hack for always saving a pad URL was added in the deferrence of the start method. This caused that in the following conditions: - pad URL is set - form is in edit mode - a change in the form change the readonly status of the pad => we would have a mutex lock (of the form change) waiting for the pad that is being rerendered to finish its start but that can only be done once the mutex is unlocked (because se
Original PR description
When the adapation without jQuery promise was done for 12.3 (in bfed574255fc) the hack for always saving a pad URL was added in the deferrence of the start method. This caused that in the following…
When the adapation without jQuery promise was done for 12.3 (in
bfed574255fc) the hack for always saving a pad URL was added in
the deferrence of the start method.
This caused that in the following conditions:
- pad URL is set
- form is in edit mode
- a change in the form change the readonly status of the pad
=> we would have a mutex lock (of the form change) waiting for the
pad that is being rerendered to finish its start but that can only
be done once the mutex is unlocked (because setValue of the pad is
protected by the same mutex)
This happened for example if we had a project.project A without
collaborative pad, project.project B with collaborative pad, and if we
moved a task from project B to project A then back to project B.
With this change, we get back to the behavior before bfed57425 of not
waiting for the fake "setValue" in `start` of Pad.
Without the change, added test fails with:
Expected 1 assertions, but 0 were run
because interface is deadlocked so write does not happen.
opw-2150827
Forward-Port-Of: odoo/odoo#41346Forward-Port-Of: odoo/odoo#41395
Original PR description
Forward-Port-Of: odoo/odoo#41395
We must delete the folder "MOUNT_POINT" before the "zerofree" Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#41388
Original PR description
We must delete the folder "MOUNT_POINT" before the "zerofree" Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#41388
When printing an invoice, the order of the lines not always match the order in the interface. It occurs because `account.move.line` contains a `sequence` field which is taken into account in the UI but not used in the report. Note that commit 0a5955bff62bc313f7b6 explicitly removed from the `_order`. opw-2145878 opw-2147922 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed t
Original PR description
When printing an invoice, the order of the lines not always match the order in the interface. It occurs because `account.move.line` contains a `sequence` field which is taken into account in the UI but not used in the report. Note that commit 0a5955bff62bc313f7b6 explicitly removed from the `_order`. opw-2145878 opw-2147922 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#41380
Description of the issue/feature this PR addresses: This change fixes #38577 Current behavior before PR: The state field does not contain any information whether an invoice was paid or not. This info is stored in the invoice_payment_state field. Desired behavior after PR is merged: This change fixes the field used in the customer-facing template to display the payment status of the invoice. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Original PR description
Description of the issue/feature this PR addresses: This change fixes #38577 Current behavior before PR: The state field does not contain any information whether an invoice was paid or not. This info is stored in the invoice_payment_state field. Desired behavior after PR is merged: This change fixes the field used in the customer-facing template to display the payment status of the invoice. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#41370 Forward-Port-Of: odoo/odoo#41354
Forward-Port-Of: odoo/odoo#41362
Original PR description
Forward-Port-Of: odoo/odoo#41362
Before this commit, when navigating from test environment (e.g. page reload), it crashed with following error: `TypeError: Cannot convert undefined or null to object` This error comes from mocked bus services in tests: even when they have been destroyed, they handle the window event 'unload'. They no longer have a parented parent, so `this.call()` returns `undefined`, hence the crash. This commit prevents mocked bus services to listen on window 'unload' event. Tests must always sim
Original PR description
Before this commit, when navigating from test environment (e.g. page reload), it crashed with following error: `TypeError: Cannot convert undefined or null to object` This error comes from mocked bus services in tests: even when they have been destroyed, they handle the window event 'unload'. They no longer have a parented parent, so `this.call()` returns `undefined`, hence the crash. This commit prevents mocked bus services to listen on window 'unload' event. Tests must always simulate this window event by explicitly calling the handler. Forward-Port-Of: odoo/odoo#41330
Description of the issue/feature this PR addresses: Change the order of documents, changing the sequence for most used taxable documents in the journals. In demo data, includes taxpayer type to "1" Change label to a singular Optimize view of taxpayer type in view -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#40877
Original PR description
Description of the issue/feature this PR addresses: Change the order of documents, changing the sequence for most used taxable documents in the journals. In demo data, includes taxpayer type to "1" Change label to a singular Optimize view of taxpayer type in view -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#40877
Adding the implied users in a group is done automatically when adding the implied_ids. Moreover it is done in SQL, bypassing record rules. Asymmetrically, the users are not removed when removing a group; it is done manually. However, since this is done via the ORM, it takes record rules into account so some users might not be visible. The standard case where this happens is multi-company. Take the case of some mutually exclusive groups, TaxB2B and TaxB2C, and a user U in company C1
Original PR description
Adding the implied users in a group is done automatically when adding the implied_ids. Moreover it is done in SQL, bypassing record rules. Asymmetrically, the users are not removed when removing a group; it is done manually. However, since this is done via the ORM, it takes record rules into account so some users might not be visible. The standard case where this happens is multi-company. Take the case of some mutually exclusive groups, TaxB2B and TaxB2C, and a user U in company C1 and C2, in TaxB2B. In company C2, change the settings to TaxB2C. U is in another company, so U is not removed from TaxB2B. But then U is added to taxB2C, which causes a validation error. opw 2118337 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#41022 Forward-Port-Of: odoo/odoo#41010
Forward-Port-Of: odoo/enterprise#7068
Original PR description
Forward-Port-Of: odoo/enterprise#7068
Task : https://www.odoo.com/web#id=2149474&action=327&model=project.task&view_type=form&menu_id=4720 Forward-Port-Of: odoo/enterprise#7051
Original PR description
Task : https://www.odoo.com/web#id=2149474&action=327&model=project.task&view_type=form&menu_id=4720 Forward-Port-Of: odoo/enterprise#7051
Open Bank reconciliation, deactivate some record (-), go to "Manual Operations" tab, add Analytic Tags using the "Search More" functionality. Resulting tag will be blank and impossible to delete. This is because: 1) The field shown is the display name, which is missing. 2) When selecting analytic tag(s) this way an array of results is returned but it is not handled correclty by the view. When selecting the analytic tag from the drop down menu a single value '{id: , display_name: }' is
Original PR description
Open Bank reconciliation, deactivate some record (-), go to "Manual
Operations" tab, add Analytic Tags using the "Search More"
functionality.
Resulting tag will be blank and impossible to delete.
This is because:
1) The field shown is the display name, which is missing.
2) When selecting analytic tag(s) this way an array of
results is returned but it is not handled correclty by the view.
When selecting the analytic tag from the drop down menu a single value
'{id: , display_name: }' is returned.
opw-2146833
Forward-Port-Of: odoo/enterprise#7038According to ISO specifications, field InstrId have a maximum length of 35 characters. opw-2145771 Forward-Port-Of: odoo/enterprise#7048 Forward-Port-Of: odoo/enterprise#7000
Original PR description
According to ISO specifications, field InstrId have a maximum length of 35 characters. opw-2145771 Forward-Port-Of: odoo/enterprise#7048 Forward-Port-Of: odoo/enterprise#7000
A new constraint in account for account.move.line makes us have to be more robust in the way we import the multicurrency entries. That constraint makes sure all journal items for an account with a currency set have the same currency. https://github.com/odoo/odoo/commit/eb7d1f30fadd73baeeae46c01ccd20575c06a5c0 Forward-Port-Of: odoo/enterprise#6671
Original PR description
A new constraint in account for account.move.line makes us have to be more robust in the way we import the multicurrency entries. That constraint makes sure all journal items for an account with a currency set have the same currency. https://github.com/odoo/odoo/commit/eb7d1f30fadd73baeeae46c01ccd20575c06a5c0 Forward-Port-Of: odoo/enterprise#6671
…able steps to reproduce: -install contacts -go to settings>translations>languages and activate a second language, for example Ukrainian as it has been fully translated in 13.0 -switch to the Ukrainian language, go to contacts and open the map view you can see the fields are not translated they do not appear in the web_map.pot either translation seem to not happen because the templates.xml file was not living in the static/src folder the fields "Name" and "Address" are part of th
Original PR description
…able steps to reproduce: -install contacts -go to settings>translations>languages and activate a second language, for example Ukrainian as it has been fully translated in 13.0 -switch to the Ukrainian language, go to contacts and open the map view you can see the fields are not translated they do not appear in the web_map.pot either translation seem to not happen because the templates.xml file was not living in the static/src folder the fields "Name" and "Address" are part of the contacts_enterprise module (so they will appear in contacts_enterprise.pot, not web_map.pot) the pot file of the contacts_enterprise module was not named properly previous behavior: most fields inside the map view and the buttons are not translatable current behavior: all text inside the map view is translatable except for the "zoom in/out" labels (they are part of a third party library) opw-2144401 Forward-Port-Of: odoo/enterprise#6965
- Create a Reconciliation Model and set 'Journals', e.g. Bank - Create a payment in the Bank journal - Open the Payment Matching The model created is not available. In the case of the Payment Matching, `state.st_line.journal_id` is `undefined`, so it is always filtered out. Since the filtering should only apply on the Bank Statement Matching, we do not filter out them in Payment Matching. opw-2149154 Forward-Port-Of: odoo/enterprise#7052
Original PR description
- Create a Reconciliation Model and set 'Journals', e.g. Bank - Create a payment in the Bank journal - Open the Payment Matching The model created is not available. In the case of the Payment Matching, `state.st_line.journal_id` is `undefined`, so it is always filtered out. Since the filtering should only apply on the Bank Statement Matching, we do not filter out them in Payment Matching. opw-2149154 Forward-Port-Of: odoo/enterprise#7052
When using mexican localization trying to reconcile some invoices will lead to a python traceback because the backend will attempt to store a date as datetime. opw-2148903 Forward-Port-Of: odoo/enterprise#7027
Original PR description
When using mexican localization trying to reconcile some invoices will lead to a python traceback because the backend will attempt to store a date as datetime. opw-2148903 Forward-Port-Of: odoo/enterprise#7027
Steps to reproduce: -Install contacts -Go to contacts > map view > click on "View in Google Maps" You can see the adresses loaded are mostly duplicates, not all the available adresses are loaded either Previous behavior: The map pointers on Google Maps load a fraction of all the addresses and the pointers loaded are mostly duplicates Current behavior: Google Maps receives all unique sets of coordinates opw-2144374 Forward-Port-Of: odoo/enterprise#7036 Forward-Port-Of: odoo/ent
Original PR description
Steps to reproduce: -Install contacts -Go to contacts > map view > click on "View in Google Maps" You can see the adresses loaded are mostly duplicates, not all the available adresses are loaded either Previous behavior: The map pointers on Google Maps load a fraction of all the addresses and the pointers loaded are mostly duplicates Current behavior: Google Maps receives all unique sets of coordinates opw-2144374 Forward-Port-Of: odoo/enterprise#7036 Forward-Port-Of: odoo/enterprise#7001