Before this commit:
In the web_editor in backend, entering edit mode would display differently text
in `div` and text in `p` but not when viewing the content outside edit mode.
Now, `div` and `p` won't have different style when entering edit mode.
We want to force the tax template to be blank always, because multiple companies can potentially use this template to create taxes. We want consistency company-wise.
Since rev. odoo/odoo@cd05983 it was not possible to submit a survey if a date
field was empty (trying to set `toJSON` on `null`).
The datepicker `date` function returns `null` if no date has been selected.
opw-1832381
When sorting events according to some property that is not defined for all
events, Odoo would give a traceback as it would try to compare a boolean to some
other type.
We simply lift every value to a (boolean, X) tuple for any type X in the
sorting key function, thus having values of homogenous type.
opw 1831457
The global link was redirecting to http://getbootstrap.com/components/ (without
the fragment identifier).
Moreover, now that Bootstrap 4.0 is released, this URL may be broken in a close
future.
Closes#24031
Have your user and your system in timezone Sao Paolo
When it is 2200 TZ time, UTC is the day after 0100
Have a activity schedule for today
Before this commit the activity was flagged as overdue.
This was because we compared the date deadline of the activity (no TZ)
to the date.today() in Python
While date do not have TZ legitimately, the moment (and place) you create them matters
Thus, we compared the date of the server (UTC -- day +1) to a date set by the user (TZ -- day -1)
After this commit we make up a date according to the user's tz
And the activity is not overdue, but in state 'today' as it should
OPW 1827920
closes#23969
- Open in debug mode the 'beetle'
- Click on open view
- select a Tree view in the list
Before this commit: A traceback appears
This was because while the Tree view per se has been discontinued
the mode 'tree' of an action must be supported
Which was not the case for this particular widget
After this commit: the list view asked for appears
OPW 1833008
closes#23963closes#24005
We transform the rrule stored as a string into a real
rrule object using 'rrule.rrulestr'. The 'UNTIL' parameter
of the rrule might not be timezoned. So the '_until' property
of the rrule object will be a naive datetime.
Later in the '_get_recurrent_date_by_event', we add the recurring
date in the '_exdate' property, but those dates are timezoned.
When iterating on the rrule set (its a set since forceset=True), the
until date and exdate are compared, but it cause crashes as we can not
compare offset-naive and offset-aware datetimes.
This commit make the rrule use only naive or aware datetimes for its
'until' and '_exdate' properties depending on the 'until' property
of calendar.event rrule field.
opw-1825679
closes#24010
Steps to reproduce the bug:
- Set your user in multi company
- Set a default analytic account A for product P with your company
- Create a PO with P and deliver it
- Generate the invoice.
Bug:
The analytic account A was not set on the line.
opw:1831998
Before this commit, some breaking spaces were present in the js code.
Such spaces are misinterpreted and worked by luck.
This has become a problem with exported js bunldes (e.g. the
external_lib bundle in im_livechat).
This commit replaces breaking spaces by regular spaces.
Correct account invoice line form view so studio doesn't fail on
something that doesn't seem really correct (and somehow worked thanks
to pyeval implementation or the override from another view type).
opw-1826254
opw-1830171
closes#23997
Steps to reproduce the issue in 11.0 Enterprise:
- Go to the language English
- Remove from the time format the seconds
- Refresh the page
- Go to sales
- Create a sales order;
Bug:
- You get the warning message
closes#23596closes#22027
opw:1829577
The code in res config that enabled or disabled internal operation type
did not take into account that active_test is set to False inside this
type of code since c2e259d8.
Thus a picking type of an archived warehouse would possibly unexpectedly
be enabled after saving the settings.
opw-1826196
closes#23956
The state of the JS documentation was quite sad, not updated in a long
time. With this commit, we rework a lot of the JS doc. Most notably,
we add a section 'Javascript Cheatsheet' (help on some common
customization tasks) and rewrite the 'Javascript Reference' totally.
Note that the JS reference page also contains a reference on all field
widgets.
This work is just the beginning, it is probably not complete, but at
least we will have a foundation.
Steps to reproduce the bug:
-Create a tax of 21% tax included but don't select the "affect base" checkbox.
-Create another tax of 5.2% (no tax include)
-Create a sale order with a line that has a unit price of 121 and both taxes.
Notice that the total amount is: 126.2 (100 base amount + 21 from 21% tax + 5.2 from 5.2 tax)
-Click on "Print the proforma invoice"
Bug:
The total amount was still 126.2 and base=100, however taxes were wrong, there were 21 for the 21% tax
and 6.29 instead of 5.2 for the 5.2 tax.
Back-port of this commit: f50a08bc3d
Forward up to saas-15
opw:1819882
- Set the number of digits of 'Product Unit of Measure' to 1
- Create a stockable product:
UOM: Dozens
Purchase UOM: Units
- Buy 17 Units, validate the picking
- Create a landed cost:
Amount: 100
Split Method: By Quantity
- Compute
The Valuation Adjustment line contains contains a line with a quantity
equal to 1.4, leading to a line of 98.60. It is impossible to validate
the landed cost because of the inconsistency.
The method `get_valuation_lines` retrieves the data from the
`stock.move` and copies the following values to the
`stock.valuation.adjustment.lines`:
- `product_qty` > `quantity`
- `weight` > `weight`
- `volume` > `volume`
Therefore, we must make sure that these fields are using the same digits
precision. We adapt the precisions accordingly.
opw-1817783
When you have a receipt in multiple steps and cancel the generated RFQ
the following internal move stay in waiting another operation.
We recompute its state and pass it in waiting.
OPW-1832176
This commit reverts part of f5912cb since the spec changed afterwards.
Unpublished page will have a red toggle, which even if it is small should be
enough to draw user attention, and not a ribbon anymore.
Task-44005
Following commit 340d70338f, we make sure the delivery price
contains the right number of decimals by sending a formatted string
instead of a float. Indeed, due to the float representation, values such
as 25.310000000000002 may occur.
opw-1831656
The commit f1e842bcd2 corrected the Khmer code language but the csv language file was left with a blank line inside.
The csv parsing (to populate the list of available languages) failed into tools.misc.scan_languages() because of the blank line
Commit b6d4cd5deb introduced the auto-reconciliation when reversing
an entry. However, we should make sure to only reconcile non-reconciled
entries. Such an entry can be generated from an exchange rate entry.
opw-1826024
When doing a sudo on top, the fields are accessed with user 1 but the set is
also made with user 1.
meeting.user_id.partner_id.id is correctly computed but
meeting.partner_color_id is not set for the current user (return 0)
All events were in the same color
Introduced at b669c71aa3
opw-1829793
Closes#23923
The correct solution would be to store the total_depreciated_cost on the fleet vehicle.
But this solution is not acceptable on a stable release as it implies to update the module.
The only thing we can do here is to add the dependencies on the field 'total_depreciated_costs'
to the field 'company_car_total_depreciated_costs'.
As the field is not stored, then the field 'company_car_total_depreciated_cost'
(which is stored) is not recomputed correctly when modifying the log_contract.
This solve the following issue: Modify a recurring costs amount (depreciated)
on the fleet vehicle contract, then the final yearly cost on the related
hr.contracts are not recomputed correclty, as the field company_car_total_depreciated_cost
on the hr.contract is not recomputed on the total_depreciated_cost modification.
Purpose
=======
In contract, track fields (create a note, no need subtype. it is just for the history)
- wage
- fuel_card
- meal_voucher_amount
- representation_fees
- additional_net_amount
- retained_net_amount
- commission_on_target
- ip
- car_id
- internet
- mobile
- mobile_plus
- final_yearly_ cost
The code of khmer language was not the offical one. Installing it
produce an error in the Babel python library.
It's not possible to easily fix it by correcting the code km_KM to km_KH
because Odoo
prohibit changing language code. The solution to this is to remove the
Khmer language from the res_lang.csv file and add it to an xml data
file with the correct code. There, we can put on this record the
"noupdate" tag. This tag
will block any modification on the ir_model_data corresponding to the
xml_id=lang_km
and so avoid the error if we update the base module. Old database still
wont be able
to use khmer language (so we'll need to manually change it in database)
but new one created
after this commit will be able to use it without issue.
Before this commit if /foo redirect to /bar?a=1
/foo?debug=1 was redirectd to /bar?a=1
After this commit,
/foo?debug=1 is redirected to /bar?a=1&debug=1
Before this commit, UTM was no more set for website.page.
Website.page mechanism uses the _handle_exception to check if an url match a
record in database, instead of use the method _dispatch that uses controllers.
Consequently, module UTM never set the utm into the cookies for website.page.
Now we override method '_handle_exception' that will anyway ignore to set utm
if it is a real exception and not a fallback (redirect, page, attachment, ...)
Romain Derie