The date of the invoice is used for currency conversion in anglosaxon stock valuation. Before this fix, the tests crashed between june 6th and december 31th, as the demo data define a currency rate for USD on june 6th. Using the proper date on the credit note ensures the good rate (the one in application when making the credit) is always applied.
Since commit 6494f51171, all images in mass mailing are created as
attachments. This can lead to URI too long to be handled by some proxy,
e.g. Nginx.
opw-1853188
This allows to set up a mail alias per purchase journal. Then share that email address to your supplier, or use it internally to forward the vendor bills received by mail, to automatically create an empty vendor bill with the mail attachments linked, and the partner might be filled if the source email matches a supplier.
Thanks to the document preview on the side, it's now super easy and super fast to copy the vendor bill info from the received PDF into the account.invoice object. This would eventually be improved later on (IAP).
Was task: 37703
Was PR #22158
The `price_unit` on `stock.move` is not rounded since it is a technical
field. Therefore, the comparison might fail depending on the rate (which
happens after June 6th because of `base.rateUSDbis`).
- 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.
Christophe Simonis