When sending notification from the frontend, if a template is rendered
for it and the user has the group "website.group_website_publisher" he
will get inherit_branding adding on elements things like:
data-oe-id="42" data-oe-model="ir.ui.view" data-oe-field="arch"
but the chatter system has feature automatically redirecting an element
that have attribute "data-oe-id": this caused for example that a
link notification towards the forum would instead be redirecting to
editing the view of the notification.
This fix distinguish the inherit_branding in the chatter feature and
ignore them.
opw-813333
closes#23225
- Enable multi-company: without sharing products and partners
- Create 2 companies (company1 and company2)
- Create 2 users one for each company
- Create inventory transaction (receipt) by user1 in company1
- Create inventory transaction (receipt) by user2 in company2
- Using user2 run inventory valuation report with 'At a specific date'
option.
You got read access error for product.product.
This is due to commit 5c5098f740. We should apply the `ir.rules` to
the query.
opw-816663
Before this commit:
1. When enabling 'List View of Variants' on a product page, it would not
replace the variant normal view as it should since the code being replaced
is included in the code replacing it.
2.The badge specifying the price difference between the variance and the
product base price would be calculated by taking the price_extra of the
variance attribute and converting it in the user currency which was not
correct if a pricelist was set on the product variant because the price diff
would then be (the variant price set on the pricelist) - (product base price)
Note: this is about the 'List View of Variants' mode, not the normal mode
which list variant attribute and not variant itself
3. The strikethrough amount was not in the user currency
Step to reproduce:
- Enable variants & pricelists
- Enable multi-currency and activate 'COP' as second currency (you may want
to change the currency symbol on edit mode since it is also '$')
- Go to iPad Retina Display product page in shop
- Enable 'List View of Variants' in 'Customize'
- Both Variants selection mode are visible (bug 1)
- The third variant shows '+$ 50.40' which is the diff between the
strikethrough prices (in fact the sum of the price_extra of the product
variant attributes, +50,40 on the 32GO attribute in this case)
It should show '+$ 40.32' since the price change from $600 to $640.32.
This is bug n°2
- Change Public Pricelist currency from USD to COP
- Back on iPad page, change between the 3 product variants, you will see
the $ price strikedthrough instead of the COP one:
Strikedthrough: 750 (it should be 1 714 491,47)
Price: 1 371 593,17
This is bug 3
- You can notice the bug n°2 being more visible since it shows
'+$ 115 213,83' instead of '+ 92 171.07'
- Remove the iPad Retina from Public Pricelist and add iPad Retina 32Go
variant to it with a fix price of $1 000 000.
- '32Gb, 2.4GHz, White' variant cost $1 000 000 but shows '+ 115 213.83'
instead of '- 714 491.47' since the base price of Retina is
'1 714 491.47'.
- You can play with the pricelist price for this variant up and down, the
diff price shown in the badge will always be 115 213.83 since it will
always calculate it by summing all the variant's attribute price_extra
and then converting it to the user currency.
This closes#14094, closes#22553
When X is adding Y in a discuss channel, the recieved notification was:
- if read in discuss: from Y, "joined the channel" (no information who added him)
- if read in email: from X, "joined the channel" (misleading, think X was the
one joining the channel)
The problem comes from the author_id in the first case and the email_from in the
second, both containing a different value.
Also correct a bad api.multi parameter
When changing the routing on a bom, "Consumed in Operation" indicated
in some lines of the BoM did not correspond to the routing used.
So the system did not link it to a workorder and it was never consumed when
a MO was processed.
Now the "Consumed in operation" are reset when the routing is changed.
opw:807560
This commit improves link creation in web editor.
Before this commit, anything with a @ would be considered as valid email which
is obviously not the case. It would then be prefixed by 'mailto:'.
This was causing 2 issues:
- URL with @ symbol in it would have 'mailto:' added as prefix, like google
maps coordinates.
eg: mailto:http://www.google.com/maps/whatever/@312211.22,321321
- Incorrect emails would go through (eg: @@@, ko@k@k@, mail@mail)
Now, we will try to detect and identify valid emails from invalid emails from
URLs. It will also handle 'mailto:' directly typed in the input.
This commit comes with it's counterpart in enterprise https://github.com/odoo/enterprise/pull/1859
This closes#11984, closes#22936
Note that there is a WIP in master to use this new is_email function
everywhere we try to validate emails. It will aim to uniformize email
validation in odoo's javascript that are often performed with different mean
here and there, some more permissive than others, some only checking for @.
When having a default template for quotation
Doing a sale order through the website
Before this commit:
The field require_payment on the SO was not matching the one on the template
This leads to confusion at config time when on the backend something is set on the template as default
while not matching what actually happens
After this commit:
The field require_payment on the SO is computed from the template
OPW 807946
If a record is deleted *and* has property fields, the deletion of the
property fields will trigger the various recomputes before the record
itself has actually been deleted, and thus stuff which depend(ed) on
that record will be recomputed under the assumption that the record
still exists, which probably will not work.
Under the assumption that the same issue would occur when deleting
more than one batch of records (unlinking the data, values or
attachment would also trigger a recompute before the proper end of the
function and could lead to incoherence, e.g. some of the records being
deleted being visible to recomputes), lift the entire effective body
of the unlink into a norecompute context, to ensure that only the very
final recompute (from the top-level unlink) is actually triggered.
opw-807036
Before this commit, if the first exported field of an M2M is `id` (the
xid) the entire M2M is folded into a single cell with comma-separated
xids and any following field is ignored. If `id` is any but the first
field, the export behaves normally (with the m2m exported as a "table"
inside the parent record).
This behaviour makes sense for import-compatible exports where the id
is the only thing which can be exported anyway, but it is troublesome
outside of that mode as the behaviour of m2m under export becomes
incoherent/unpredictable (ish) as it depends on the position of the
m2m's `id` in the exports list.
Change it so we only perform folding in import-compatible mode (which
is the default for backwards compatibility with e.g. API calling
export_data directly & the like).
opw-813361
Fixes#22600
Before this in the event of a network failure that lasts longer than the respective return cycle of the deferred call,
this deferred will keep in purgatory forever (until reload of the client).
This is not problematic in the normal use case, but working with offline modules, such as POS or similar making use of the
long polling concept for synchronization purposes, this generates toxic behavior.
Simply: The client state never recovers on it's own from the network failure
(PR #21653)
Apparently, SEO audit thingies (possibly google's own? unclear) don't
ignore *empty* keyword or description meta tags, then complain that
they're duplicated (there's a use case for SQL-like nulls).
So remove the keyword & description metas entirely if the
corresponding fields are empty.
OPW-815492
5ca0ef97 was forward-ported from 9.0. In 10.0 the function signature
of product.uom's _compute_price has changed. In 10.0 it uses the new
API and it no longer takes a to_uom_id keyword argument.
opw-816738
Revision 89c63096cb fixed the creation
of the taxes applied to account move lines when validating a pos session
The fix though overlooked two things:
- protection against recursivity
(nothing prevents a group of taxes to have a grand-parent as one of its children)
- the fact that when converting a group of taxes into a regular computed one,
the field children_ids is never reset
Those two caveats provoked a "max recursivity error" in python within the right conditions
This commit protects the recursive process from the two issues, and there is no traceback
OPW 816163
Having base_vat installed (but is potentially more general than this)
In the pos frontend, try to save a partner with an incorrect VAT
Before this commit, the generic and cryptic message "your internet is probably down" was displayed to the user
when a python exception occured
After this commit, we display the exception's message
OPW 807656
We should normally stick as close as possible to the version we depend
on in the official DEB packages. This in turn depends on the version of
Debian stable at the time of release - for 9.0 that would be Debian 8
(jessie) and thus Pillow 2.6.1.
However Pillow versions before 3.1.1 suffer from a few issues that could
lead to crashes of Odoo workers. The bugfixes have been backported in
the DEB packages for Pillow, so users of Debian/Ubuntu LTS versions
won't be affected if they are keeing their systems updated.
However it's worth an exception to our rule for pip users.
FWD-PORTS: skip
The emails sending is skipped during the tests.
The mecanism to determine if the server was running tests
was to check if the attribute `testing` was set for the thread.
Unfortunately, this `testing` attribute is removed/set to false after the loading/installation
of the modules is done, and phantomJS tests are ran post-installation,
and therefore the emails that were potentialy sent following an action
performed in a PhantomJS tour were not skipped.
This occurred for instance in the tour `project.tour`,
when the responsible of a task was changed,
the sending of the assignation notification email was not skipped.
In the case the machine on which the tests are ran does
not have an smtp server (or mailcatcher) running on the port 25,
this resulted in a test fail.
Previously, some screen in front was casted in Integer, others not.
This commits closes#22443
To improve in master using precision decimal, t-field, ...
But avoid to change in dom tree in stable version
Christophe Simonis