Before 3959afc the `node` tested would be the selection containing node,
but since then it may have been a `<br/>` which has some damaging
effects: now entering double enter at the end of a list, quote or code
block doesn't end this block.
Testing the use case corrected by 3959afc, the said change seems to have
no effect so this commit reverts it.
opw-667618
Since 27a7cab52b, it may happen that the
stock.history view contains duplicated id (mutliple quants with
different lots for a single move).
Regroup serial numbers in order to keep a unique id per row.
opw-669349
Specifying the partner_id in the search does not give the same
result as the portal_sale module, which actually lists all the
SOs/Quotes/Invoices where you or anyone from your company is the
partner_id. To make the backend and frontend listings consistent,
let the ACL and ir_rules do their job (these are defined in the
portal_sale module).
`account.move.line.company_id` is a related
to `account_id.company_id`
`account.bank.statement.company_id` is a related
to `journal_id.company_id`
Any attempt to set the `company_id` value
when creating or writing records for these models
will result to the update of the value in
the related record (the update of `company_id` in the
`account.account and the `account.journal`), which
will result in the update of the `company_id` value in all
records in which this related record is used
(in all `account.move.line` where this `account_id` is used,
in all `account.bank.statement` where this `journal_id` is used).
In other words, the more a database had `account.move.line`
or `account.bank.statement` records, the more
it took time for the pos sessions to be closed.
To force a company for an `account.move.line`
(`account.bank.statement`), you must just
set the correct `account_id`(`journal_id`)
in the first place.
For instance, for the `account_id`, passing
`force_company` in the context ensure to choose
the `account.account` from the right company
property.
See
`local_context = dict(context or {}, force_company=company_id)`
which is set in `_confirm_orders` just before calling
`_create_account_move_line` which retrieve
the account from the
`property_account_receivable_id` property.
opw-671362
For a message to be considered as a private message,
the message must have:
- `no_auto_thread` set to `False`
in other words, it must not be attached to a thread
- no `model` or `res_id` must be set on the message
meaning the message is not attached to a specific
record thread.
See `_get_message_id` in `mail/models/mail_message.py`.
Before this revision, the mails sent from
`Discuss` > `Send mail` were not regarded
as private messages,
but as a kind of mass mailing messages,
with a `reply-to` wrongly set.
Any attempt to reply to these mails
failed with a delivery failure notification.
This was because the `message-id` of these messages
contained `reply-to`, and such message-ids are
treated as a special case in the messages routing
(basically, the match on the mail references is disabled
for these messages containing `reply-to` in
their message-id).
opw-669241
Commit bfa68b433 adds the field `date_planned_end` in the Gantt view.
However, the Gant view will perform search on this field, which is an
issue since it is a computed field without any `fct_search` defined.
opw-669042
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.
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