By default in the notification manager we see something like:
```
record name {a second ago}
summary V
```
but if for example the record name is long or the summary empty, we can
have something like:
```
record name so very long {a s}
V
---
record name so very very lo...
V
```
This is because the record name was not allowed to grow, and the
positionning of the check mark based itself on the existence of the
summary container (.o_last_message_preview).
With this change the date a message was sent is shown in any case and
the check mark is on the right.
opw-1911654
closes#28960
Returning inactive users breaks many features based on the partner's user ids
(among which the company switcher).
This reverts a small part of commit 14af2c7f2fe6c14afb96d7e9f2bb02b2a022eaae
which is related to #25939. That part was not necessary and had some
unintended side-effects.
closesodoo/odoo#28947
- Before this commit when a transaction failed, the code doesn't
rollback and continue to process the other transaction, thus creating
record that should be rollbacked.
closesodoo/odoo#28748
Purpose
=======
Currently the remaining leaves substract the taken leaves with
no needed allocation.
That way, sick leaves are removed from the remaining leaves for example.
Closes#28659
Co-authored-by: Cas Vissers <c.vissers@brahoo.nl>
closesodoo/odoo#28951
When we mention for example `@hell'o`, the user will be added as
subscriber but he is not linked.
This is because there is two part of mentions:
- inserting the mention in the message: at this point the mention is
not escaped (only space are replaced with non-breaking space).
- wrapping a link around the mention in a message that is being posted:
at this time the message has been escaped ( for &<>"`' ).
Thus when wrapping the mention, we have to search the escaped content.
In the case of canned response, the system is different with defined
substitution that replaced the "shortcut" so this makes no change to
that.
Added test without fix failed with:
8. should contain a link in the message content (expected:1, result:0)
9. should have correct mention link in the message content
(expected:"@ЅpëciãlUser<&>\"`' ツ", result: "")
opw-1909300
closes#28846
- In some cases (record rules modified to allow access to multi company
SO) the duplication of a quotation isn't possible if the quotation is
set on a company than the user trying to duplicate it.
This is due to a computed field that tries to access the order's
company currency.
closesodoo/odoo#28945
- On `project.task` records the field `allow_timesheets` is a related
set to `readonly=False` which triggers writes on `project.project` and
raise access rights issue for users who can create tasks but cannot
write on `project.project`.
OPW-1910877
closesodoo/odoo#28943
Have a user A having the focus on the search bar, minding his own business
Have a user B send a direct message to user A
Before this commit, the chat window on user A's browser took the focus manu militari
After this commit, the focus stays on user A's search bar
OPW 1911553
closesodoo/odoo#28915
The link pointing to the hardware setup for PoS redirected to the POSBox doc which no longer exists in 12.0.
Therefore the response was a 404.
Now the link redirects to the IoT doc for using the box with PoS.
Btw, this new doc seems less complete than the previous one.
closesodoo/odoo#28944
- This commit fixes a crash that happens when the server receive a
JSON-P call done in two requests (a POST followed by a GET).
The issue is due to the fact that when the first request is done (POST
one) the member `params` is never initialized.
This parameter is then used in the module `auth_signup` on an override
of the method `dispatch` thus crashing the code.
To avoid the crash, we now initialize `params`.
closesodoo/odoo#27369
Have a recurring meeting, repeated until some date
Edit one of the instances and detach it (click on "update only this instance")
Edit the detached event and change some value
Save
Before this commit, a JS error was thrown saying that the field final_date was invalid
This was because the required attribute on this field was set to True, but the python
put the value of the final_date to False
After this commit, there is no error as we set this value to false, since the field
doesn't make sense for a non-recurring event anyway
OPW 1892426
closesodoo/odoo#28850
Put the browser in timezone Sao Paulo (Or like West of UTC)
Trigger the autocomplete (and the subsequent search) on a date field
by writing a date (in the locale format) in the search view
Before this commit, the domain sent to the server contained the date as the day
**before** the one asked for in the input
This is because, the string input is parsed and gives:
input = 12/02/2018
When creating the moment object:
> since there is no explicit time, moment will interpret it as 12am (midnight)
> We force moment to consider the string as being UTC (function: moment.utc())
> the moment contains, as output the time ** 2018-02-12T00:00:00 UTC **
When getting the facet value for making the domain
> we call toDate on the moment object, which, according to the browser is UTC and will
be converted to the locale timezone before formatting
> And the domain will use the date 2018-02-11T22:00:00 Brazil/SaoPaulo
which gives the day before the one we asked for
After this commit, this issue doesn't arise, because we use the string representation of
the moment object in search_inputs (i.e 2018-02-12T00:00:00 UTC), to create a new one
*BUT* we create it with a date format that excludes the time from being interpreted.
Also, the resulting moment object in this case is not flagged as UTC anymore
OPW 1903224
closesodoo/odoo#28542
Purpose
=======
Buggy example:
I have a 35h working schedule. I work every week day:
- From 8h to 12h
- From 12h to 16h
Let's say that I want to retrieve the working hours from Wednesday 14h03
to Thursday 11h03.
The working hours are:
- From 14h03 to 16h --> 1h57
- From 8h to 11h03 --> 3h03
----------------------------
TOTAL 5h
Currently the result will be 1.95, i.e. 1h57 because the second day
is not taken into account as start time > end time, and thus rrule
doesn't manage this correctly and returns only the datetime corresponding
to the first day.
Specification
=============
Force the until parameter of rrule to be set at the end of the day, do
avoid skipping the second day. Do this in the methods that compute the
work hours and the leave hours.
Add a test to ensure the robustness of the fix.
Closes#21297closesodoo/odoo#28920
This revision brings the compatibility for our reports
using wkhtmltopdf 0.12.5.
Up to now,
the supported wkhtmltopdf version was 0.12.1.
The goal of this revision is to add the compatibility
to wkhtmltopdf 0.12.5,
while keeping the same exact rendering than in 0.12.1.
There is a behavior change with the `--dpi` parameter,
which no longer has a "zoom" level effect as it did with 0.12.1.
To deal with it, we pass the `--zoom` parameter when
the detected version installed of wkhtmltopdf is after 0.12.2,
with a ratio 96:dpi. 96 being the default dpi of wkhtmltopdf.
This trick allows to render the reports with the exact same
zoom level, whatever the dpi value configured in the reports paperformat.
(at least with dpi values up to 149, after 150, included,
the dpi parameter with wkhtmltopdf 0.12.1 as a weird behavior,
it no longer zoom out)
opw-1907346
closesodoo/odoo#28864
Fixing it directly by commit since there is no es_AR on transifex.
The issue of the ticket has been solved by transifex, this is for
another similar issue that has been found.
opw-1907924
closes#28923
Put the browser in timezone Sao Paulo (Or like West of UTC)
Trigger the autocomplete (and the subsequent search) on a date field
by writing a date (in the locale format) in the search view
Before this commit, the domain sent to the server contained the date as the day
**before** the one asked for in the input
This is because, the string input is parsed and gives:
input = 12/02/2018
When creating the moment object:
> since there is no explicit time, moment will interpret it as 12am (midnight)
> We force moment to consider the string as being UTC (function: moment.utc())
> the moment contains, as output the time ** 2018-02-12T00:00:00 UTC **
When getting the facet value for making the domain
> we call toDate on the moment object, which, according to the browser is UTC and will
be converted to the locale timezone before formatting
> And the domain will use the date 2018-02-11T22:00:00 Brazil/SaoPaulo
which gives the day before the one we asked for
After this commit, this issue doesn't arise, because we don't convert the moment into a Date,
and we directly format that moment into a string
OPW 1903224
closesodoo/odoo#28689
Fixing it directly by commit since there is no es_AR on transifex.
The issue of the ticket has been solved by transifex, this is for
another similar issue that has been found.
opw-1907924
closes#28929
In the extended composer, we focus on subject when adding a mention in
the body. Focusing in subject is wanted at the opening of the composer,
but not when adding a mention.
opw-1911566
closes#28910
The "add" button shown in the outstanding credits menu in the
button right corner of a payment wasn't shown in green like the
other clickable elements.
opw-1907342
closesodoo/odoo#28908
In the following commit (https://github.com/odoo/odoo/commit/744de4ee1cec5e43aa77ac3eccc7a9b1224f8fa1) we introduced some floats as keys
to Selection fields (namely request_hour_from and request_hour_to)
This lead to the ORM creating a column of type `int4` to store this
field which rounded the values.
In order to repair that faulty behaviour we use negative integer values
for the half hours, which is then transformed back into a float in the
code.
closesodoo/odoo#28877
Steps to reproduce the bug:
- In the Manufacturing App , enable Work Orders and Quality
- Configure your products,BOM and Routing
- Create steps in routing with type='Register Consumed Materials'
Bug:
When you finished your Work Order operations it displayed "False" value in
the "Finished Steps" tab instead of the uom of the finished product.
Technically:
The function "record_production" unlinks the temporary stock.move.line that can
be linked to a quality.check. So the component_uom_id of the quality.check could not
be found when computing the field 'result' on model "quality.check' with function "_compute_result".
opw:1909768
closesodoo/odoo#28865
When we print or post_message of an invoice it is set as sent.
But when we multiprint, we do not use each invoice post_message but
create directly mail.mail then send them in batch.
Thus the invoices are not set as "Sent".
With this change we make a special case.
opw-1910937
closes#28852
Purpose
=======
As we try to open a mail.compose.message on a model that doesn't inherit
from mail.thread (Mimic a cowboy yellin' "Yihaaa" while shooting into the air
with one revolver in each hand).
Specification
=============
The only way to fix this issue while keeping the feature (Open a
mail composer) is to open the mail composer in mass_mail mode and
to remove the model on which it should be called.
The template won't be rendered in the mail composer but will
be rendered when sending the mass_mailing obviously, while avoiding
the unavoidable traceback when clicking on the 'Send' button
closesodoo/odoo#28849
The gengo module is used for automatic translation, if you try to
uninstall the module, at some point the required models/fields of
gengo no more exist but the module is still in use by odoo for
every translation.
This commit fixes the problem by disabling the gengo translations
when the system is installing/uninstalling a module.
opw-1906293
closesodoo/odoo#28806
The "Get authorization code" button in the General Settings >
Integrations > Google drive was not correctly rendered on firefox.
This PR fixes that bug by correcly rendering the button, it has
been tested on both Firefox and Chrome
opw-1907644
closesodoo/odoo#28672
- The value returned by the method `_portal_ensure_token` is False due
to a cache issue.
The value is generated written using the `sudo` environment while in
the current user environment the cached value is `False`.
After generating the value, the cache is not cleared, thus letting the
method return `False`
closesodoo/odoo#28836
Before this commit, we had the following issue:
1. Open two tabs A & B.
2. Receive a message from a channel in tab A.
3. Mark it as read in tab A by clicking on the
chat window of the channel.
> The unread counter is correct in tab A: no
unread messages on this channel, and the
messaging menu counter has been updated.
> The unread counter is not correct in tab B:
it still has unread messages on this channel,
and the messaging menu counter has not been
updated.
The issue was caused by not notifying the updated
unread counter to the widgets when receiving the
'channel_seen' notification from the longpoll.
It was working in tab A because this is were we made
the action, so that it already marked messages as
read without waiting for the longpoll response.
However, Tab B has to wait for the longpoll response
to update the unread counter. It was updating the
counter, but it was not notifying the widgets.
This commit fixes the issue by letting the widgets
know when the unread counter has been reset.
Task-ID 1911239
closesodoo/odoo#28833
Fine-tuning of commit: d60f2ab0e2
Which applied when the next action was to create a new activity.
However the problem is also present when the next action is to send an email.
We extract the logic in a new private function to share the code in both cases.
opw 1904156
closesodoo/odoo#28819
On save, the editor will ask to parent widgets if something needs to be
done first. The website navbar will receive that demand and asks to its
action-capable components to do something. For example, the content menu
handles page-related options saving. However, some users with limited
access rights do not have the content menu... but the website navbar
expects that the save action is performed. So, this empty action is
defined here so that all users have an 'on_save' related action.
This was only happening since 12.0 as 'on_save' actions were introduced
there to save page-related options.
closesodoo/odoo#28810
Transfer accounts created for payment acquirers was ignoring the prefix of the main transfer accounts and was always creating accounts with code 000001, 000002, etc.
The reason is because the method was called on an empty recordset
closesodoo/odoo#28789
Christophe Simonis