The priority widget did not handle the readonly concept
It was therefore possible to set the priority of
an issue (for instance) even if the field was marked
as readonly.
opw-628960
Adaptation of afe4a97d03, but we properly unlink the timesheet lines themselves instead of going for the account.analytic.lines like the original commit proposition did. Actually, the unlink method of hr.analytic.timesheet already unlinks the corresponding acount.analytic.line, but those records were previously deleted via ondelete='cascade', which didn't trigger the unlink method at all, so the associated analytic lines were not deleted accordingly.
Fixes opw 628256.
The natural order was discarded when merging results with a set,
and this was actually un-necessary as the second search()
excludes the previously found `ids`.
In the rare places with a m2o field to product.template
(e.g BoMs), it is necessary to be able to search on product
codes, EAN, etc, the way it works on product.product.
This is done by delegating the name_search to product.product
and then returning the corresponding templates.
This has a small penalty of executing name_get() twice,
but is simpler and more robust for future changes.
An alternative would have been to extract the name_search()
method into a mixin and mix it on both product.product and
product.template. However this would be more brittle and
only work as long as the name_search implementation strictly
uses fields that are present in both tables.
OPW 626662
It looks like it was possible to pass vals['date']
in date format (!= datetime format) to _create_analytic_entries.
This rev. is a retrocompatible patch for 73f7a2ba35.
In addition, it solves the same issue than the rev.
73f7a2ba35, but in the case the project is
set on the task after the work hours are created.
See ab5ecef476
opw-628729
In ir_ui_view.py, in method render (line 132 atm),
the values passed to the rendering engine is a merge of the context
and the values.
Therefore, if at this place, the language is rightly set in the context,
the report lang will be as well in the values.
In abstract_report.py, the values passed to the render method is the
wrapped report localcontext in which are added some key/values
(docs, doc_ids, doc_model).
By default, the lang in the localcontext is False
See __init__ method of rml_parse class in report_sxw.py.
If setLang method is not called, the lang in the localcontext remains False.
In this rev., we avoid to overwrite the lang from the context by the lang
of the localcontext if this one is False, so the lang of the report is set
with the current context lang.
Forcing the lang of the report to False had as side-effect to prevent the
editing of report using the website editor(e.g. playslip_report)
opw-628720
- Translations lookup normally uses the namespace of the current
QWeb template, after merging all inherited views.
But when a QWeb template is "cloned" by a child view using
inheritance with `primary` mode, the translations are more
likely to exist for the original (parent) template, and would not
be found when using only the "child" namespace.
This patch adds support for looking up each translation
also in the parent namespace in this case, if none was found
for the child template in the first place.
- ir.translation's _get_source() now supports a list of res_id
to search for, in addition to a single res_id
- Also moved the logic of routes /website/customize_template_get
and /website/get_view_translations to the ir.ui.view model where
it belongs.
opw: 615241
Closes#5325
The tasks list view "act_project_project_2_project_task_all"
always displays inactive tasks ("'active_test': False" in context).
Both the link in the kanban and the button in the form
leading to this list view should therefore counts both
inactive & active tasks.
opw-628672
When having account installed, but having as only
access right "Contacts creation", it wasn't possible to
display the partner form.
Setting the "groups" on the button itself has as effect
to hide the button, but not to prevent its value computation.
If you did not had the access rights required to compute the
buttons values, it leaded to security issues.
Put the "groups" on the view instead prevent the button to be loaded,
and its value to be computed. It therefore avoids both
a useless computation (computing the value of a hidden button
is not really useful), and prevent any access rights warnings.
Besides, 3 different groups were needed to display the
three buttons:
- account.group_account_invoice
- account.group_account_user
- analytic.group_analytic_accounting
Not having one of these tree groups could lead to security
warnings. We therefore split this view into three sub-views,
with each one a group set (and a button)
opw-628668
In calendar, using recurrent events leads to the use of
virtual ids, which are strings.
It wasn't possible to change the message subscriptions
for recurring events,
neither for the user himself, neither for the other followers
opw-627895
27a48f8026 introduced the use of self.dataset
It appears it is not always defined.
Few lines above, self.getParent().dataset is used,
and looks to be always defined.
We therefore now use this dataset in order to get the context,
to correctly pass the current session language.
Closes#5416
When a delivery order is confirmed, pass the user language to the
procurement creation so the messages in the chatter are now translated
in his language.
opw 627002
Traceback because id was not casted: AccessError: ('AccessError', u"Database fetch misses ids (u'1') and has extra ids (1), may be caused by a type incoherence in a previous request")
default_get method of mail.wizard.invite model uses
the key 'default_res_id' to retrieve the res_id of the record
to add the followers.
In the case of recurrent events, virtual ids are used, and
the conversion from virtual ids to real ids is needed.
Pass the context, with the language setting, when the record is read to
fill the google drive template. That allows to translate the name of the
document and all the informations inside.
opw-626675
This rev. reverts partially 1d76586a1b
This rev. is related to #3462
Regarding addons/web/controllers/main.py
---
name of model ir.actions.actions is not translated
it's the name of server actions, client actions and window actions
that are translated.
Meaning the name of the ir.actions.actions will always be in English,
even when passing the user language within the context.
Regarding addons/web/static/src/js/views.js
---
There is no reason to pass the field values within the context
of the /web/action/load call: The read methods of actions are
not overidden to use the field values. Besides, it pollutes
the context of the action, leading to unwanted behavior, such
as the translation of the action name within the lang available in the
fields of the form view (e.g. the partner form).
Initially, the field values added in the context has been added
within the rev. 542928adde
Indeed, sidebar_context (or sidebar_eval_context nowadays), contains
the field values, and the additional_context passed to /web/action/load
is an extension of this sidebar_context.
We are not sure the reasons why the sidebar_context was passed to the
/web/action/load, but we believe it was to pass the session/user context
containing the lang, timezone, and so on, not to pass the fields values.
The delivery module overrode the method _create_invoice_from_picking
to add the shipping costs according to the invoice and the shipping.
The issue is that the method _create_invoice_from_picking creates an empty
invoice, without any line. The lines are added afterwards, using the method
_create_invoice_line_from_vals, within the method _invoice_create_line.
So, after having called _create_invoice_from_picking, the invoice is indeed
created, but without lines, and therefore without the amount total value.
Adding the shipping costs there will thus prevent the shipping costs
based on the total price of the invoice (e.g. free for an order of 500€)
This rev. overrides the method _invoice_create_line instead, as, after
the call to this method, the invoice will be completely set, with all
its lines, and with a correct amount total. The side effect
is that we need to recompute the taxes a second time, using button_compute.
This is not the cleanest way to solve this issue. Indeed, a cleaner patch
would be to change the method _create_invoice_from_picking so it creates
the invoice along with its invoice lines, using the ORM command
(0, _, values) to creates the lines directly within the invoice creation:
invoice['invoice_line'] = [(0, _, values) for values in invoice_lines_vals].
Nevertheless, this is a bigger change, that will probably require API changes,
and therefore should be done in master.
opw-626226
opw-628517
Many trivial changes to journal items, such as the
"blocked" flag for litigation (follow-up), do not affect
the balance of the whole entry. These should not cause
the account.move to be (re)validated.
For example it should be possible to change trivial
fields even on journal entries recorded in a closed
fiscal period.
Setting an expense with a tax included with a negative base code sign was
getting the wrong amount (tax line as a credit instead of debit). So leading to
a total for the accounting entry superior of the total of the expense (should
not happend as the tax is included).
Add test to verify this scenario.
Fixes#4260, opw 618531
The quick creation and account record opening in the sheets are not useful.
Besides, restricted users (simple employees) have no read access on account.account.
opw:626989
In the website editor, the translations are loaded using
the route 'get_view_translations', which returns the translations
of the templates loaded by the website (t-call calls)
The thing is, report templates use the 'translate_doc' method
to actually load the report, translated in the partner language,
and the templates loaded by this method are not seen by the website,
therefore, when calling 'get_view_translations', those report
templates were just ignored, thus their translations are not loaded.
This rev. injects the templates loaded with translate_doc
when rendering the report into the method 'customize_template_get'
(which is used by 'get_view_translations' to retrieve the loaded templates).
The translations of the reports are therefore now loaded corretly when
hitting the "translate" button in the website editor for reports.
Besides, this rev. has as (good) side-effect to add the template,
in the template selection input when editing using the HTML editor.
opw-620713
Without this, if the user creates a second line (or more) with another search query and presses tab (or clicks somewhere else) quickly, it will take the previous search result instead of the new one because the new one did not occur yet.
With this fix, if the search did not have time to process, the Create a product modal appears, just like it already did for the same behavior on the first line.
Fixes 620679.
Denis Ledoux
David Monjoie
Christophe Simonis
Olivier Dony
Vijay Baladaniya
Fabrice Henrion
Josse Colpaert
Jeremy Kersten
Goffin Simon
Arthur Maniet
Denis Michiels
Goffin Simon
Vicente Jimenez Aguilar
Somesh Khare
Anthony Muschang