- Create a SO with an ticket for an event, confirm
- On the attendees wizard, click on 'Apply'
The event ticket is remove from the registration.
This is because the event ticket wasn't saved when creating the
registration line.
Complement of commits 7492c97bf4 and 0717bb6c0d
opw-1920464
closesodoo/odoo#30262
Before this commit, in the organization chart, when a manager that have too many
subordinates, and we want to view all the subordinates clicking the '...' button. There was
an error in the breadcrumbs, the text 'Undefined' was shown in the place of the manager's
name.
Now, the breadcrumbs shows the name of the manager.
OPW-1923990
closesodoo/odoo#30231
Commit 68e9d5504c makes the redirection type mandatory, which is
logical. Since we can't add such a constraint in stable, we make the
field required in the view and assign a default value (in case the
module is not upgraded, which is very likely to be the case).
opw-1924983
closesodoo/odoo#30252
Some views have the primary mode while having an inherit_id view
In such views, if the user wants to change the inherit_id,
the mode must remain primary.
The use case behind this is a user who want to change
the inherit_id view of the view
product.product.form (product.product_normal_form_view)
to another view.
This view is in primary mode while having an inherit_id
(product.product_template_form_view).
In such a case, the primary mode must remain,
otherwise the view will no longer be opened by default
when opening a product.
Indeed, when searching the default form view of a model,
it only searches for primary mode views for this model.
The `all` is there because this is an `api.multi` method.
We could consider adding a `self.ensure_one`,
but it breaks the API if someones calls this method with multiple records.
This is likely to happen, as this method is used
in `write` which is likely to be called with multiple records.
In my opinion, in master, this should be replaced by an
onchange so the user can see the change of mode
when he adds or remove an inherit_id for a view.
opw-1916324
closesodoo/odoo#30241
This is essentially a backport of module l10n_be_intrastat_2019 made for
Enterprise v12 + the refactoring needed on the original v10 module to
allow the changes to apply where needed.
Was requested by opw-1887019
closesodoo/odoo#30400
The coupon program applies only one rule based on the sequence.
Steps to reproduce the bug:
Create a promotion with 5% if untaxed amount is greater than 1,000$
Create a promotion with 10% if untaxed amount is greater than 2,000$
Create a promotion with 15% if untaxed amount is greater than 3,000$
Create a SO for 3500$
Click on "Update Promotions"
Bug:
The 5% promotion is applied because it is the first one in the list.
Solution:
Display the sequence field in the list view with a handle to sort the different
promotions.
closesodoo/enterprise#3209
- Create many reconciliation models (more than 100)
- Try to create a manual reconciliation entry
The reconciliation models buttons are displayed on top of all fields,
making it impossible to encode any data.
We limit the size of the `div` to 54 pixels, which corresponds to 3
lines of buttons. All buttons are still accessible thanks to a
scrollbar.
opw-1890781
closesodoo/odoo#30212
When removing the editable attribute on the list view
of th o2m towards order_line, when adding a line,
the price_total of the line was neither computed nor sent to the onchange
of the sale order
now it is
OPW 1914740
closesodoo/odoo#30234
The field reference_type has been renamed invoice_reference_type in v11.
The selection value 'bba' for that field has been renamed 'structured'.
We update the template to reflect these changes.
Discovered thanks to a forward port of that field up to v12.
closesodoo/odoo#30224
When posting a URL containing a semicolon, odoo stops the link
before the semicolon instead of continuing the link to the end
although it is a valid characters in URL (see RFC-3986)
e.g. the url "example.com&foo;bar" matches "example.com&foo"
instead of the whole link
opw-1918367
closesodoo/odoo#30198
- Create the following attributes with values:
Size: S, M, L, XL
Color: Black, White
- Create a product template with the following attribute values:
Size: S, M, L, XL
Color: Black
The `name_get` of `product.product` returns `Name (SIZE, Black)` while
it should only return `Name (SIZE)`.
When using `attribute_id.value_ids`, the list of values contains all
possible values of the attribute, not only the values which apply to the
given product. In this case, it contains 'Black' and 'White', therefore
the condition `> 1` is verified and the attribute is kept for display.
We go back to the original filtering, and add `attribute_line_ids` in
the list fields read in order to avoid prefetching.
opw-1922140
opw-1922447
closesodoo/odoo#30273
Cherry pick of 5b769650d6 in version 11.0
A customer can pay an order with a non-cash journal (e.g. a credit
card through a stand-alone terminal).
When this order has to be refunded later it should be possible to do
so on that same journal.
Some code prevented this from happening, notably a check in
order_is_valid which explicitly prevented this for an unknown
reason. There is no explanation in the
commit (4647f896a4) introducing that.
This commit allows the following:
1. input what you want to refund with a negative qty
2. click 'Payment'
3. click the Credit Card (type Bank) journal
4. (amount is auto-populated)
5. click 'Validate'
opw-805302
opw-1913731
closesodoo/odoo#30218
- Create a bank statement with more than 80 lines (therefore more than
80 AML)
- Reconcile the lines
- Go back to the bank statement, and try to add a new line
An error arise:
"You cannot do this modification on a posted journal entry, you can just
change some non legal fields"
The error arise on the `move_line_ids` field on which the web client
tries to write.
Actually, this field is hidden since it is only used in the domain of a
stat button. We can make it read-only.
opw-1921138
closesodoo/odoo#30266
The super call of action_payslip_done executes the method compute_sheet.
Without this compute_sheet call, there is no salary lines and no accounting
move is created.
closesodoo/odoo#29737
Start a message mail (respectively note) in the chatter. Attach a file.
Switch to note (respectively mail). The attachment is lost.
With this commit, we keep the attachments after the switch.
opw 1925588
closesodoo/odoo#30197
- Set FIFO as costing method in product category
- Create a stockable product with the category configured previously
- Create a SO with the stockable product for 1 unit with dropship route
and confirm the SO
- Confirm the PO created from the Sale Order to generate the delivery
- Process the stock picking
- Create a new Landed Cost with the stock picking delivered with a cost
line with split method "Equal".
- Generate the valuation adjustments and confirm the landed cost to
generate the journal entry
The debit account is wrong because the system takes the inventory
valuation account instead the expense account.
Odoo must take the expense account because the product never enter to
the company inventory, so is a cost of sale.
opw-1922633
closesodoo/odoo#29947
Detected with OPW 1920765
Reproduce : set multi-companies, install accounting. The due amount for all companies is the sum of the due amount for every single company
Cause : the context for company_id is not set in account.move.line:_query_get
Solution : set it in res.partner:_credit_debit_get in case _query_get is used elsewhere
closesodoo/odoo#30463
Go to 'delivery methods', edit a delivery method.
Click on 'install more providers'.
You land on the 'Apps' app, already filtered on the 'delivery_' modules.
Click on 'more info' of a module: nothing happens.
It should open the form view of the module.
What happens is that the action doesn't contain 'form',
so the framework fails to open the form view from the kanban view.
opw 1928711
closesodoo/odoo#30437
- Create a product where the associated product category has Costing
Method "Average Cost (AVCO)"
- Create a PO. Order:
2 units at 40
4 units at 35
- Receive the picking
The cost of the product is set at 35 (or 40, depending on the order of
the lines in the PO).
Since we are in a situation where the available quantity is zero, we
enter in the `if float_is_zero...` condition, where the `qty_done` is
not set.
We should set it in all cases.
opw-1907328
closesodoo/odoo#30422
Before this commit, when the journal entry date was duplicated, the
maturity date (in the journal entry lines) stayed unchanged (it kept the
values of the original journal) and the user wasn't able to modify it.
Now, when the user duplicated a journal entry, the user can modify the
maturity date.
Note that, as is the case for the journal entry date, the maturity date
can't be modified after saving the journal entry.
OPW-1914706
closesodoo/odoo#30393
- Create a Public Pricelist without discounts
- Create a pricelist with a discount for all products, with 'Discount
Policy' set to 'Show public price & discount to the customer'
- Assign the discount pricelist to the administrator partner
- Go to the eCommerce as public user (or any user with the Public
Pricelist as default)
- Add a product to the Wishlist
- Go to the Wishlist
The discount of the admin pricelist is shown.
This is because the `product.wishlist` is browsed as superuser and the
computed field `price_new` depends on the user (ultimately through
`_website_price`)
opw-1912726
closesodoo/odoo#30358
Create a sale order. Confirm it. Add a new line. Change the UoM on this line.
The onchange is applied, modifying the unit price.
Save: the saved product UoM is the default one.
So for example if the user changes the UoM from day to hours,
he will sell one day for the price of one hour.
This is because the field product_uom is set to read_only if the state of the
sale order is confirmed ('sale') (as well as if the state is 'done' or 'cancel')
However it is still possible to change it when adding a new line.
opw 1923534
closesodoo/odoo#30420
ea6e7379a3 removed the few intersphinx
refs to sqlalchemy & django, so these mappings have not been necessary
in a year. This is especially annoying as the currently configured
sqlalchemy mapping has been very flaky / regularly failing.
Remove the mappings entirely.
closesodoo/odoo#30397
Some sips provider don't use 2 as key_version.
E.g. mercanet uses '1' as production key.
Now we allow to override it in Ir Config Parameter for stable version.
Todo:
Need to make it customizable by end user into the configuration of acquirer.
Courtesy of BEK for reporting
opw-1916316
closesodoo/odoo#30185
Previous to this commit, if one were to create an ir.model.field with a
poorly constructed domain (read: SyntaxError), the server would properly
send an error message stating that an Error occurred, however this would
be too late as the registry with the bad code would have already been
reloaded, this meant that the registry would be left in an unstable
state (read: crashed).
With this commit, a constraint on the domain is added so that we confirm
that the code in the domain field is properly constructed, thus no need
to reload the registry and therefore no crash.
closesodoo/odoo#30157
Before this rev., a crash might occur when the user quickly
switched twice between pages (e.g. go to page 2, then page 3) on a
slow network.
In the given example, when data of page 2 returned, the list was
re-rendered. Unfortunately, the offset of that list' datapoint was
already changed due to the switch to page 3, meaning that the view
tried to render a page that wasn't loaded yet, leading to a crash
if there were modifiers to evaluate, or to empty records being
displayed.
This rev. ensures that the view is rendered with the data of the
page it expects.
closesodoo/odoo#30150
On the PO form view, change the order_lines inline view:
- the tree becomes not editable
- allowed modes are tree,form
Add a new order line, the form view of order_lines opens up
Modify some stuff, then save and new
Before this commit, it crashed because some fields were expected in the tree view
that were not defaulted in the form view by the JS framework.
After this commit, this flow doesn't crash because we make sure every field
in the tree view is present in the form view
OPW 1917111
closesodoo/odoo#30219
test_web_planner throws errors like this on some environments:
AssertionError:
'/web#action=135&view_type=list' != '/web#view_type=list&action=135'
the urls in web_planner are created with a dict for the parameters to
create the urls. dicts are unorderd up to python 3.5. (see
https://www.python.org/dev/peps/pep-0468/)
As the urls /web#action=135&view_type=list and
/web#view_type=list&action=135 are equivalent we now test if the
parameters are the equal in the url regardless of their order.
closesodoo/odoo#30138
Since multi-website, we COW (copy on write) views when editing a view on a
website.
This is causing 2 issues related to module install/update:
1. During a module install, when creating an inherited view, it will create
that view as expected on the generic tree.
But that generic tree may not be used on website(s). Indeed, if the view
was edited, we are now using a copy of the view instead of the original
XML view (with an xml_id).
That copied view won't get the new inherited view in its view tree.
Now, we correctly copy the new view under every specific view tree (if
exists).
2. During a module update, when updating a view, it will only update the view
having the xml_id, so the generic one.
But most of the time, the generic view is not used as it was usually COW'd
and the specific view now replace the generic one.
Now, we also apply the update on the COW'd view. Note that only unmodified
field will be updated, this behavior basically mimic the noupdate behavior
on view's ir.model.data.
Step to reproduce for bug 1:
- Install website_sale module
- Go to a product page and then enter edit mode
- Make a modification to trigger COW, eg edit the information area under the
price "30-day money-back guarantee".
- Now install website_sale_comparison module
- The product page won't have the comparison button as the comparison view
inheriting the product view was created on the generic tree and not copied
on the specific tree (COW'd before the comparison module install).
Step to reproduce for bug 2:
- Repeat first 3 steps of bug 1
- Now make a modification in a view from the XML file in
website_sale_comparison module and update the module
- Only the view with the xml_id is updated, not it's COW'd views. This mean
that only the generic view is updated and not the specific one(s) really
used on the website.
task-1920487
closesodoo/odoo#29956
Christophe Simonis