- Removed 'Invoices' and 'Credit Notes' filters.
- Removed inherited view of filters to remove the 'Not Draft' filter.
- Renamed 'Not Paid' to 'Open' filter.
- Added new filter 'Paid'.
- When click on 'Invoices/Bills' or 'Credit Notes' link of 'View'
column from 'Customer Invoices' and 'Vendor Bills' dashboard, it
should be open invoices with a specific domain instead of default
filters.
Co-authored-by: Nicolas Martinelli <nim@odoo.com>
opw-1817236
Purpose
=======
It looks a little to restrictive to only allow bank journals on payment acquirers.
For example on could want to define a manual payment acquirer linked with a journal of type "cash".
Allow both journal types instead of only bank.
Before this commit, while performing a check on whether a customization
being imported was done using studio or not, we would assume that the
.zip would, at the very least, contain a data folder.
This is not the case as loose files can be imported and the data folder
is only generated by studio customizations.
To solve this, we walk over the whole zip instead of walking over the
data/ folder only (which may be non-existant), so loose files, files
inside the data folder and potentially files in other folders can be
parsed without raising unexpected errors.
Previously, trying to register a payment on today towards an invoice posted with a date prior to the FY lock date, was raising an error... which was completely wrong.
Before this rev., it crashed when trying to create records of the
res.users model. This is due to commit ad1cceb.
The 'default_get' of 'res.users' always returns a value for field
'groups_id', whereas the docstring of 'default_get' states that it
only returns default values for fields given in arguments.
Rev. ad1cceb changed a bit the way the result of 'default_get' was
processed, by iterating over the values instead of over the fields
in the view. So, before ad1cceb, 'groups_id' was simply ignored,
and after, the BasicModel tried to process it and it crashed when it
attempted to retrieve its fieldsInfo, as this field isn't in the
view.
This rev. restores the previous behavior.
Fixes#23303Fixes#23305
When uploading an image as attachment, the document viewer doesn't
support the EXIF data. Therefore, a picture taken with a non-zero angle
will not appear with the right orientation (preview or full-size image).
Unfortunately, supporting EXIF data is not trivial in Python or
JavaScript without external libraries. Therefore, we add a rotate button
which allows the user to rotate the image by 90°. Moreover, we add the
`image-orientation: from-image` CSS property, which is only supported by
Firefox.
opw-1814407
Let's assume a one2many displayed over several pages with a default
order such that a record, say R, that would normally be on page 1
is actually on another page. Moreover, there is an onchange on that
one2many which converts all commands 4 (LINK_TO) into commands 1
(UPDATE), which is standard in the ORM.
When the first line of the one2many was edited, the record R was
fully loaded, whereas it shouldn't have been (as it is not on the
current page). So basically, a useless read was performed.
Moreover, if there was an x2many field in the one2many list, a
crash occurred because relational data of R that shouldn't have
been read wasn't postprocessed by the BasicModel.
The useless read occurred because the one2many subrecords weren't
correctly sorted before checking if some of them/some of their
fields should be read. This is not the case anymore.
OPW-1816800
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
* Install sale_management, contacts
* Uninstall sale (not sale_management)
* Try to access any partner via contacts
-> BOOM, traceback: relation account_invoice_report does not exist
For some reason, uninstalling `sale` drops the SQL view for
account.invoice.report which in turn means that anything that requires
the view will break, this was the case for accessing the res_partner
form view.
Fixes#23270 by forcing account.invoice.report.init() upon
uninstallation of the `sale` module.
Purpose
=======
The warrant cost formulae has been modified at 5d22170.
Instead of using the (remaining) warrant costs formulae, use the corresponding field instead.
When only point_of sale module is installed, it is impossible to modify
existing taxes because the One2many tags widget doesn't allow to open the
taxes and edit them. So we add a menu item allowing to modify them.
It is needed if we want to set a tax included in the price.
Before this commit, when stroking "Enter" in the filter, a JS traceback popped, because no created lines where found
After this commit, we control that we have created lines
OPW 1814309
If the vacuum finds that there is nothing to do regarding the accounting
entries, do not call `_account_entry_move`, else an accounting entry
will be created for the entire cost of the compensated move.
opw-1817372
Remove wrong slash trailing
Now, in V11, matching of page are done on the exact name.
Previously, the error was transparent because we was using a
dedicated controller that allow trailing slash.
https://github.com/odoo/odoo/blob/11.0/odoo/http.py#L936https://webmasters.googleblog.com/2010/04/to-slash-or-not-to-slash.htmlhttp://example.com/foo/ (with trailing slash, conventionally a directory)
http://example.com/foo (without trailing slash, conventionally a file)
Google treats each URL above separately (and equally) regardless of
whether it’s a file or a directory, or it contains a trailing slash or
it doesn’t contain a trailing slash.
Different content on / and no-/ URLs okay for Google, often less ideal for users
Special case for homepage
Rest assured that for your root URL specifically,
http://example.com is equivalent to
http://example.com/ and can’t be redirected even if you’re Chuck Norris.
Before this commit, the sitemap will crash if you have some res.partner
without country that are publish and with an assigned_partner_id.
Now, we only search for customer with country that are set and avoid to have
a traceback:
File "/home/odoo/src/odoo/11.0/addons/website_customer/controllers/main.py", line 31, in sitemap_industry
loc = '/customers/country/%s' % slug(country['country_id'])
File "/home/odoo/src/odoo/11.0/addons/http_routing/models/ir_http.py", line 91, in slug
identifier, name = value
TypeError: 'bool' object is not iterable
The field `auth_signup_uninvited` is defined in the 3 aforementioned
modules, yet they are independant modules in respects to one another.
This means that whichever module is installed first will create an XMLID
for the field, if this module is uninstalled before the other two: boom!
crash when changing general settings because the res.config.settings
field set by the other two modules no longer exists.
To solve this, we simply ignore the field during ir_model_field.unlink()
Fixes#23171
Let's assume a one2many list view inside a form view, displaying
a single char field A. There is an onchange on the form view
returning a command 0 (CREATE) for the one2many. The command 0 only
specifies a value for field A. The one2many list isn't editable, so
when a sub-record is clicked, it is open in a form view (in a
dialog). In this form view, an x2many field B is displayed in a sub
list or kanban view.
Before this rev., it crashed when the user tried to open the
created one2many sub-record (returned by the onchange) in the form
view, because of the presence of the x2many field B, which wasn't
correctly processed by the BasicModel (its value was undefined,
whereas it must be a valid, empty, dataPoint).
Moreover, the limit of the x2many field B wasn't set, so a pager
was displayed as soon as it contained at least one record.
Fixes#22050
Due to the representation of floats, it may happen that the amounts in
the project overview appear with much more decimals than expected.
We use the usual `monetary` widget to render the amounts.
opw-1814843
Error messages are given by vendor and have specific meaning
Translating it does not specifally help to find out more about the problem
pos_mecury is intended for US market anyway
Method `get_day_work_hours_count` can return 0 if no attendance is found
in the calendar. Therefore, we must make sure to not divide by zero,
otherwise, boom boom.
Closes#22900
opw-1815095
The change in 3ae382f8d3a caused a similar error to ef91c141f6.
So the tour failed in enterprise because account_taxcloud caused a
customer tax to be added to the "Orange Butterfly" product.
Since the method `_get_leave_intervals` assumed that field `tz` is always filled in.
There is a case in default function, when `self._context` had key `tz` but its value was `False`,
which may causes null value of field `tz` and lead to mismatch interval between leave and payslip
This is more a architecture fix than a bug fix. With this commit, it is easier to modify the behavior of the dialog using the super function. like this: this._super.apply(this, arguments).opened(...)
PR #23255
Due to this commit: 3267e76520
Steps to reproduce the bug:
When registering a payment for a customer invoice in an other currency than
the company currency and marking it as fully paid, it raised an error:
"Wrong credit or debit value in accounting entry !".
Reason: counterpart_aml['debit'] and counterpart_aml['credit'] were both incremented
and it violated the constraint credit*debit=0
opw:815465
The function _prepare_invoice_line_from_po_line has not been
designed to compute in a right the quantity for a line in an
in_refund invoice. So it has no sens to display the field purchase_id
for a refund vendor bill.
Closes#23095
opw:816717
In case the discount product is misconfigured and therefore not loaded
by the POS, a traceback appears when applying a discount.
Add a comprehensive error message instead.
opw-817527
Several issues:
- If product `product_product_consumable` was deleted, an error is
raised.
- The default values are inconsistent with the fact that
`module_pos_discount` is `False` at POS creation.
- The domain should ensures that both `available_in_pos` and `sale_ok`
are `True`, otherwise the product won't be loaded by the POS.
opw-814426
The test_mimetypes and base_import modules need various files for their
tests. Before this commit some of those files (.ods, .odt, .xlsx, .docx,
.zip) were not included in the packages.
Fixes#22778
Commit a0f8ee92c3 solved the use case where
a quotation was created through the website shop and where the default quote's
template's require payment should be transmitted to the quote.
However, this commit made the field readonly
This present commit solves both problems by assigning a default to the problematic field
rather than computing it
OPW 817510
Commit 985c224 introduced a way to properly uninstall these two modules,
however if a user were to reinstall them the views would stay inactive,
in the case of sale_management this would mean some menus were missing,
in the case of account_invoicing this meant that not even the top-level
menu would not appear, effectively misleading users into thinking the
module was not installed.
The solution is to create a post_init_hook (to ensure that all
potentially missing menus are already installed) that activates the
previously deactivated menus.
Fixes#23245
Before this commit:
User timezone would be taken into account when displaying message date on
chatter. It would always display the hour in the server format (UTC).
Now, we correctly use the user timezone to format the date being sent by the
server.
This closes#22812
The POS recomputes order lines when the pricelist changes. This is
different from the sale app on purpose: in a usual POS flow the customer
and thus pricelist is selected after taking the order.
But users commonly use a 'Miscellaneous' product when they are selling
something that is not in their POS system. The user can select this
product and manually set the price. When now a customer is
selected (even if the pricelist has not changed) these miscellaneous
order lines get recomputed. So now the cashier is forced to input
these prices again.
To avoid this we keep track of lines that have had their price changed
through the UI and we don't update them.
opw-817353
Hiral Bhavsar