When adding a partner (without any backend or portal access) as a
follower of an invoice, project, task or SO, the mail received contains
a 'View ...' button. When clicked, it redirects to the login page.
In the case of projects and tasks, no `auth_token` exist, so the user
faces an access error in the backend. For the other objects, it
redirects normally to a frontend page.
This feature is not yet complete in v11. So simply hide the button until
this is properly developed in master.
opw-785824
I clearly missed some bits in 01e3514147
as _get_access_token was still using urllib.Request despite that
import having been removed.
Fix it up by properly converting it to requests.
Fixes#21544
The ORM does not currently, an probably won't support two fields with
the same name in different modules that do not depend on each other.
This is obviously a nasty hack, but it's the best one can do for a
stable branch.
THIS IS WHY WE HAVE DEPENDENCY MODULES, PEOPLE.
Before this commit, if you had an uom with an unicode character as name, it
would throws an UnicodeEncodeError.
Now, since the str() parsing is not needed, removing it fixes the issue
This closes#20325
This closes#21374
It was the purpose of this commit fea667a243
However it uses purchase uom in any cases and not
only vendor bill.
This commit correct it by using it only if a purchase
order is linked to the invoice.
The 'main_flow_tour' noticed an error that we
had already corrected for the input fields.
See here: @a71f2237
In fact the same error can occur in the many2one fields
for the exact same reason.
It's why the 'main_flow_tour' crashed at the following step:
".ui-menu-item > a:contains('the_flow.customer')"
Before this fix, when editing a translatable input field,
the translate button becomes unclickable if the input text
is to long.
With this fix, the translate button is always on top of the input text.
opw-777914
Before this commit M2Mtags widget did not translate.
This was because no context was given to the rpc that fetched the fields
Hence, the lang was not passed.
After this commit, M2Mtags translate well
OPW 784396
`str.format()` is only safe with byte-strings arguments, not unicode.
Unicode parameters would be automatically encoded using 'ascii'
encoding, resulting in a UnicideEncoreError in case any non-ascii
characters are present, which is quite likely.
Using '%' formatting on a str format string works the other way around,
and will cause the format string to be decoded into unicode if any
unicode params are present. This is typically safer because we never
use non-ascii characters in our format strings.
It also feels more natural than having to coerce the format string to
unicode using a u'' prefix.
This issue does not occur in Python 3, where either syntax will work.
Depending on the payment flow, the `email` field may not always be
present in the token data coming from Stripe.
Currently, it is missing in s2s mode, because we do not send it.
To avoid a KeyError during creation of the customer, we can use
token["card"]["name"] instead, which is always provided (it contains
either email or cardholder name), or the explicit ` description`,
when provided.
As the field digit doesn't exist on currency, we use decimal_places
instead which is the field containing the number of digits of the
corresponding rounding field
When fetching batched namegets (typically after a default_get), we need
to evaluate the context that we send to the server. This may be
important for models with a custom name_get method. (note: overriding
namegets should be avoided if possible)
With the new views refactoring, this was not done properly and the
'view' context was sent instead. This is not really critical, the proof
is that it took a few months before getting some complaints, but this is
definitely a bug.
To reproduce, simply add a context attribute to a m2o field in a form
view, with a non empty value in a default get, and look at the context
sent to the server.
Unlinking such a record causes a cache invalidation, that drops the values of
other company-dependent fields to set. This may cause other company-dependent
fields to be set to their former value.
OPW 782080
As there's a check for unique supplier reference numbers, you can't duplicate them as the field is copied on the duplicated record. This patch removes the copy for emptying the error.
@Tecnativa
Before this commit, when a localization defined default payable or receivable
accounts on partners (like l10n_do does)
The reconciliation tests that involve an invoice on the one hand and a payment on the other hand
broke just because the accounts of the payment and the one of the invoice did not match
After this commit, we force the receivable or payable account to be the partner's (if available)
and the tests do not break
Before this commit, when printing all orders from the POS interface,
the ticket sometimes showed weird amounts (like 128.25000000001).
This was due to the usual problem of representing a float and has nothing to do with Odoo.
After this commit, the templates correctly display the amounts, rounded according to the currency
We do this by applying the relevant qweb widget (or calling the right format function in JS)
OPW 784626
Related fields that are not readonly are rewritten each time you save the
associated record, provoking performance problems.
Moreover, we don't want to allow an employee to change its department through
an attendance record.
Closes#21441
Suppose we convert a x2many field `foo_ids` with a many2one sub-field `bar_id`.
The conversion of the values of `bar_id` generates pairs `(id, name)`. Before
this patch, the method `name_get` is invoked on every value, one by one.
Rewrite the code to ensure that `name_get()` is invoked on all values at once.
In Pick - Ship:
- validate a sale order which scheduled date is an hour in the future.
- validate the WH/PICK picking
Before this commit the WH/OUT picking 's scheduled date was set a day in the **past**
This was due to the implementation of datetime substraction and timedelta, which,
in case of a negative value, would take -1 day and some complementary values (hours, minutes etc...)
(the difference is complementary)
After this commit, the WH/OUT picking 's scheduled date stays what it was in that particular use case.
OPW 784452
When an error happen (which may have been intended as such and ignored
down the error pipeline) in google_account/google_calendar there was
some typos that tracebacked.
opw-783271
closes#21263
Several issues arise with the virtual keyboard.
Issue 1
- Go in client list
- Go back to product list
The keyboard is still connected to the client search field.
Issue 2
- Go in client list
- Add a new client
- Click on any field
The keyboard is still connected to the client search field, it's
impossible to fill in any client data.
opw-784613
This commit basically reverts 4974f8edb7
The fix was unstable (as restoring a feature that was not there
before release, even if originally merged before). This was in
particular breaking saas modals as lots of them are still opened
using 8.0 system... and opening them this way might make them appear
below their own backdrop in the new system the mentioned commit
restored.
We will think about that feature again for a future version.
Pierre Masereel