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

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

This commit lints JS files located in survey as some typos and mistakes
were recently introduced. Code related to routes is also slightly reorganized
to better understand file main sections.

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 survey.user_input.line, clean code about constraints. Purpose is to make
it easier to read and understand.

Code creating user input lines is moved from survey.user_input.line model to
survey.user_input. Indeed it is now based on a user_input record, and create
answer line related to a question, based on values coming from controllers
(and therefore frontend). It makes more sense to delegate that code to the
user_input model itself that creates its lines. Code is also rewritten to
be cleaner and easier to read.

Code computing statistics on user input records is moved from survey model
to user_input model, where it belongs. Missing translation marks are added
because translations matter.

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

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

``question_ids`` field name is quite difficult to understand as we wonder why
there is such a field on user input model. As its purpose is to store questions
user has to answer (randomly chosen or all chosen) let us rename it to
``predefined_question_ids``.

Moreover starting from now on if it is now given at create it is automatically
computed. Classic flows go through ``survey._create_answer()`` method that
prepares them accordingly. However tests or demo data do not necessarily go
through that method and it makes scoring fail (notably) if people forget
to define them.

Let us automatically generate them at user input create if not given.

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

A new naming 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 indicates the use;

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 QUIZ_SCORE ON SURVEY.USER_INPUT

On survey.user_input, quiz_score field to scoring_percentage

``quiz_score`` field name is related to the old "quiz" behavior of surveys
that is replaced by certifications and scoring mechanisms. Let us propagate
the renaming, beginning with a ``scoring_`` prefix.

SPECIFICATIONS: RENAME QUIZZ_PASSED ON SURVEY.USER_INPUT

on survey.user_input, rename quizz_passed field to scoring_success

``quizz_passed`` field name is related to the old "quiz" behavior of surveys
that is replaced by certifications and scoring mechanisms. Let us propagate
the renaming, beginning with a ``scoring_`` prefix.

SPECIFICATIONS: RENAME TOKEN ON SURVEY.USER_INPUT

on survey.user_input, rename token field to access_token

Survey user input model holds two token field. One is used to distinguish
a pool of attempts linked to a given invite: ``invite_token``. The other
one is used to control access to a specific user input. It means that
``invite_token`` indicates a set of user inputs and each of them is accessed
through its own ``token``. To be coherent with other naming in odoo this
latter field is renamed to ``access_token``.

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

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.

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

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: QUESTION FIELD ON SURVEY.SURVEY

On survey.survey, remove question field, unnecessary related on title.

Question model holds two fields for its title: ``title`` and ``question``.
Question is simply a related on title, making the two fields completely
redundant. It is mainly due to historical reasons, when updating models for
certifications and eLearning. In this commit we keep only title field and
remove the question related field as it adds unnecessary complexity to the
model.

SPECIFICATIONS: INPUT_TYPE FIELD ON SURVEY.USER_INPUT

On survey.user_input, remove input_type and its garbage collect.

``input_type`` field exists on user input model to tell whether answer has
been created through invite or through manual click on a survey page. It
has been added a long time ago when surveys were either open to everyone,
either closed and on invite only.

Since eLearning and certification surveys access mode on surveys has evolved.
Notably being able to distinguish invite from manual survey user input is not
necessary anymore. Indeed what is important is the way people can reach the
survey, not how they created their user input.

Invitation creates token and this can be used if people effectively want to
find invitation-related user inputs.

Since 09ea5c7d manual entries still in draft are garbage collected.
Reason is still unclear as it is not obvious that tons of unnecessary entries
will be created. As this seems like unnecessary optimization this commit
removes that feature along with the input_type field.

SPECIFICATIONS: REPLACE URLS FIELDS BY METHODS ON SURVEY.{SURVEY, USER_INPUT}

On survey.{survey, user_input}, remove url fields replaced by methods

In this commit we remove some remaining of URL fields that are better found
using methods. Both survey and user input holds a "start" url field that is
replaced by a method call ``get_start_url`` on both survey (generic) and
user input (token specific) models. We also introduced a ``get_print_url``
method doing the same for the printable version of survey / user input.

SPECIFICATIONS: REMOVE CATEGORY FIELD ON SURVEY.SURVEY

On survey.survey, remove unused category field.

Survey model holds a ``category`` field whose purpose is to be able to somehow
categorize surveys according to their use. However using this field is not
easy as it is hidden and is a simple selection field. Module should add their
own key. Its sole use is in ``hr_recruitment_survey`` which is a niche module.
Let us clean models and lessen model complexity.

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

Add math floor and ceil functions in qweb rendering context. It allows to use
some math methods directly in templates to avoid unnecessary data preparation
in controllers that lead to a lot of hard to read code mixed with important
code. Notably in survey we will use them for some pagination within statistics
rendering.

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

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

closes odoo/odoo#41419

X-original-commit: 42ae9ce544605314d969ae1210245f5b5bbf2628
Related: odoo/enterprise#7073
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>

closes odoo/odoo#41142

X-original-commit: fdbabfdc
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>

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.

closes odoo/odoo#38397

Task: #2074822
Related: odoo/enterprise#5887
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>

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.

closes odoo/odoo#41415

X-original-commit: b5020a44
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>

When the adapation without jQuery promise was done for 12.3 (in
bfed5742) 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) => so we have deadlock and interface does not allow to
save or do any other change.

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 bfed5742 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
closes #41346

closes odoo/odoo#41406

X-original-commit: cc73abb218e17756b21824a192f4461eb8537c0e
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>

closes odoo/odoo#41404

