- Create a product with variants which can be sold in the POS
- Open a POS session
- Delete a variant (e.g. change the attributes)
- Sell the product in the POS, validate
The POS order cannot be created because the product ID doesn't exist
anymore.
We extend the existing constain on `product.template` on
`product.product`.
opw-1850598
- Create Product A with 5 Unit(s) on hand
- Created SO for 5 Units(s) A, validate SO and picking
- Return of the same quantity, but assign an owner
- Created RMA for 5 Units(s)
A warning generated: 'A is not available in sufficient quantity in ...'.
By assigning an owner on the return, the product is not considered
available. However, this makes sense since we are not owner of the
product, so it should not be valued.
Ideally, we would need a field `owner_id` on the RMA. Since it is not
available, we use `partner_id`. the logic is the following:
- try to reserve with owner_id = partner_id
- if the available qty is not sufficient, try without owner
When the stock moves are created, we apply the same logic to know
whether we need to create the move with an owner. Note that this is not
really sufficient. Ideally, we should reserve the quantity to repair
when we check if the quantity available is sufficient.
opw-1854346
`sale_timesheet` adds a value to the selection field `service_type`, if
any product.product or product.templates are set to this new
`service_type` and then the module `sale_timesheet` is uninstalled, the
`service_type` field won't be implicitly reset to the default, existing
value of `manual`, due to this, when accessing a view displaying
product.product records the view will crash and won't be accessible as
long as it contains an undefined selection value.
this commit explicitly resets the field to the base value upon
uninstallation.
opw-1856776
res_config_settings.website_id should be ondelete='cascade', however
that is not suitable for stable, so we emulate the ondelete cascade
with an SQL query during ir.model unlink (website uninstallation).
Fixes#25078
According to Authorize.net documentation, the state code should only be
used for United States. For the other countries, use the state name
instead.
opw-1854278
Otherwise the time is printed using the timezone on the user printing
the badge. This fix is inspired by how the times are rendered by
website_event (e.g. website_event.index).
Using the date_{begin,end}_located fields was considered, but their
formatting is not configurable and they result in lines that don't fit
well on the badge.
opw-1853238
User B mentions @UserA in a channel on discuss
User A gets two notifications: one for direct chat,the other for the channel
User A clicks on the notification for the channel
Before this commit the form view of the channel was opened
After this commit, the channel is opened in discuss
OPW 1849577
closes#25074
- Create a PO with 2 different product lines (A & B), confirm.
- Change quantity of B and save
The chatter message mentions A, while the quantity of B was changed.
opw-1849258
When creating an allocation by employee tag if you copied any allocation
made, it was still linked to the parent allocation, hence when
confirming/refusing the parent allocation it would confirm/refuse the
copied one too.
Closes: #25106
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
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
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`).
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: 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
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
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
The website_event_questions override EventRegistrationForm's method
on_click and expects the returns is a deferred.
This commit provides a deferred in all instances avoiding an error.
Also what was done in e9454e79 and enables back the Register Now
button if no ticket was selected.
opw-1850527
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.
Also if website_event_questions was installed there was an error
preventing an error message to be displayed.
saas-15 version of 9.0's #24966
opw-1851622
closes#24967
Gustavo Valverde