Since revs 53582c2ea6 & f65c913027,
this was no more possible for portal users to read groups
on purpose, for privacy reasons.
fields_get of res.users model is overriden, for
the access rights form view features
(The groups selections and checkboxes).
At each call to fields_get, which happens at each call
to fields_view_get on the res.users model, operations are
done on the model res.groups (basically, to
build the selection groups and checkboxes). So,
each time a view of model res.users is displayed,
whatever the view, operations on res.group model were performed.
The thing is, these operations on res.groups
are actually needed only for the user access rights
view, or at least only for users having the group
Administration > Access rights. These group operations
aren't needed for the preferences view, nor for portal users.
We therefore avoid to do these if the user is not part of the
Administration > Access rights group, which lead to
performances improvment, and solves the fact
portal users couldn't access their user preferences view.
opw-627391
When auto subscribing to a message
(For instance, change the ```user_id``` field on a record,
like an invoice)
The new user is notified of the last message of the thread.
He must be notified of the parent message as well,
to have access to the first message of the thread,
to prevent access rights issues to the thread.
This mechanism is applied in the _notify method
of model ```mail.message``` as well, for the same reasons.
opw-630286
The timezone of hr_analytic_sheet should be the timezone
of the employee as well, so sheet analytic lines and attendances
lines are grouped within the same timezone, the timezone
of the employees, so the time difference between the analytic
lines and the attendances lines can be properly computed.
Fixes#5809Fixes#5379
Related to rev. 3bf1615ad4
The BBA communication is now only checked when provided as input
(created or modified).
Avoids useless check for uniqueness when it's not modified, and
prevent errors when several invoices are modified in batch.
opw: 629649
Closes#5700
In the accounting settings, we prevent having gain and loss accounts that are linked to a
different company than the one selected for the chart of account.
opw: 630494
The sequence for new items in some models is simply set to a constant 10.
Hence if 3 items had after reordering sequences 10, 11 and 12. If a new item is
added, it would get after saving at the second position.
This fix set the sequence of a new item to the maximum+1 or minimum-1 sequence
of current items sequences (max if tree has editable="bottom", min if tree has
editable="top").
opw-627830
The result of the residual amount of an asset is : asset.purchase_value - amount - asset.salvage_value
where purchase_value and asset.salvage_value are in the currency of the asset. Amount is the difference
between debit and credit of an account move line expressed in the currency of the company.
This is why the amount must be convert in the currency of the asset.
It is possible, if the user created a new country by himself, to have a country without a code, we then need to check that.
Fixes opw 629891, where the customer wrote "Belgie" trying to find "België", didn't find it and created a new "Belgie" country without code.
It's always dangerous because (cascade-)deleting workitems
has a great chance of killing the workflow instances they
belong to, putting the records in the workflow limbo
permanently. (They will appear stuck as they don't have
enough workitems anymore)
In addition, in some rare cases a subflow activity is
converted into a regular activity during an update, and
nullifying the `subflow_id` column is all there is to
fixing the corresponding workitems. It will simply take
them out of their subflow, and back into the main flow.
This is the case for the modification of the purchase.order
workflow in Odoo 8 (saas-5), for the picking subflow.
The test for account followup use UTC time, but the default `date_maturity`
and `date_due` of an account invoice come from fields.Date.context_today`.
One failing test for project_timesheet also used `today` instead of
`context_today`.
So depending on the test user timezone, an error of one day (if UTC time
and user time are on different day) occured which failed the tests.
For example:
* user has GMT+1 timezone, test fails 0:00am–1:00am (11:00pm-0:00am in UTC)
* user has GMT+3 timezone, test fails 0:00am–3:00am (9:00pm-0:00am in UTC)
This fix removes UTC use in the tests.
After discussing with jco, we decided to keep it simple and have a coherent behavior between different versions, we then changed the behavior from the one of jbefficient PR at 92adf673f7.
Allows exporting fields whose string is a non-ascii *byte*string (rather than unicode).
backport of 7286f4e424 fixing #773 to branch 7.0 by request of @flotho
Amount in payment order is not correct if the account move
line has already been paid by another way. The right amount is
in the residual field related with move_id to the account invoice.
opw:628903, 628428
Text fields, or char fields having widget="text",
were not sized correctly when the field was not
visible by default, ans was set visible thanks
to attrs and other fields values.
opw-629394
Before this revision, the overdue payments report contained all payments due,
including the ones in the future, that are not actually due yet.
opw-628874
When the ORM is cleaning up related attachments upon record deletion, the
search() method hides the attachment of the record that is being deleted.
If the same file is used exactly once in another attachment, the reference
count will be 1 and the file will be deleted.
When setting a partner on the lead,
the on_change_partner method retrieves
the various partner field values.
title & function fields were omitted, without obvious reasons
opw-629374
Closes#5388
It wasn't possible to create a new dashboard,
as a user other than SUPERUSER_ID,
using the "Create board" menu specifically
Reporting > Configuration > Create Board
(Technical Features & Administration > Settings groups required)
Because it creates a new menu for this dashboard,
which lead to the automatic creation of an "ir.values" record
which is prevented for other users than SUPERUSER_ID
opw-629367
In a timesheet, when a sign in is added, and a sign out
is not following, the current time is took as sign out value.
Rev. dbb2a669f4 corrected an issue
regarding the worked hours summary not taking into account
the employee timezone.
This timezone has to be applied on the current_time also.
e.g: For an employee being in timezone UTC + 1
If the current_time is presently 12:00 (UTC+1)
If the employee set his sign in to 10:00
and do not entered a sign out
The hours summary table displayed 1:00 of worked hours,
based on computation (11:00 - 10:00)
11:00 being 12:00 but in timezone UTC
Besides, another issue was present when entering
a sign in at midnight exactly without a sign out:
If the employee set his sign in to 00:00:00
and do not set a sign out, worked hours displayed 0 worked hours
whatever the current time.
Fixes#5379Closes#5378Closes#5503
When accessing an existing record in form mode directly (enter the url or refresh a page), the daterecord has not been initialized yet. This means that the value of actual_mode will be set to 'edit' before loading the current record (method _actualize_mode() called from do_show()).
This was problematic for one2many fields that we loaded in edit mode, showing add/delete icons/buttons in readonly views. (opw 607910)
Backport of 7ec7f1ba40 for 7.0 and saas<6. (opw 627885)
When the number of records n and the limit l were such that n%l = 0
(e.g. 16 records total, 8 displayed per page), clicking on the
previous button on the first page, or on the next button on the
last page produced a bug because the total number of pages
computed for this edge case was incorrect.
When selecting a product in a sale.order, the asked quantity is verified against
the available quantity.
If the user changes the UoM or the onchange from super call changes it,
the context should be updated accordingly.
Fixes#2559
The precision 'Product Unit of Measure' was defined after the declaration of kg.
Since fc85a7ee, the precision of kg is set in data to 0.001.
As the Product Unit of Measure was not defined yet, the rounding was stripped to
(16,2) precision, so getting a rounding of 0.0 for the kg unit of measure.
[FIX] product: the declaration of decimal precision was done after
the declaration of uom precision, preventing uom precision from going above
the default decimal precision. + made the Kg unit precise up to grams by default.
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
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.
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
Module 'Warning' overwrites onchange_product_id method of purchase.order.line
The signature in the warning module had 'notes', while there isn't any 'notes'
parameter in the original method, in the purchase module.
The super call was also wrong, ignoring the optional fields, which
were therefore always set to the default value
The name must be changed when changing of product,
but not for other changes, quantity for instance.
The 'or not uom_id' is just for retro-compatibility concerns
uom_id being False actually means we just changed of product,
and the name must therefore be changed
name as been set as False in the onchange call in the view
for the product_id field, in this rev.,
so the name being False now means th change of product
Nevertheless, existing databases for which the view
is not up to date won't have this change
and we therefore have to rely on something else to know
when the product has been changed or not.
fixes#5295
opw-628138
When you change the country of your company, each field of a company address keeps
its attrs. This is why the company address stays on readonly when use_parent_address
is checked.
Closes#4808
opw: 627033
When clicking on an element in a listview editable, the record_id
is not updated in the dataset, which means that when you switch to form
view, the list view does not display the last selected record.
Also, it should fix the issue solved by PR pull/2725
Loïc BELLIER
Denis Ledoux
Goffin Simon
Nicolas Martinelli
Nicolas Lempereur
David Monjoie
Olivier Dony
odoo-tac
xmo-odoo
Laetitia Gangloff
jbeficent
Stefan Rijnhart
Romain Deheele
Olivier LAURENT
Holger Brunn
Martin Trigaux
Aaron Bohy
Lionel Sausin (Numérigraphe)
Frédéric van der Essen
Somesh Khare
Anthony Muschang
Géry Debongnie