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
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
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.
On delivery order, it happens that when it contains more than 40
products and multiple pager. The quantity done are only saved on
the first pager and on the other everythings is reset to 0.
This issue is not deterministic.
The reason is because on the picking view, both stock.move and
stock.move.line are present. When the user write the quantity done
on a stock.move it exists a function inverse that write qty_done on
stock.move.line. However during an onchange, inverse function are not
trigger and every field present in the view is returned to the client.
It means that data after the onchange are inconsistent since the
quantity done write on the move is different than the quantity on the
move line. When the user save the form view, the write could be trigger
in different order. If the write on stock.move is trigger first, it will
write the qty_done with the inverse function but it will be erase by the
write on stock.move.line that is trigger after.
In order to fix it, we set the stock.move.line as readonly when they are
not needed, so they are not send to the server.
closesodoo/odoo#27903
Steps to reproduce the bug:
- Create a credit note for an amount of 100$
- Validate it and register a payment
- Let's pay an amount of 90$ and mark this credit note as fully paid
Bug:
An error message was raised saying: Wrong credit or debit value in accounting entry !
DO NOT FORWARD-PORT
opw:1893570
closesodoo/odoo#28433
If all the planets are correctly aligned, it is possible for a model to
not have any xids associated with it, if this happens then the computed
field that calculates the records to be deleted during an uninstall
may mistakingly add records of this xid-less model to the list of
records to be deleted, even if the actual uninstallation won't remove
these records.
opw-1904139
closesodoo/odoo#28388
This widget claims to support one2many fields but it doesn't work in most cases.
This was triggering warnings when this widget was set on another field or in another
view (i.e. in Studio).
opw-1905803
closesodoo/odoo#28413
Steps to reproduce the bug:
- Create a promotion program P with a fixed amount discount
- Set a customer tax T on the discount product generated for P
- Create a SO with one line
- Apply the promotion program by clicking on "Update promotions"
Bug:
The SO line with the discount product is generated but the tax T was missing.
opw:1888484
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
PRICING
--------------
The pricing on snailmail has changed and we now charge stamps for each letter.
USABILITY
-----------------
Added a new error to help the user more specifically
Avoid spamming the user's mailbox with the next activities when a letter can not be sent.
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#28290
the fix merged in cb8bd299fc
was only tackling half the problem. When you assign a user to an
activity, the said user will be notified by email. This also occur if
you change the assignee to the next activity even if you change it to
the same user.
This commit ensures that we only write on the user_id field when we
create the next activity and not during the update.
Up until now, we'd charge the user in actual curency but we changed the
pricing to 1 creidt=1 letter. in forder to help the user we will change
the name credits to stamps. As 1 letter = 1 stamp.
This commit fixes a bug introduced with https://github.com/odoo/odoo/pull/28251:
When opening the ace editor on page load thanks to the #ace-view-editor
URL hash, a JS error occurred preventing the editor to open.
This was due to the way actions were executed on page loading:
- Menu elements are initialized and can handle actions
- On initialization, the ace menu tried to launch the editor
- First, it asked that all widgets are closed (see mentioned PR)
- The website handled that action demand by asking everyone to close
their widget
- The 'new content' menu tried... and failed as referenced a variable
which would only have been created in the start method.
Conclusion: before handling actions, all action-capable widgets should
be started. This is what this commit does: when receiving an action
demand, we first wait for the action handler to be fully started. This
implied another change: before, many menus were waiting for the result
of an action to notify that their start method is finished... this
would cause a deadlock in the new system so those were removed, this did
not make much sense anyway (if the result of that starting action has to
be known, a dedicated event/method should handle that).
closesodoo/odoo#28364
A challenge with less than 3 participants was failing with a key error
The challenge line has only one 'goal' result per participant
As the template is set in a noupdate, even a module update does not fix the bug
Generate fake goals that will be displayed in the top 3, e.g.:
1 Bob $100 42%
2 Alice $50 21%
3 0 0%
closesodoo/odoo#28363
- When deleting attachments, the foreign key constraints on
`message_main_attachment_id` are triggered which could take
a lot of time to be computed.
closesodoo/odoo#28358
Doc links were created before the doc, then the doc was merged under a
different URL.
This commit corrects the links to the Unsplash documentation.
closesodoo/odoo#28355
- Open the Attendance kiosk mode
- Scan an incorrect barcode
It's not possible to scan any barcode anymore.
If the barcode is incorrect, we need to add back the event listener.
Moreover, the RPC introduced with bbc7e9586d is not necessary if
we retrieve the barcode thanks to the existing RPC call.
opw-1878632
opw-1888402
closesodoo/odoo#28354
52a8ed3c0c made related fields readonly by default. 3f4f77fd9d
attempted to identify all fields that needed readonly=False but missed
this one.
closesodoo/odoo#28343
In the previous debian version, the output of ifconfig was:
ifconfig eth0 Link encap:Ethernet HWaddr b8:27:eb:d6:03:8d
now is
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
ether b8:27:eb:d6:03:8d txqueuelen 1000 (Ethernet)
closesodoo/odoo#28320
Running the bus garbage collector synchronously during the handling of a
request can stall the request for a very long time.
Instead, we add this step to the existing auto-vacuum scheduled job that
handles this kind of housecleaning. It brings another interesting bonus:
it can be scheduled outside of peak hours, which will avoid blocking other
bus-related transactions (the GC deletes a lot of rows and takes a lot
of exclusive locks in the database)
closesodoo/odoo#28326
With https://github.com/odoo/odoo/commit/55131b8f5becdd3d4776f4c3e7e4288a0b185706,
we automatically add the known editor context (containing lang,
website_id, etc) when using the `this._rpc` method. Some RPCs needed
however to explicitely not send a value from this automatic context...
but this was not correctly implemented. This can now be achieved by
using the `noContextKeys` key in the `this._rpc`'s *options* parameter.
closesodoo/odoo#28322
The objective of not creating the record if the email was invalid
was to avoid crash on import. But if the number of record created does not
match the number of record that would have been created (see in flush()
in models.py), this cannot work.
Also, it's necessary to tell the user that his import file has an error
and where. This is why a UserError must be returned.
Task ID 1902139
Closes PR #28011
In v11, when we add the extra step in website checkout and
then click 'proceed to checkout', user will be directed to address
(even when there is default address detected), and then extra step,
and in the end confirmation.
But in v12, when extra step is enabled, user will be sent
directly to confirmation after clicking 'proceed to checkout'.
They can click 'extra info' to fill out the information,
but I imagine user would easily ignore that option.
It seems the express checkout implementation ignored extra_info route.
closesodoo/odoo#28122
Some of our new snippets for 12.0 uses parallax. Those were not using
the exact structure required by parallax which *may* lead to unexpected
results when playing with the related options.
closesodoo/odoo#28299
On the payment page, a cart summary appears on the right. This summary
is still not visually perfect and the design will be improved in master.
This commit however restores what can be considered as a bug with a
minimal diff:
- "I have a coupon" message was glued to the card border
- If a product name was long, the table was very small on Firefox as the
name broke accordingly while it was very large on Chrome.
Also see https://github.com/odoo/odoo/pull/28245/filesclosesodoo/odoo#28286
Lucas Perais (lpe)