Chatter suggests to include recipients on several objects, notably on
registrations. When a registration is done through a public interface
like website in website_event associated partner is the public user.
In that case proposing to mail the public user does not make sense.
It should propose the real email stored on the registration record.
To fix that we filter the partner if it is linked to the pubic groups.
The fix includes a sudo + context switch in a loop. As this method is
called only on a recordset of one element this has no impact on real use
case. Purpose is to keep the diff minimal.
Closes#23187 .
There was a difference in the tax codes Import Buiten EU (2), some had the tag
'5B Voorbelasting' and other had the tag 'Voorbelasting BTW Bis'.
Link all the codes to '5B Voorbelasting' instead.
This is more consistent with the rest.
Closes#23119
With saas-11.2's 3fbd86b some trigger towards other fields are improved
but this caused an issue when a inherited field towards a custom
computed field had no depends.
When we created a computed field x_custo on res.partner, we have a
inherited x_custo on res.users automatically created.
Both these fields have a depends computed to `('',)`, this caused an
error for the one on res.partner: but this was ignored with dd048ae7.
Since saas-11.2's 3fbd86b this also caused an error on the inherited
field but since an inherited field is not "manual" the error was not
ignored. Thus it was not possible to create custom field on a model
inheriting of another model if the fields had no depends.
opw-1854786
closes#25146
Co-authored-by: Raphael Collet <rco@odoo.com>
As for consumables stock levels are not that important,
it should be ok to scrap a consumable at all times,
even if the stock becomes negative.
Tests were added to check what happens with a consumable/stockable
product if stays positive/goes negative.
Before this fix, we can create a Bom with both product_id and
product_tmpl_id filled where the product_id is not a variant of the
product_tmpl_id. This is unlogical and will be even trickier when the
user is not able to see the variant field on the BOM.
This fix puts the product_id back to False when the product_tmpl_id
is changed.
Fixes#10381 (wrong calculation on datetime)
if worked hours > 24h, calculation is wrong because "seconds" funtion does not take into account days
See: https://docs.python.org/2.4/lib/datetime-timedelta.html
total_seconds() should be used instead of seconds function
Before this commit, you can set the question of a post like the post itself.
That will generate a traceback:
RecursionError: maximum recursion depth exceeded in comparison
Now we check that there is no recursion
This commit fix an access right issue when a user that belongs to account.group_account_user (and not to account.group_account_manager) imports a bank statement file.
Was PR #25041. Courtesy of Alexis De Lattre (Akretion)
Steps to reproduce the bug:
- Create two products P1 and P2 requiring a lot
- Create a BOM B for P1 and requiring 3 P2
- Set on B a routing with a work order
- Create an inventory adjustment with 2 lots for P2:
- Lot1 with 20 P2
- Lot2 with 10 P1
- Create a MO for 10 P1
- Start the production and create a current lot Lot3 in Current Production sheet
- Set as current Qty 5 with Lot3 as current lot and Lot1 as Product Lot
- Click on DONE
- Set as current Qty 2 with Lot3 as current lot and Lot1 as Product Lot
- Click on DONE
- Set as current Qty 3 with Lot3 as current lot and Lot2 as Product Lot
- Click on Done
Bug:
When you checked the produced qty on the MO in the Finished product sheet, it only displayed 5 instead of 10.
opw:1849796
If a user member of group 'group_erp_manager' create a new user and adds
the user in multiple companies, the system raises an AccessError on ir.ui.view
When adding a user in multiple companies, he is automatically added in
the 'base.group_multi_company' group.
Modifying a 'res.group' record recomputes the view architecture.
The ir.ui.view records is writable by 'base.group_system' users.
Closes#21207
With website_version, when publishing a version and copying the current version,
the copy_translation wrote a new translation for the copy of master in the published
view instead of the copied view.
Reason:
When writing in the view, odoo checked in the context the current version and
wrote in the view corresponding to the key and the verion seen in the website.
So when copying a view, it translated the copied view instead of the copy of
the view.
The write is made by the function copy_translation with the line:
"new_wo_lang[name] = old_wo_lang[name]"
opw:1856150
Purpose
=======
In the website_sale.product_variants template, for the "checked" attribute in the radio input,
it must be " checked' if variant_id_index == 0 else None " instead of "' checked' if
variant_id_index == 0 else '' ".
For this moment, it checked the last variant because we get " checked="checked" " for the
first and " checked="" " for the others.
Specification
=============
Use None instead of '' for the checked attribute if it shouldn't be checked.
Purpose
=======
Currently, users have to retype email in the stripe payment popup.
For event registration, the email address must be typed 3 times (the first
for the registration information, the second for the billing information
and finally for the payment on the stripe popup)
Specifications
==============
As the email is already filled on billing information view, isn't
necessary to retype in the payment form.
Currently there are 3 ways of going out of the modal: clicking cancel
registration, hitting the close button or clicking outside the modal.
The latter one however does not trigger the close event for modals and
therefore buttons of event registration are not reset correctly. This
commit fixes that behavior by preventing to close modal by clicking
outside of it. Buttons should be used and flow is now fixed.
Closes#25174 .
gevent 1.3.0 removed backward compatibility on gevent.wsgi.
make the new path the default
While the recommanded version on requirements.txt is 1.1, a server can not
launched with the 1.3
Closes#24780Fixes#24779
backport of 682ae1cc64
Before this commit, if you enable website_form_enable_metadata, that
will crash with a "KeyError: 'meta'"
This commit closes#24888
When trying to import an OFX bank statetement under MS Windows, a
Traceback states that BeautifulSoup is missing.
During the build process, py2exe didn't autodiscover that BeautifulSoup
is needed by the ofxparse package.
With this commit, BeautifulSoup is explicitely added to py2exe packages.
The Nightly VM was updated accordingly.
opw-1848202
The duration field on a workorder computes the total time spent on it.
The mrp_time_counter widget that is used to display it only computes the total
time spent on it by the currently logged user (ignoring the field stored value).
To help the user understand the inconsistency between the two values, we add a
help tooltip.
Since this really depends on the widget used to display the value, the tooltip
is directly put in the view.
opw 1854802
If you don't define an explicit address type, then the
record is not going to be accessible.
In the ORM:
>>> env['res.partner'].create({'name': 'Test', 'type': False})
res.partner(44356,)
>>> env['res.partner'].search([('type', '!=', 'private'), ('id', '=', 44356)])
res.partner()
>>> env['res.partner'].search([('type', '=', False), ('id', '=', 44356)])
res.partner(44356,)
due to the fact that NULL in the database is undefined and can't be
compared to a specific key.
Before this commit one could choose any journal for the registering exchange rate differences.
That could lead to accounting errors down the line
After this commit, we apply a domain on the field, and there is no problem afterwards
OPW 1851616
closes#25101
The percentage computation of statistics only uses the consumed ratings
>= 1 (through `rating_get_repartition`), while the initial search of the
first 100 ratings doesn't have this restriction. It leads to an
inconsistency between the ratings displayed and the percentages
computed.
Moreover, if there are less than 100 ratings, the percentage might not
be a natural number => use of float and round.
opw-1854863
- When merging partners with fields restricted to certain groups which the user doesn't belong, an access error is raised.
To avoid this, we only merge fields that are accessible by the user. We do so by using the method fields_get() that only returns the fields accessible by the current user.
Currently when connecting to a smtp server, if no response is returned
and no error is raised, the `SMTP()` instantiation method never ends.
This PR is inspired by 54a477d797 related to `fetchmail()`.
Possibly, a better way exists but it has to change some methods
signatures.
Closes#24877
opw-1851030
Before this commit, the complete list of orders of the pos session
was processed through the reconciliation mechanism to check if an
automatic reconciliation was possible (introduced in a controversial
'bug fix' at fe70f07, itself a backport of a master commit at
a2319b4). The goal of this auto-reconciliation was to avoid potentially
silent and numerous customer statements that could be reconciled
automatically.
This is mostly useless in a lot of cases, since a lot of users do not
set any partner_id value on the pos order - there is nothing useful to
reconcile. Going through the whole list of orders is time-wasting
(especially since the reconciliation method does not scale well).
Combine this with users who do not close their POS session often enough
and closing a session can suddenly take up to several hours to process
instead of several seconds with practically no obvious gain.
After this commit, only orders which have a partner set on them will be
auto-reconciled.
opw-1818838 and opw-1817172
Before this commit:
* Module A defines a field X of model M
* Module B inherits from model M without touching field X
* Module C inherits from model M and extends field X by giving an INDEX
/ NOT NULL constraint.
* Module B and C depend from Module A, but not each other
If all three modules are installed and Module B is updated, the INDEX /
NOT NULL constraint could be dropped.
This happens because Module B can be loaded before Module C is loaded,
if that's the case, then after the upgrade of Module B, during the
schema checking, we verify that the field object we have and the field
on the DB are the same, since Module B doesn't introduce the index then
this check is false and we drop the index. When we get to loading Module
C, we do not do any schema checking because the module is not marked as
`to upgrade`, therefore the index is lost forever.
To solve this, we re-init the models that belong to the set of the intersection
between upgraded and modified models and loaded and modified models.
Fixes#24958
Steps to reproduce:
- Enable multi currencies
- Make sure that the current rate of a foreign currency (i.e. $) is not 1.0 (i.e. 0.5)
- Create a purchasable product with a cost (i.e. 100€)
- Create a vendor bill in a foreign currency (i.e. $)
- Add the product on the invoice
Bug:
The unit price was equal to 25$ instead of 50$
Technical reason:
The function "_onchange_product_id" was called twice (the second time by function
"_onchange_uom_id") and the price unit was converted twice in the currency of the vendor bill.
The idea of this fix is to only convert in the currency when the unit price is set
by the system.
Fixes#24751
opw:1849212
Before this commit:
* Module A defines a field X of model M
* Module B inherits from model M without touching field X
* Module C inherits from model M and extends field X by giving an INDEX
/ NOT NULL constraint.
* Module B and C depend from Module A, but not each other
If all three modules are installed and Module B is updated, the INDEX /
NOT NULL constraint could be dropped.
This happens because Module B can be loaded before Module C is loaded,
if that's the case, then after the upgrade of Module B, during the
schema checking, we verify that the field object we have and the field
on the DB are the same, since Module B doesn't introduce the index then
this check is false and we drop the index. When we get to loading Module
C, we do not do any schema checking because the module is not marked as
`to upgrade`, therefore the index is lost forever.
To solve this, we re-init the models that belong to the set of the intersection
between upgraded and modified models and loaded and modified models.
Fixes#24958
Make one Payment
Reverse the entry of this payment.
Before this commit, only the lines in the receivable were reconciled.
The lines in the liquidity were'nt, leaving the two entries appearing
in some reports
After this commit, the four lines are reconciled two by two, even in the liquidity
account
OPW 1816641
closes#25026
If the `web.base.url` contains a trailing `/`, the replacement of the
`/unsubscribe_from_list` link won't work since the string to replace
will be `my_url//unsubscribe_from_list` instead of
`my_url/unsubscribe_from_list`.
Fixes#24731
opw-1848572
In 11.0, this change e9454e79 solved the use case of:
- opening the registration of a ticket
- discard
=> the page must be reloaded to register a ticket
A new report is that since 9.0, if we try to register 0 ticket we would
also have to reload the page.
This commit backports e9454e79 and solves the 0 ticket registration.
10.0 version of 9.0's #24966
opw-1851622
closes#24991
Carlos Dauden