Mail thread now holds a method to replace local links by global links.
Let us therefore use it in mass mailing as it does basically the same
job. Adding base tag is not necessary anymore since there are not
local links or images anymore.
Since notification emails are not mail templates anymore they do not go
through the mail_template.render_post_process() method that converts
local links to absolute links. This means that buttons and images were
not correctly displayed in notification emails. Indeed those still had
local links.
This commit fixes that by moving the method directly in mail.thread and
calling it accordingly when rendering the notification email. Note that
the method has been changed in order to use regex instead of html
parser. It is done based on work already done in mass mailing application.
Indeed using parsers is complex and time consuming and may create
changes in the html structure that are not intended.
Next step in master is to go through various link modifications in
mass mailing module to see how to handle them properly. Maybe.
Notification emails now use QWeb to be rendered instead of jinja-based
mail.template since 2f7593761c. Part of the notification emails was not working
anymore since its syntax was still using jinja. This commit fixes that.
This commit also removes strange ';' that should not be part of python code
as well as an unnecessary variable propagation.
A traceback occurred on the Intrastat list view (Accounting >
Reporting > Management > Intrastat), when the user clicked on a row
of the list. This action only specifies 2 view modes: list and
kanban. When a record is clicked, the ActionManager tries to open
that record in a form view. As the view isn't in the action, this
request should be ignored. Before this rev., this case wasn't
correctly supported.
Static help from xml and python generated help were both showing the new
smiling face, we needed to sort that out.
Python dynamic help now prevails over static help.
Co-authored-by: RomainLibert <rli@odoo.com>
Use case to reproduce:
- Install delivery/batch picking
- Process 2 pickings in a batch.
-> Traceback due to ensure_one.
It happens because the action_done method in delivery is
not multi and batch_picking launch action_done on multiple
picking.
This commit makes action_done in delivery multi.
It happens due to workcenter working hours,
the workcenter is not active during the weekend thus
the productivity loss are not counted in the oee.
This commit removes 2 days to the test date if it is
during the weekend.
Previous to this commit, installing sale_managmenet/account_invoicing
would add some menu items for the `sale/account` module
(which contains all the logic for the sale/accounting flow)
and it would also install sale/account since it's a dependency, however,
horror would strike if one were to go and uninstall
sale_management/account_invoicing: nothing happens!
This is because these "facade" modules don't actually install anything, and
uninstalling an app does not force the uninstallation of its
dependencies, thus the `sale/account` module would stay installed, along with
the views introduced by the "facade" module.
To fix this, we create an uninstall_hook which forces the removal of
the ir.ui.menus that the "facade" modules introduce, so that the
functionality remains (for modules that depend on it) but it's not
user-accessible (because it should only be accessible to users if the
facade module is installed).
The issue adressed by this fix was observed by a problem with a missing
onchange. The situation only happens when we have a one2many in a form
view with an onchange in a field in the list view, and the arch of the
list view is not inline. In that case, the onchange was not properly
triggered.
There are two causes for this bug:
- the BasicModel does not exactly receive the same data when loading a
record in a one2many with a non inline view. More specifically, there
is a confusion with the fields/viewFields in that case. This is done
because the postprocessing of the fields is slightly different when a
sub view is not inline (not ideal situation, we should fix it btw)
- when it construct a subrecord, the BasicModel did not use the correct
fields value, when there was a subview. More specifically, it used
the view.fields (which does not contain onchange informations) instead
of the view.viewFields (which contains processed/view specific
informations, including the onchange data.
This commit fixes the second issue, because this is clearly a bug, and
it actually fixes the problem. The first issue is actually okay,
because we already have a difference of behaviour between the main view
and sub views (in the first case, we have the fieldget information, not
in the second case, so the processing is already a little bit different
anyway)
Notes:
- This bug was discovered only because we added a test in 11.0, which
was forwardported and broke in master. The breakage occured because
of a recent refactoring in master which moved the arch processing
inside the views and out of the data manager.
- It is good that we discovered this bug, but I want to say that it really
sucks that forwardports are done, break the master/saas.11.2, then I
have to fix it in emergency, and it completely break my own
schedule...
wip
wip
When exporting to a tarfile, we first export each module's translations
to a file on the FS, then create a tarball from all of them.
With the P3 bytes/string split, translation export was defined to export
to a bytes IO object in order to work correctly with CSV (which work on
bytes IO for better cross-version compatibility). However the tgz file
export was left opening module's files in `w` mode, which in P3 means
text, which blows up as POFile expects to ultimately write to a bytes IO
object: it uses text, and a StreamReaderWriter is used to translate that
into an underlying bytes IO.
Fix by explicitly opening the files in binary mode.
Fixes#22700
A name_search on attribute line would possibly ends up with a domain like:
['|', ('attribute_id', '=', 'm'), ('value_ids', '=', 'm'),
('attribute_id', '=', 'm')]
which would just search the attribute.
This is caused by calling the default name_search. This commit forgo
the default name_search when we are in this attribute line special case.
courtesy-of: @fmdl
opw-813505
closes#22619closes#22760
Before this commit, when having a simple employee (group employee) accessing the form view
of hr.employee, there was traceback because the field is_address_home_a_company was not in the view
This is because of commit 2d777d5
which restricted this field to the group_hr_user (Officer) in Python
When the view itself is not group-restricted
The JS loads everything from the view but puts invisible=1 on sections that have a group
The field, in our case, is forbidden before that and is not loaded, whereas the domain in which it is used is loaded
After this commit, the view loads correctly, while avoiding leaks as intended
OPW 813721
The data in tests use 'datetime.today()'. This can
add second and milli seconds: if those are not zero,
a 4th day of work will be count (hence the '+1').
The test craches with "3 != 4" when the test was executed
on a 'zero second' time.
As Dr Emmett Brown would say : "Time traveling is just
too dangerous !"
Name of scripts piped to `odoo shell` were `__builtin__` (`builtins` in
python3), which is not really obvious (and awful if your script must
handle python2 and python3).
Change it to `__main__`, allowing to use to common pattern
`if __name__ == '__main__':`
Before this commit, when duplicating a task,
the pad of the original one was updated with plain text
Hence losing all the layout.
This was because, in all likelihood, Odoo's Etherpad server did not support pushing HTML
At the time of the commit, Odoo's pads can receive HTML.
We then push HTML by default, falling back to pushing text as before
if necessary
OPW 806064
Before this commit, when connected as a portal user, the user was not
able to post replies to existing replies. This is because the textarea
section was marked to be displayed for connected internal users only.
This commit removes the whole group restriction. Indeed, it makes sense
(as a fix), to show the textarea section for public users too. Indeed,
the "Reply" button is already shown to public users but does not do
anything. With this commit, clicking the "Reply" button shows the
textarea section for everybody and, if the user is not connected,
redirects to the login page when posting the message. This of course
needs usability improvements in master.
Note: the problem had originally been fixed for regular answers with
commit https://github.com/odoo/odoo/commit/b81b03c82d282dc94595a9beb94444041509ef25
Note 2: both mentioned problems were originally introduced by commit
https://github.com/odoo/odoo/commit/9069d0127c176317436b67b23ae5677dd9d53de7
Closes https://github.com/odoo/odoo/issues/22648
Use `ir.values` for default taxes. Stop using `ir.config_parameter`. The
logic is made in order to be as error-proof as possible.
Backport of a9ede7fdfa
opw-807226
In case an invoice is required to be paid thanks to the route
'/my/invoices/', the user is redirected to '/shop/payment/transaction/'.
If website_sale is not installed, this causes a crash.
Complement of 2bd17285ea
opw-813481
Thibault Delavallée