This override was always sending the document to all the recipients.
If the user is only a follower, he sees the button but cannot access
to My Account as he's not a user.
Some computed fields have been added in v9 and are calling the method
_compute_day. This method accesses the project related to the issue
So a user portal is able to see his own issue, but cannot open the
form view as the prefetching is loading the fields. Hiding them in
the group base.group_user doesn't have any effect as the compute method
is called on the read. These information may have their importance to
the customer too.
We decided to compute these fields on superuser access rights.
Also the field project_id is displayed on the project_issue form view.
As this information is internal, we're hiding this also under the employee
group.
The access/follow/actions buttons on the notification email template
are sent only to employee. For this particular business model when
want all the users to receive them, as the portal users.
The access/follow/actions buttons on the notification email template
are sent only to employee. For this particular business model when
want all the users to receive them, as the portal users.
When the stock.picking record is linked to some pack.operation records,
the move line state displayed has to be the move line with the same product as
the one in the pack operation record.
opw:671192
As it's done few lines below,
in `set_message_done`.
The user could have a notication associated
to a message he has not, or no longer, the
write access, but he should still be able
to mark it as read.
opw-671188
Adding an attribute with only one value does not recreate the product,
but write this attribute on every product instead. However, the current
filter is not correct: it checks if the given attribute value is not
already in the list of attribute values of the product.
The appropriate check is to verify that the attribute itself is not
already in the list of attributes of the product. Indeed, there is a
constraint to prevent the same attribute to have two different values on
the same product.
BTW, it's a new api function (`mapped`) inside an old api module. Not
the cleanest way to do it, but simpler to write.
opw-671114
Adaptations following rev. 1684ae4:
The website pricelist is now dynamic, according
to the pricelist chosen by the customer on the website.
It's no longer a static pricelist, it's no longer
the public user pricelist.
Therefore, when computing the variants prices,
the prices should no longer be converted
from the public user pricelist to the current (context)
pricelist, but from the product currency to the
current pricelist chosen by the customer on the website
In addition, when getting the unit price,
`/shop/get_unit_price`,
the website current pricelist should always be used,
it should never fall back on the partner pricelist,
as, it's the user who choose his pricelist from the website
now (if he has specific set on his partner
form, it's that one which is loaded by default, and which
is returned by the website.pricelist_id)
In addition, the displayed currency on the ecommerce
must always be the current website pricelist currency
Adaptations following rev. 3622c0d:
A product can have no company set (not required).
Therefore, when attempting to set the `from_currency`
to the product company currency, this could return
`None`, if no company was set on the product.
`product.currency_id` ensures to always return a currency
for the product. It's the company currency
if the product has a company set, otherwise it take it from
the main company (`base.main_company`).
In addition, when editing the product price from the website,
the price must be displayed within the product currency,
as, if changed by the user, it changes the product sales
price directly on the product form, without any currency
conversion applied or whatever.
opw-670898
opw-671100
When installing or upgrating a module via the apps managing view, the
module updates are applied in a new cursor. So when getting the action
to do after updating the module, we need to have a transaction current
with commited transaction.
closes#11216
opw-660269
Commit cf62fdb4 introduces a default pricelist item for any new
pricelist. Therefore, this default data is not necessary anymore, and
leads to two identical pricelist items created by default for the
"Public Pricelist".
The dialog form opened when clicking on a membership line,
in the "Membership" tab of the partner form,
was just unbearable.
This revision improves the readability of
this dialog form.
opw-671144
On older iOS devices (like the iPad 2) webkit would crash when clicking
on the closing button. Newer devices like the iPad Air 2 and iPad Mini 3
do not exhibit this behavior. This occurs on iOS 9.2.1 but I expect iOS
in general is affected by this. This affects both Safari and Chrome as
on iOS they both use the same rendering engine.
When the POS closes it searches the xml_id containing the action ID,
which seems to trigger the webkit crash. So instead we will use the
xml_id directly in the URL, that's simpler anyway and it avoids an
unnecessary RPC call. Functionally this means you won't get the 'Your
internet connection is probably down' message anymore, but it's useless
anyway, as after closing the popup the webpage is blocked anyway.
A log of the crash can sometimes be seen in the iOS diagnostics logs
which indicates com.apple.WebKit.WebContent crashing due to
EXC_BAD_ACCESS (SIGSEGV). This log is not always present, but that's not
unusual for out of memory issues on iOS [1]. Presumably the segmentation
fault is caused by iOS forcefully freeing memory being used by the
browser.
iOS manages memory in an unusual way. Plenty of developer reports are
available online which indicate this [2], but no official documentation
from Apple exists that specifies exact memory limit amounts.
[1] http://stackoverflow.com/questions/16400431/ios-app-crashes-with-no-error-and-no-crash-report
[2] http://stackoverflow.com/questions/16319486/ios-ipad-has-1gb-ram-why-is-my-app-killed-after-using-30mb
opw-668268
meaningless entries like
` Checks that the bundle's cache is working, i.e. that a bundle creates only enough
become
` Checks that the bundle's cache is working, i.e. that a bundle creates only enough ir.attachment records when rendered multiple times
see https://docs.python.org/2/library/unittest.html#unittest.TestCase.shortDescription
An issue could arise if a preprocessed stylesheet asset is present
in multiple bundles: the first bundle will cache a version of this
file (identified by its url) and the second one will cache another
one. The next time the first bundle is rendered in debug mode, it
will use the last created record of the asset.
This could lead to design issues as, for instance, a less asset
could change according to another less asset included in the bundle.
We fix this issue by adding the xmlid of the bundle in the url's
asset. This fix another inconsistency as the compiled version of
an asset is reachable with an url that is not dependent of its
bundle, so if the asset is present in multiple bundle it could
return different values.
Note: this only concern the debug mode
`default_search_product_id` with several ids simply can't work.
The only way to do it is using a domain in the action.
Anyway, this is unlikely that the user would like
to remove the domain (which is the main interest
of using a filter, the possibility to remove it), as
this will display all sales orders lines, whatever the products,
all mixed up. This is not super-useful.
opw-671022
when using a journal with 'Group Invoice Lines'
and issuing an invoice with foreign currency with more than 1 line
(of the same product, or no product),
the amount currency in the journal item
associated to the merged invoice lines was wrong.
It took into account the `amount_currency` of the first line only,
ignoring the `amount_currency` of the remaining merged lines.
opw-670972
Closes#10375
When creating the account translations using the account template translations
read it without the environment language.
Otherwise, when the translation is created, the content of `element.name` (the
source term to translate) might be in a different language and already
translated.
This was introduce during the migration at the new API where previous code did
not propagate the context (probably by accident).
Up to this revision, barcodes set in reports are generated
using the controller `/report/barcode`,
using a `img` HTML tag, e.g. (from `report_location_barcode`)
```
<img t-if="not o.loc_barcode"
t-att-src="'/report/barcode/?type=%s&value=%s&width=%s&height=%s'
% ('Code128', o.name, 600, 100)" style="width:300px;height:50px"/>
``
This `/report/barcode` route is set as `auth='user'`, meaning
the route can only be accessed by signed in users.
When wkhtmltopdf prints a report containing such a barcode,
it calls this `report/barcode` route, making sure to pass
the request session in the cookies, so wkhtmltopdf
uses the same session than the one of the user. This is
needed, as only users can access this `report/barcode/` route.
This session is passed in `report.py`, in the method
`_run_wkhtmltopdf`, thanks to the --cookie wkhtmltopdf
parameter.
Nevertheless, if a report is printed through the website
front-end, as public (without a signed in user), the request
session is not associated to a signed in user, and therefore
the route `/report/barcode` refuses the access / redirects
to the login, making it impossible to print a report
containing a barcode without being signed in. This even
if the report is printed as `sudo` through a controller
(as this is the session of the not signed in user which is passed,
not a session associated to `sudo).
Fixes#10621
opw-667797
Before this commit, the only way to translate a chart of account was to install
the language (if present in 'spoken_language' field on the chart of account
configuration) **before** the installation of the chart of account.
This commit loads the translations of the chart of account at the installation
of the language too.
To avoid recreating translations at each update of a language, skip if the
language is already installed.
This means than, to benefit from the fix, already deployed instances should
remove (after de-activating it) the language and reinstall it to translate
existing chart of account.
opw-670327
Closes#11091
When a specific SMTP server is set on a mail template, it is never used
when the mail is sent. There are two reasons:
- `mail_server_id` is a read-only field set by an onchange. However, a
read-only field is not sent to the server, so the information is lost.
- The information is stored in the context of the object `Mail`, but it
is never used. Moreover, when the method `message_post` is called, the
`Mail` object is not used to post the message, so the information is
lost again.
The fix includes two parts:
- the `mail_server_id` field is not read-only anymore. Actually, there
is no reason to make it read-only.
- the information is stored directly in the mail values and used at the
appropriate moment.
Fixes#6554 (from v9.0)
opw-669958
In Odoo 7.0 & 8.0, this was possible to translate
a field label, from `en_US` to `en_US`. It was
used as an easy way to change the fields label,
instead of creating an inherited view changing
the string attribute of the field everywhere it was needed.
This was no longer the case in 9.0,
following the revision 9593a29.
The translated terms for `en_US` have been
excluded, for performance reasons
as it was considered not possible to have
translated terms for the `en_US` language.
The fact is, this is very possible: Nothing
prevents to add a translated term
in `en_US` for a translate-able field,
as this is the case for the fields label,
as mentioned above. This field is then
used as the display value instead of the source
term when being in the `en_US` language.
Besides, the above revision was mainly to
give the possibility to sort a model records
on a translated field, using a join on the translations
table. It was then considered that the join could
be avoided, in the case where the user language was `en_US`,
for performance reasons, but, as this is possible
to give another value to the field value trough
the translations, it should actually be done, even
for the records sorting.
opw-670814
Test to bind save and discard buttons of an editable tree view are done
only once when initializing it.
But if the view is by default grouped at the beginning, it will be then
"not editable" but only removing the groupby will change this.
So this commit add a case so if the view is grouped when initialized,
the buttons are always bound.
closes#11198
opw-666794
It looks like reportlab doesn't handle well
UPC-A barcodes.
As UPC-A barcodes became EAN13 barcodes when
adding a `0` to the beginning of the barcode,
and the render is the same, we ask reportlab
a EAN13 barcode type when a UPC-A barcode is asked,
making sure to add the `0` automatically first.
From Wikipedia:
```
The EAN was developed as a superset of UPC,
adding an extra digit to the beginning of every UPC number.
[...]
the original rules for UPC are treated as a '0'
if read as EAN-13.
A UPC barcode XXXXXXXXXXXX therefore is the EAN-13 barcode 0XXXXXXXXXXXX.
It is possible to prefix a UPC barcode with a 0;
they become EAN-13 rather than UPC-A.
This does not change the check digit.
All point-of-sale systems can now understand both equally.
```
opw-670560
In the POS we use a touchmove event listener to stop undesired
rubberbanding (in Chrome.disable_rubberbanding()). Elements which should
be scrollable by touch should have the touch-scrollable class. The
receipt screen is obviously one of those, because otherwise you won't be
able to scroll down if you have a long receipt.
opw-670899
When a bank account is set within another currency
than the company currency
(the currency of the journal is set and is different
than the company currency),
the balance displayed was the amount within the company
currency, instead of the amount within the bank account
currency (despite the fact the currency displayed
was the one of the journal).
opw-670815
I'm not sure why the serial timeout is so aggressive, but I assume there
is a reason for it. During probing however, we shouldn't use such an
aggressive timeout because if we miss the device during initial startup
we'll never find it since we only probe devices once.
Convert the domain to display only the sale / purchase
taxes in the taxes list to a default filter doing the same thing,
but which give the possibility to remove the filter
and see taxes with the scope `None`.
opw-670737
Yannick Tivisse