Since https://github.com/odoo/odoo/commit/d1fc62df0b850c56360c1e5391c69eb807d0fe46:
When several ir.actions.todo are created, only the last one is
considered and the first are marked as done. Thus, there are never
multiple "open" todos at the same time (while before this, only the
first todo was done and the other ones were done on subsequent module
installations, which makes no sense).
The new system however broke stuff. Indeed, when installing the
eCommerce, we expect to land on the "Choose a Theme" page (if website
was not already installed). This was not the case anymore, as the
last todo in that installation is "Redirect to /shop". To fix the
problem, the system is changed to not consider the "last todo" but
"the todo with highest priority, or the last one if same priorities".
By making the "Choose a theme" todo high priority, this solves the
problem.
A better system would be to make todos depend on each other... but
that would be a task for master.
- simplify unicode handling for Py2 and Py3
- fix Py3-related bugs, such as passing bytes for context['tz'], making
the conversion silently fail, or attempting to decode() a text
- There was no feedback to the user when executing the Charge
transaction in server-to-server mode, while it could take several
seconds, with the normal UI/action buttons still available.
- Stripe integration was almost working along with `website_quote`
payment, but entirely broken with `website_payment`, and partially
broken with `website_sale`.
Fixing it required:
+ More leniency in processing optional transaction parameters, which
may or may not be present in the various payment flows.
+ It also required more precautions when locating the transaction for
which the Stripe Charge was to be created, which passed in different
manners in the session. The route now supports an explicit `tx_id`
to allow forcing the transaction without risk of mixing different
payment flows.
+ FIXME: There is still some amount of duplication and bad modularity
in the handling of the various payment flows in relation with
Stripe.
- We provided very little metadata to the Customer and Charge APIs of
Stripe. We now pass more names and references to make Stripe payments
easier to manage in the Stripe dashboard.
- In some cases, selecting Stripe as payment method caused a second
inclusion of `stripe.js`, raising a JS error because of the
duplication.
- Strip whitespace in emails: the Stripe API raises an error for
transactions done with invalid emails, including with
leading/trailing whitespace.
Customers will have a hard time figuring out the problem
by themselves, so we should at least strip whitespaces.
When double-clicking on a link/button, the link dialog is opened. The
problem was that the "btn" class is sometimes used on non-link elements.
While this should not be, the editor can easily be adapted to this.
Purpose
=======
Invoicing is now optional with ecommerce and POS -> there shouldn't
be an Invoicing tab in product form by default
Specification
=============
- Move 'Customer Taxes' field from 'Invoicing' tab to right
below 'Sales Price' (in General Information tab).
- Move 'Invoicing' section from 'Invoicing' tab to 'Sales' tab.
- Add section 'Inventory Valuation' in 'Inventory' tab and move
'Cost' field from 'General Information' tab to this section.
Also move 'Landed Costs' section from 'Invoicing' tab to this
section (without heading 'Landed Costs').
- Rename tab 'Invoicing' to 'Accounting' and apply group
'group_account_invoice'.
- Remove 'Notes' tab and move descriptions and warnings to
relative tabs(Sale, Purchase, Inventory).
- Apply groups 'stock.group_stock_multi_locations' to 'Description
for Internal Transfers' in 'Inventory' tab.
- Improve tooltip of 'Description for Customers', 'Description
for Receptions' and 'Description for Internal Transfers'.
- Visible/Invisible 'Sales' and 'Purchase' stat buttons based on
'Can be Sold' and 'Can be Purchased' checkbox fields.
- Update 'main_flow_tour', set trigger 'Sales' instead of 'Invoicing'
as now fields 'service_policy' and 'service_tracking' will be placed in 'Sales' tab.
- Move 'TaxCloud Category' field from 'Invoicing' tab to 'General Information' tab.
- Rename ebay option 'Use eBay' to 'Sell on eBay' and move 'ebay' tab next to 'Sales' tab.
- In 'Sales' tab, set 'Subscription Product' field before description and add
string 'Subscription' to differentiate it.
Full details and discussion under : https://www.odoo.com/web#id=33939&view_type=form&model=project.task&action=333&active_id=131&menu_id=4720
When a user clicks on an input or a select field
in Safari on IOS, Safari has a behavior of zooming-in
on the field when the keyboard opens.
Even after the user dismisses the keyboard, the screen
still stays zoomed-in. The user has to then zoom out manually.
Now, the user is not allow to zoom-in at all.
This is already the case with the Android application.
We now have the same behavior between the two apps.
Not used since a while, remaining of old res.request. Requests have been
removed at 881a76dbcf . Links have been kept because still
used in some reference fields. It seems the last use was in OpenERP v9.0
in crm_claim module. As links are not used since a while let us get rid of
it.
As can be seen in https://github.com/scottjehl/Device-Bugs/issues/8 a
combination of "-webkit-overflow-scrolling:touch", "position:relative"
and "overflow:auto" can have unexpected behavior on iOS.
The issue solved here is that writing in a form view inside a modal in
iOS (at least version 10.3) would make the whole form body invisible
until edition is ended.
This commit fixes this by adding a CSS rule which avoid the iOS bug.
opw-774396
closes#20314
When a user clicks on an input or a select field
in Safari on IOS, Safari has a behavior of zooming-in
on the field when the keyboard opens.
Even after the user dismisses the keyboard, the screen
still stays zoomed-in. The user has to then zoom out manually.
Now, the user is not allow to zoom-in at all.
This is already the case with the Android application.
We now have the same behavior between the two apps.
We have problems when trying to validate our EU VAT report because some vat number are wrongly encoded in Odoo.
There are 2 problems:
1) We use vatnumber library to check the validity of the VAT number entered by the user on website.
That library removes the following characters '.' and '-' in order to perform the check and
thus can return True for a number like 123.123.123.13 or -123-3454-34
And those VAT number are then saved in our database but are rejected by the state
as VAT number should only contains alphanumeric character
-> Solution: prevent entering vat number with other characters than alphanumeric for users that are located in EUROPE!
2) Usually VAT is prefixed by country code, however some people in europe managed to bypass the system
by prefixing their VAT number with CC instead of their country code, CC is consider valid in odoo
(it means Country Code) but is not a valid European country code in general, which means that those
people that should have pay some tax have not. Which is a huge problem.
-> Solution: prevent the use of CC as country code by the user when entering a vatnumber only if the user country is in EUROPE!
source: https://en.wikipedia.org/wiki/VAT_identification_number
opw:772621
FIX: amount_currency can allow negative searches
IMP: can search on positive or negative amount only if use '-' or '+'
IMP: search for move lines based on the amount by clicking on the balance
amount. Search in 2 currencies if possible.
Display the 'money' icon in the balance amount line when the user is in
multi-currencies and there is a currency different from the one used in
current line.
issue: in the 'match' part of a reconciliation line, if the user uses the
search without any line as result and validate the selected proposition,
the line is removed but the account or partner reconciliation is maybe
not finished.
A bug happens when you enter a number with more than 2 decimal
if you unfocus/focus the field it will truncate it.
This commit change the decimal precision and use the same digits
than other fields used in stock.
opw-775791
When put a quantity in a pack the reserved quantity is
split between the original move line and the move line
for the pack.
However in order to compute the quantity left to do. The
system compare the quantity reserved in term of quant UOM
and the quantity done with the move line UOM.
This commit compare both fields in move_line's UOM.
Purpose
=======
If there is no picture attached to a task, the user doesn't understand how to add a cover image.
Sepecification
==============
- "Select" button to select image => Display only if we have images
- "Remove Cover Image" => Display only if image already set
- "Upload and Set" => Always visible , highlight button if no images. Image uploaded via dailog box should automatically set on task kanban and add to the "Attachments" in task.
Purpose
=======
The attribute name isn't required on the <filter> tag. If not set, it can't be selected with a xpath and it can't be overwritten.
A lot of PR are coming from the community just to add a name on a filter because:
- It can't be selected with a xpath.
- It can't be used with `default_search_foo` on an action context.
Specification
=============
Make the atttribute name required
When we generate commands for many2many, it could happen that the id was
in the list of changed fields (when we are in a new records, with a non
empty initial onchange). When this happens, the server is not happy.
To reproduce this, open the uninstall wizard of a module in the 'App'
application. This creates a new record with a non-empty many2many
field. Then click on 'Show technical modules', this will trigger an
onchange which should not send the id field.
Fine tuning of 1108c150d9
When setting a pricelist to show the public price discount, it ignored
the pricelist item's base field (if not 'Other Pricelist') and set it
by default on the lst_price instead.
This did not work when you based your discount on the standard_price
(= cost price) with public price discount.
Now it does.
opw:775275
Purpose
=======
Simplify / reduce the warning message when we update a record in multi-languages
Specification
=============
1/ Make the translation banner little bit lighter in design
2/ Make it still visible when coming back from breadcrumb
Before this public users could see pages before their
date_publish.
request.website.is_publisher is a function that always exists. So the
if body will never be executed. Additionally, is_visible is a
non-stored computed field that can't be searched. So instead grab all
records that match and filter the ones that are visible.
This commit closes#20296
Since procurement removal introduced by commit 0e4f3bb959
product is editable once picking, timesheet,... are created.
However if the user modify the product it will not be reflected to
the related downstream object.
Previously it checks if a procurement order was linked to the sale line
and thus make it readonly.
This commit reproduce the old behavior by using a computed field that
can be override in sale_x modules in order to block the product
change for defined object.
- Create a vendor bill with a line linked to an asset category
- Validate the bill => an asset is created
- Refund the bill
The refund is also linked to an asset category. Therefore, upon
validation, a negative asset will be created.
The refund should not be linked to the asset category in a first place.
The user should cancel/modify the asset manually.
opw-775933
Nsis installer was installing the wrong MS Visual C++ redistributable
file. Python 3.6 needs MS Visual C++ 2015 redistruibutable files.
Also, Nsis now differentiate Windows architecture for the nssm service
and the MS C++ redist.
The created accounting entries have their debit/credit columns switched
because
- they use the sign of the value to post to decide if it should be
credit or debit
- an out move always have a negative sign
As this code is always called on out moves, we can safely reverse the
sign when getting the price_unit of the move.
Fixes#20080
Errors that are not whitelisted are not managed correctly due to the jsonrpc behaviour in Odoo.
When we make a post in json using iap.jsonrpc function, it contacts iap.odoo.com.
However, if this url does not respond, it falls back to the 'typo' page and the answer to the call
has a '200' status code but with an 'error' key in its response.
Currently, we manage the errors via whitelisting, which hides this kind of errors.
We opted to raise this error (odoo server side) as a UserError and to add UserError to the whitelist.
Christophe Simonis