The calendar module generates string values with
a date/time formatted according to the user
language. Those formats may contain non-ascii
characters and are read as unicode strings,
but fed to str{p,t}time, which only accepts
byte strings (in Python 2).
This would cause an exception when loading calendar
notifications for a user using e.g. Chinese with
some CJK unicode chars in the date/time format.
There was two problems:
* it was filtering on the probability of the opportunity, not on the
probability of the stage
* the filters were not prefixed with '&', which means that they gave
weird results when combined in the searchview (in a filter group, filters
are combined with '|', but it breaks when the filters are defined by
an implicit '&')
This rev. 7307227 ensured to not (re-)set the state 'confirmed' to exploded moves with a more advanced state (for instance, 'assigned')
Nevertheless, the location chaining is performed on the move confirmation, through the action_confirm method of the stock.move model. Besides, the resulting moves of the _action_explode method had the state 'confirmed' on creation, the 'confirmed' state wasn't set by the method 'action_confirm', meaning that the moves were confirmed without having the location chaining done. Allowing moves to go through the action_confirm method even if the state was 'confirmed' or further triggered the location chaining.
Preventing already confirmed moves to go through the action_confirm method prevented the location chaining, thus.
We now create the resulting moves with the 'draft' state, and then confirm them through the procurement workflow signal 'button_confirm'. Thus, the resulting moves are confirmed by going through the action_confirm method, writing the confirmed state and triggering the location chaining at the same time. We then write the 'assigned' state if necessary.
opw-617235
Changing the decimal precision of float fields is a rare
operation, while cache clearing occurs fairly frequently.
Signaling a full registry change when the decimal precision
is changed (instead of a mere cache change) is therefore
a better trade-off, and more semantically correct as well.
This way we avoid the decimal precision refresh for each
invalidation.
Registry invalidation implies cache invalidation.
The company_logo is cached and was not refreshed when switching between database, still showing the logo of the company of the previous database
Fixes#2738
For privacy_visibility 'followers' or 'portal', the user should be follower of the project (not the task).
Remove public access to portal task
Fixes#2372
If no project on the task (or other rule), an employee (not a portal) can access if is follower of the task.
Follower rule is not enough as a user creating a rule will subscribe to the rule but to subscribe to record, the user should have access to it in the first place.
To make sure the snake does not bit its tail, fallback to give access on task where the user is reponsible (user_id = user.id).
Fixes#139
Adapted the tests to the new behaviour (removed not relevant and added some on creation)
Use if_dom_contains to check if we need to load js
Fix bug where _tag_to_write_vals was called like old API but model converter was new api
Move IsKarmaValid and Load CKE only in website_forum context
Since bank statement do not use vouchers anymore in 8.0,
it's not necessary to create the voucher anymore.
Additionally, I add an extension point to let modules adapt
the statement line.
The delivery of a purchase order was not keeping the currency and cost price
from the purchase order for the reception. This was problematic for orders where
the invoice was generated from the picking (Invoicing Control: Based on incoming
shipments). The currency of the purchase order was kept while the cost was the
one in the company's currency.
It's better to keep the currency of the purchase order to make the invoice as
it's usually the one expected (and not convert everything to the currency of the
company). opw 615555
This rev. 06104ba553
Added the dirty flag on the o2m field when the editor of the editable list was enabled (meaning that the editable list has been altered)) because the dirty flag was not set correctly by the one2many during the edition, at the time.
It looks like this is now the case
Besides, as now, we valid all the editable list of the form, wether or not the editable list was altered, we must not set the o2m as dirty anymore.
First, name_search searches on default_code, then, if the limit is not reached, it searches on the product name
The results found from the default code search must be removed from the search domain when doing the search on the product name, to avoid having results already found by the search on the default_code
opw-618015
When a picking is confirmed, the generated account.move(.line) should take the
company, accounts, journals and period with the same company as the picking,
not the one of the current user.
This was problematic if a user in a company confirm a picking linked to
a purchase order done in another company.
For real time valuations, the generated accounting entries were mixing both
companies.
Fixes#3466
The name of a vehicle is function field.
The field odometer on a vehicle has a a setter that creates an odometer.
The name of an odometer is a function field that uses the name of the vehicle.
If a vehicle is created with a value in odometer field, the odometer is created before the name is computed so the concatanation would fail.
Fixes#3468
Olivier Dony