- 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
The "connection test" was only attempting to establish a socket to the
SMTP server and then trying to login, if credentials were setup.
This would catch basic config errors but would fail to detect setups
were the SMTP server would forbid relaying, because of missing
credentials, missing STARTSSL mode, and other more complex cases.
By actually beginning a real SMTP session and sending the MAIL FROM,
RCPT TO and DATA command, we make sure that the server appeas willing to
relay emails from the current user address to an arbitrary recipient
address. Then we close the session before actually sending the message.
In order to have a valid destination domain with a valid MX server, we
use an odoo.com recipient address for the test, which should prove that
the destination server will relay to arbitrary addresses (unless the
destination server is an Odoo.com MX server ;-))
When an exception is raised during the course of a normal SMTP session,
smtplib's `sendmail()` method will close the channel automatically,
so any further attempt at sending SMTP commands will fail with an
SMTPServerDisconnected error, even just calling `smtp.quit()`.
This will shadow the original error, and make debugging harder.
Fixes#1493
This reverts commit 09a22e3bef, which was
attempting to fix a use case that was actually working.
It also created a duplicate `name_search()` method for res.country, in
addition to the one aliased to `location_name_search()`
It is indeed supported to import countries and states, using the
country code or state code as the imported value. These will be matched
uniquely thanks to the special `name_search()` performed for import,
forcing the `operator`.
And this is done while still allowing proper auto-completing for normal
UI case, where the "exact code match" will only promote an extra result
at the top of the suggested matches, rather than limit the results to a
single match.
The confusion apparently stemmed from the test case using "UK" as the
country code. UK is not a valid ISO country code, so it would never
match as expected.
With a user that do not have access to the the Event module,
go into Contacts > open a contact
Before this commit, a ACL error was thrown. This was because of the presence of
a smartbutton refering to events in the form view of the partner
After this commit, the form view of the partner displays correctly
OPW 1851783
closes#24931
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
Before this commit: links like `tel:+1-555-555-5555` were being replaced
both in javascript (prefixing `http`, when using the summernote editor)
and python (prefixing the base url, when they were added directly to the template).
After this commit: the replacement is avoided on links with `tel` scheme.
This is related to commit: 8b97a39
Have a model A with a o2m to B.
In the list have a field B > m2o > C
Also have a sequence field (widget handle) on B
Then Create a record A
Arrange yourself to have two new records B popping right away (through an onchange)
in the o2m. Their C field have to be empty
Resequence those two B lines with the handle
Before this commit, there was a traceback when trying to do an name_get on the C fields
Since both of them are empty, there is no record in the localData
Hence, no model. And also no records anyway, so no need to do a name_get
After this commit, there is no traceback, the name_get is avoided when no data is to be fetched
OPW 1853088
closes#24988
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
To compute the week number, the fullcalendar.js library uses the locale.
It depends on the day on which the week starts (usually Sunday in the Americas,
Monday in Europe), as well as which week is considered the first of the year.
In commit:
https://github.com/odoo/odoo/commit/717b472ef9ad6d2998cbefb4aafe2d1199e6235d
the starting day was explicitly added, however it was computed as isoWeekday.
The ISO first day of the week is always on Monday.
It resulted that if the locale used Sunday as first day of the week, the
calendar would consider it to be of the previous week, and thus displayed
(weeknumber - 1).
The fix does the same thing as was done in v10, taking the locale into account:
https://github.com/odoo/odoo/commit/df124080b624a8bdb86fec352fe690725ed36bac
opw 1853745
The new route make_event_ics_file received a list of attendee ids and was sending
the emails associated with these in an ics file, this could potentially
give out some information about the attendees.
(see commit 7862b2b71c)
Also the method get_ics_file had no reason to be public and so is now
private.
Closes#24711
Let's consider a Sales user U with no access to Purhcase
Steps to reproduce the bug:
- Create a SO with one line with the drop shipping route
- Validate the SO
Bug:
A access error was raised because the user has no access right on
Purchase.
opw:1851301
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
When archiving a product template P with one SO linked to it,
- Going to P by Accounting > Configuration > Products > P shows 1 sale
in smart button
- Going to P by Accounting > Sellable products > P showed 0 sale in smart
button
Now it shows 1 sale in these two cases.
opw:1852948
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
- Create a picking, set as 'Carrier': 'Free delivery charges'
- Enter a 'Tracking Reference'
- Validate the picking
The tracking reference is removed.
opw-1849279
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
When a line in a editable tree view has no acivable element
(readonly or toggle_bollean fields only) the currentFieldIndex
will be null after selecting the row, and when trying to edit a
field (boolean field_toggle in this example) an error will be
thrown when trying to put focus on currentWidget.
We need to check that the currentWidget is not undefined.
In the portal module,
the `index` method from the `web` module controllers
is overriden to redirect `/`
to the portal `/my` for the portal users,
instead of the regular backend `/web`.
However, when `website` is installed,
this behavior should not happen,
as you would like the signed in portal users to
be able to see the website homepage,
and not to be redirected to `my` when
they try to access `/` root path of the website.
Because the override in the website module was done on the
`index` method coming from the `web` module instead of the `portal`,
according in which way the Python module were loaded,
it sometimes redirected to `/my`, sometimes it correctly
displayed the homepage. This is because the modules are not
loaded in a determinist order.
To summarize, on runbot, if you logged as portal/portal,
one time on two you were redirected to `/my`, and the other
time you saw the homepage correctly.
As `website` depends on `portal`,
we have the possibility to override the `index` method
of `portal` instead of the one of `web`,
to force the determinist order,
and therefore the determinist behavior of the homepage for
portal users.
When installing the `account` module, some of its master data is
installed as `l10n_generic_coa` data.
During the uninstallation of `account`, `l10n_generic_coa` is
uninstalled first since its a dependency of `account`, but some of its
master data cannot be uninstalled yet as its still being referenced in
some `account` et al tables.
When `account` is being reinstalled, the datas will be updated instead
of created since they were left intact in the database, this proves
troublesome as the code YAML interpreter adds some context variables
when creating records but not when updating records, these context
variables are necessary in order to trigger some onchanges and defaults
for fields that are required, since this does not happen we get a `NOT
NULL CONSTRAINT` error when re-installing the `account` module.
This patch solves this issue by adding an uninstall_hook that will
delete all ir_model_data that belongs to the module `l10n_generic_coa`
upon its uninstallation.
Fixes#25005
- Create the following BOM for Product A:
Comp 1: 1 Unit(s)
Comp 2: 5 Unit(s)
- Update on-hand quantity:
Comp 1: 10 Unit(s)
Comp 2: 30 Unit(s)
- Create a MO for 10 Unit(s) of A
- Check the Quantity on report 'Stock Level Forecast':
Comp 1: 0 Unit(s)
Comp 2: -20 Unit(s)
- 'Check Availability' on the MO
- Check the Quantity on report 'Stock Level Forecast':
Comp 1: 0 Unit(s)
Comp 2: 30 Unit(s)
The `partially_available` state has been added with Inventory
refactoring in v11, and needs to be taken into account.
opw-1849556
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
Before this commit, some values of res.config.settings were saved
(e.g case of website settings were some fields are related)
After this commit, they are not saved
OPW 1853230
closes#24972closes#25028
- Create a BOM for Product A, using Component B
1 Unit of a is built with 1 Unit of B
- Update on hand quantity for B to 3.0
- Create a MO for 5 Units of A
- Update the quantity to produce to 3.0
The button 'Check Availability' never disappears.
The core of the problem is that the move remains "Partially Available".
Indeed, if there is no product available (`available_quantity <= 0`),
the stock move is skipped and its availability status is not updated.
We slightly change the logic by first checking if we need any quantity.
If not, the move can be considered as assigned.
opw-1850499
Martin Trigaux