In 10.0, the resolution of the m2o field in a read group was
done with a `read` (which sudo the name_get). So, the access
rights were bypassed to get the display_name of the related
records.
In 11.0, a call to `name_get` but not as `sudo` causing access
error in some case. For instance;
- a user has read access on project
- he log some timesheets
- its access to project is removed, but not the timesheet ones
- trying to access its own timesheet via the grid view (which does
a read_group)
- the user gets the access error for project.
The read_group should reproduce the behavior of the `read` method,
so the `name_get` for m2o field during a read_group is now sudoed
to restore previous behavior.
opw-1855942
In bd4f09f there was a typo in the domain portal message fetch (two `&`
instead of one), luckily this did not cause an error in 11.0
But in master expression.AND normalizes the domain, thus we got an error.
opw-1819702
closes#25131
Default group by is required in order to correctly display a kanban view on
vehicles.
By the way activities fitlers were missing. This commit adds them.
This commit is related to a recent commit adding activities in fleet, see
7356c3b5b6 for more details.
Due to timezone difference between two test users the state of activities
depend on the time when the test is running. Indeed if user 1 plans an
activity for tomorrow this could already be today for user 2. Test
that ensure tomorrow is correctly computed should therefore be done with
users being in the same timezone. Current behavior is correct as activities
manipulate date that cannot always be timezoned back to another timezone.
How to reproduce the issue before this fix: run the activity mixin tests
between 0:00 and 1:00 in +1 TZ (Brussels).
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
This is mandatory to ensure consistency of the data generated by the test, as stock pickings created from a PO are by design always created for the current date (there is no way forcing this), meaning that they always use today's exchange rate for their valuation.
Despite the fact we rewrite the date of the valuation moves artificially, we cannot correct the debit and credit values, since the anglosaxon entries get automatically reconciled (and you cannot modify a reconciled entry).
So, we have to make sure that "today"'s rate will always be the last rate we created in order to ensure complete control of the test. This deletion will have no further impact, as the transaction will be rollbacked at the end of the test.
Issue 1
-------
- Set a product with:
Inventory Valuation: Manual
Costing Method: Average Cost (or Standard Price)
- Receive 1 unit @ 10, set an owner
In the 'Inventory Valuation' report, the product is valued @ 10 while no
accounting entry was created.
The system simply multiplies the available quantity by the cost price,
without taking into account the ownership of the quants.
Issue 2
-------
- Set a product with:
Inventory Valuation: Automated
Costing Method: Average Cost (or Standard Price)
- Receive 1 unit @ 10, set an owner
In the 'Inventory Valuation' report, the product is valued @ 10 while no
accounting entry was created.
Once again, the system simply multiplies the available quantity by the
cost price, without taking into account the AML.
Solution
--------
A slight refactoring of the `_compute_stock_value` method is necessary
to make consistent the the FIFO computation and the Standard / Average
method:
- in case of manual valuation, the quantity on stock moves are taken
into account
- in case of perpetual valuation, the quantity on AMLs is taken into
account
The method `_compute_quantities_dict` needs a minor change so a `False`
value can be handled correctly.
The FIFO method is slightly changed:
- the quantity at date takes into account the owner
- in case of perpetual valuation, AMLs are used instead of stock moves
Bonus point: an error was discovered in `_create_account_move_line`
thanks to the test `test_change_cost_method_1`. The forced quantity
should follow the same sign logic than the product quantity.
opw-1849535
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
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
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
jem-odoo