X-original-commit: 6af602fa676db19260a828a3cfd0befe3ba1ef4e
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

- Some layout broken when a scrollbar appeared
- The edit icon of background disappeared when the filename was too long

X-original-commit: d3419fed27147c92e673fb367657db8865a0d538

Some debugging lines were introduced in https://github.com/odoo/odoo/commit/30cf7bc798ddede8e610001146f4a76352aa582f


Those should be removed

closes odoo/odoo#41400

Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>

We must delete the folder "MOUNT_POINT" before the "zerofree"

closes odoo/odoo#41399

X-original-commit: 4dffb76f
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>

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 0a5955bf explicitly removed from the `_order`.

opw-2145878
opw-2147922

closes odoo/odoo#41396

X-original-commit: f4571e2f
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

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.
This change fixes the field used in the customer-facing template to
display the payment status of the invoice.

closes odoo/odoo#41394

X-original-commit: d1d83ee53c8274c1cb44f1cd7440e73a9eba9bef
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Co-authored-by: Igor Ishchenko <igor@cruxlab.com>

opw-2125858

closes odoo/odoo#41371

X-original-commit: d19982b7
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

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.

closes odoo/odoo#41378

X-original-commit: fd08d04f
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>

Description:
- Add readonly attribute to partner view for l10n_cl_sii_taxpayer_type field for children res.partner records.
- Fix the tax payer type label to prevent usage of "label for.."
- Optimize document type order to put most used on top of file and in selection of document types during invoicing process

closes odoo/odoo#41372

X-original-commit: 4162b9b6
Signed-off-by: Josse Colpaert <jco@openerp.com>

Execute the tests from ea574fe9 and 9e9ac5ce,
which are in a SavepointCase.
The second test fails on a cache_miss.
Whats happens is the following:
 - the second test starts with the environment from the beginning of the
   first test. However its envs has a reference to environments that
   were created during the first test.
 - when computing the field, the ORM finds the value in a zombie
   environment, so does not recompute it
 - when trying to get the value, the value is not in cache

The issue is that going through res.config.settings's execute resets the
envs.

One solution is to put:
    self.addCleanup(lambda: setattr(self.env.envs, 'envs', envs))
in SavepointCase's setup.

However in that case the reset is not needed at all:
it's necessary only if there were some modules to install.
Unfortunately to_install and to_uninstall are not symmetric:
to_uninstall contains only modules that should be uninstalled, whereas
to_install contains everything, and only filters later what actions
really need to be performed.

In this case, we can rely on the result of the installation process.

closes odoo/odoo#41126

Signed-off-by: Nans Lefebvre (len) <len@odoo.com>

Initial issue solved by 3eb06a27
We keep the test since it ensures that settings can be saved properly.

X-original-commit: 2c1b92f6

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

closes odoo/odoo#38694

Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>

The method `unlink` checks whether any of the records to delete is used
as the default value of a company-dependent field.  The query simply
blows up when deleting several millions of records.  The fix consists in
performing the check in batches.

closes odoo/odoo#41331

X-original-commit: 30e8b8f2
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>

Fix error like "TypeError: {4} is not JSON serializable" when
serializing the session object (e.g. for external storage)

closes odoo/odoo#41360

X-original-commit: e91e38fa
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>

If a module add a state field on another table used by this report,
PostgreSQL will report a:

```psycopg2.ProgrammingError: column reference "state" is ambiguous```

closes odoo/odoo#41350

X-original-commit: 16ae8aed
Signed-off-by: Nicolas Seinlet (nse) <nse@odoo.com>

- we would have to set this domain on every actions directing to
products
-we can't set a proper depends_context since the new orm doesn't support
it

closes odoo/odoo#41322

Related: odoo/enterprise#7033
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>

This context key was used to get the valued quantities. We now have a
`quantity_svl` computed field that does this job. The test is removed,
it was showing that intercompany quants are visible thanks to a context
key but with the introduction of the on_hand filter, it is now useless
(just remove the filter)

tax grouping key from base and tax line that will be used as a key to group taxes together
so both functions must have the same dictionary key. (you can check comment here https://github.com/odoo/odoo/blob/13.0/addons/account/models/account_move.py#L412

)

here we have three key (product_id,product_uom_id,quantity) in _get_tax_grouping_key_from_base_line
and only one key (product_id) in _get_tax_grouping_key_from_tax_line

so we get wrong tax calculation

now we remove that extra key(product_uom_id, quantity) because we don't need group by these key values.

closes odoo/odoo#41340

X-original-commit: a758e5ea
Signed-off-by: Josse Colpaert <jco@openerp.com>

task-2121584

closes odoo/odoo#41339

X-original-commit: 565f42cb
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>

closes odoo/odoo#41320

X-original-commit: b25922f77279eaf09800486954fe79b246ea105b
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>

Task 2148441
The main language is now english, translated in indonesian.

closes odoo/odoo#41266

Signed-off-by: Josse Colpaert <jco@openerp.com>

Before this commit, when doing a primary inheritance
the root node of the resulting template was the one of the inherited template

after this commit, the root node of the resulting template is the one defined
on the inheriting template

closes odoo/odoo#39452

Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>

Before this commit, when a template was inheriting from another
the template mentionned its t-inherit

This has been deemed overkill as the information is irrelevant to the caller
i.e. the caller just wants the template and doesn't care how they've been computed

After this commit, only t-name and attributes not related with inheritance
are disclosed

[FIX]: base: static inheritance propagates other attributes

When doing a inherit in primary mode, the original attributes on the root node of
the inheriting template were not propagated

After this commit they are