Related issue odoo/odoo#27256
use case is in there
Retrieving the access token for an attachment should be done as sudo
Also, we adapt the code to the method, which appears to be "api.one" (lol)
OPW 1888873
closesodoo/odoo#28074
Be in timezone Europe/Brussels, where, in 2018, the DST switch
happens on 2018-10-28.
Create a recurring event starting on 2018-10-27 until 2018-10-29
at say, 8am
For the days before the 28, the time of the event will be correct
Before this commit though, for the days after the 28,
the meeting time will be shifted by one hour
This is because the rrule took a TZ aware datetime, and generated recurring
event dates with that same TZ, i.e. the one in STD time
After, this commit, all the meetings are well scheduled at 8am,
OPW 1895315
closesodoo/odoo#27985
Before this commit:
If an user has multiple session on a database (eg: he is connected both on his
smartphone and his laptop on the ecommerce), and there is a cart in these
session, confirming the cart on one of the session will make other sessions
unable to use the checkout anymore.
This is because other sessions will still contains the Sale Order that is now
'sent' and updating the cart will raise an error:
`It is forbidden to modify a sales order which is not in draft status.`
Now:
If the SO to be updated is not in `draft` anymore, we create a new one.
Step to reproduce:
- Login on ecommerce from device A
- Add product in cart, the SO will be added on session
- Login on ecommerce from device B
- Pay the cart (it will retrieve the SO from device A)
- At that point, the cart is paid and the SO is removed from session on
device B but other devices won't be able to use the checkout anymore
as they still have the SO in session which is in `sent` state.
Thus, any action on cart will raise the error
Note:
1. We can't implement that behavior in `sale_get_order()` as it is supposed to
return SO in `sent` state after checkout.
2. We can't implement that behavior in `_cart_update()` as it is inherited in
some module. Thus, implementing that behavior in `cart_update()` would change
`self = order` but inherited methods would still have initial `self`.
3. Implementing the behavior in the controller it is already done (differently)
in `cart_update_json()`.
Fixes#27508, closes#27794
Spamming the save button when creating a new custommer in point-
of-sale create duplicate users. This PR disable the button once
clicked and re-enable it when all the processing is done.
opw-1895302
close#23919
https://bugs.python.org/issue33899
tokenize.generate_tokens was altered to match the C tokenizer,
previously it would end the tokenization with just an ENDMARKER, in the
titled releases it adds a NEWLINE before the ENDMARKER if none is
present, this broke the parsing of jsdoc type specifications as Python's
tokenizer is used under the cover.
closesodoo/odoo#28056
With a user in a distant timezone, like UTC +/- 11
Create a all day event.
Before this commit, the event was displayed across the wrong days
This was because the dates were converted from the user's timezone
into UTC before being stored.
Which is:
- start date at december, 12
- if the user's tz is utc-11: the date becomes december, 11 (at 1:00pm)
- at rendering, it becomes december, 11 (at 7:00am)
After this commit, we store the datetime field "as if" it were a date field
that is, we don't convert it to any particular tz
It is worth noting that, if one removes the allday mapping in the xml view,
an event that has been created as allday will get its start and stop date converted
to the browser's timezone, and will NOT be displayed as from 8am to 8pm as one could expect
This is considered as a limitation of the code, that was present before this commit anyway.
In any case, please do not revert this commit :D
OPW 1891110
closesodoo/odoo#27949
When an unlogger user places an order, a new partner is created on the fly when
the unlogged user is asked to place his delivery address.
The values he enters on the form are processed before being used.
In particular the team_id is taken from the order (typically website_sale team).
We add to the new values the salesperson id.
This value is then used in onchange_partner_id to update the order's user_id.
opw 1889510
closesodoo/odoo#28030
In Dominican Republic, only english speakers and the military use 24h time
format. Businesses handle their information using 12h time format with a.m.
and p.m.
closesodoo/odoo#28042
Until v12, doing this is wrong. The currency_id field of account.journal should only be used if the journal is in a different currency. Otherwise, this field should stay empty.
//NOTE FOR FORWARD-PORT: this commit should not be ported to 12.0 and further.
When the user previews a background color, the background image of the
snippet is removed and re-added if the user chooses not to pick the
color. The background-image was not correctly added for carousel items.
- Handle the case where one select-class is a subset of another
select-class of the same group e.g.
<... data-select-class="hello"/>
<... data-select-class="hello world"/>
- Handle empty values <... data-select-class=""/>
Note: both cases worked but were not displaying the active checkbox
correctly in the editor UI.
when grouped on field types for which it isn't supported.
Rev. 42e1efd disabled the quick create feature when the view is
grouped by date(time) fields. However, it hasn't been correctly
forwardported to 11.0 (with the new views). Indeed, the check was
done only once, at the initilization of the view. So if the user
selected another field to group by afterwards, the quick create
feature wasn't enabled/disabled accordingly.
Moreover, we didn't check if it was available when the user clicked
on CREATE in the control panel. So even if it wasn't (and thus if
there were no '+' icon in the columns), when the user clicked on
CREATE, the quick create widget was inserted in the first column.
This rev. fixes both issues.
Task 1878254
closesodoo/odoo#27867
Usecase to reproduce:
- 6 units in stock
- reserve 3 units on a move
- reserve 3 units on another move
- validate a third move with 1 unit
It raise the error could not reserve more than you have in stock.
It happens because when free reservation stole reservation from
an exisiting move with too much quantity available, it continues the
loop instead of stopping.
This commit stop the loop once we have enough quantity taken.
opw-1895578
closesodoo/odoo#27935
Seems like something similar to odoo/odoo#17111 can happen on Python 2.
The same change as #17111 is a bit involved for -stable, but this looks
pretty harmless.
Probably fixes#23781.
If the invoice is not in the same currency as the sale order, then there was an
inconsistency in the sales report, as it was considered to be the unit currency.
We keep the initial computation in case where the invoice currency is the same.
opw 1890381
closesodoo/odoo#27797
Typically if you use an onchange method to retrieve values on the server
and convert them to write it will also try to write empty values like
[(6, 0, [])] and this will crash as it has also the length of 3 but no
dictionary but a list
closesodoo/odoo#27937
The CRON job that sends email sends them in a LIFO order instead
of a FIFO order which can lead to confusion when the order is
important.
Exemple, when updating multiple time an appointement, the last
update should be the newest mail clients receive in their mail box
which was not the case before this PR.
opw-1888601
closesodoo/odoo#27888
Steps to reproduce the bug:
- Create a customer invoice I with an amount of 100$ and validate it
- Register three payments P1 at 11/10, P2 at 12/10 and P3 at 13/10
- Click on button "Print" and the report displays the payments in the right order
P3, P2, P1
- Click on button "Send by email" and click on the attachment with the report
Bug:
The report didn't display the payments in the same order, it displayed P1, P2, P3
opw:1888251
closesodoo/odoo#27895
In JS, the groupBy attribute is a list of strings
The default_group_by key that is sometimes present in the XML views
gets converted to a list at somepoint.
Before this commit, the task action couldn't be used in the app Dashboard
After this commit, it can
OPW 1894751
closesodoo/odoo#27908
Gert Pellin