The field `purchase_count` is described as '# Purchases' (which is an
integer), so the user should expect the number of POs associated to the
product, not the quantity ordered as it is the case before this commit.
opw-697815
In ff56304f58 a solution was tried to have message posted from
backend livechat linkified for visitor in frontend. This was
forward-ported when it should not have been and introduced issues
including:
- `href="{link}"` would become `href="<a href="{link}">{link}</a>"`
- if html entities such as the ones for U+00A0, and entities <, >,
', " or ` were next to the link, the entity would be linkified
too (up to the ;)
This happen because utils.linkify function is to be used with text
content and not html which was the case in this instance.
opw-693457
opw-702410
This reverts commit 1c60a631df.
The fix was done to conciliate 83956d4 and ff56304f5 but ff56304f5 was
forward-ported erroneously and introduced other issues.
opw-702410
When the user clicks on "Run Reordering Rules", it might create
procurements. However, the cron "Run mrp scheduler" will also create
procurements and might already be running in the background. Therefore,
we need to make sure that both actions don't run concurrently.
Note that the same check is done for the wizard "Run Schedulers".
opw-695607
The field resource_type in mrp.workcenter tree view must be invisible because
this field was not available in the form view before f9f4bba
Adding resource_type in the form view had no business case.
opw:698183
The tree view of the stock locations displayes the field
`complete_name`, which is not translated. This is disturbing since
everywhere else, the `display_name` (translated) is used.
opw-693723
When the policy of the sale order is set to
`Deliver all products at once`,
the commitment date should be the maximum of the order lines lead time
rather than the minimum, as you will deliver all lines at the same time
It looks like the former behavior is applied since Odoo 7.0
d8d0b88467
It should therefore actually be applied in 7.0/8.0/9.0,
but we consider the risk too high for databases
that are used to the former behavior, and expect the old behavior.
We therefore apply this revision only in 10.0, to minimize the risks.
opw-702271
- When opening a mass mailing
- Editing it and making a change (e.g. add a block)
- Click on the breadcrumb
- Click "OK" on the warning popup telling your changes will be discarded
- Choose another mass mailing
A crash occured. This is basically the same case than in the revision
7bf80d22dd
but for Firefox, for which `window` is still there
`!window` returns False
but is `closed`
opw-702211
- In a livechat window, type a URL, then end by a space. For example,
type "https://odoo.com " (whithout quotes)
- Press enter
It is converted into "https://odoo.com ".
opw-702410
The depends for an issue inactivity_days expects a set create_date but
this may not be the case (when creating the record for example with the
field create_date in the form view).
opw-702532
Create a canned response containing the character "<". It is
automatically converted into "<".
The substitution field is systematically escaped, for security reason.
This causes the substitution observed. However, the canned responses are
only used in text-only messages. The escaping is therefore not
necessary, since the HTML is not interpreted.
opw-693970
Simplifies the left margin calculation logic with a pre-defined width.
In practice, more use cases should be taken into account, and that could
just make the logic overkill.
opw-697626
The company currency is EUR, and GBP rates are:
- 0.8414 at day 1
- 0.8389 at day 2
Then:
- Create a SO in GBP at day 1 and confirm
- Create an expense in GBP at day 2 and choose the analytic account of
the SO
- Validate the expense and post the journal entries
Problem:
- The amount of the expense is 93 GBP
- The amount of the sale order line is 93.28 GBP
opw-696375
When syncrhonizing an allday event while being in a negative timezone
e.g. Dec 22 in US/Eastner (-5:00)
The event was synchronized the day before
e.g. Dec 21
because `context_timestamp` of `start date-time-` was used,
and then the time was removed to have the date of the all day event
e.g. 2016-12-22 00:00:00 converted to 2016-12-21 19:00:00 and then the time
removed 2016-12-21.
Instead of using the `start_datetime`, we now use the start
date which stores only the date, without timezone information
(and this is what you would like in the case of an all day event).
opw-697202
In graph view, the y-axis always uses the standard float precision with
2 digits. This might not be enough if the precision was defined
differently for a given float type.
opw-697625
While choosing a start/stop datetime in a timezone hour
were the UTC value is within the next day,
e.g.
Start time Dec 22 20:00 in US/Eastner (UTC -5:00)
Therefore, start time Dec 23 01:00 in UTC
Checking the "all day" box made the start time set to
Dec 23 instead of what the user expected, Dec 22.
This is because the onchange simply took the UTC datetime
(Dec 23 01:00) from which it removed the time (Dec 23).
This revision make sure to remove the time from the
user timezoned datetime instead, so the day set
remain the same day than what was set in the datetime.
opw-702065
1;2802;0c
now() was bad as it excluded the orders of the latest session
midnight is not good either because
- midnight server != midnight user (timezone)
- some restaurant, bars start in the evening and finish after midgnight
With this default, with 4 sessions:
- POS A, start 2016-12-21 08:05:36
- POS B, start 2016-12-21 08:08:11
- POS A, start 2016-12-22 08:17:51
- POS B, start 2016-12-21 08:19:23
The default start date will be 2016-12-22 08:17:51 to include all orders of
both sessions.
When there are too many labels to display on the x-axis, they overlap
and it simply becomes unreadable. By slightly rotating them, this can be
avoided in most cases.
opw-697625
opw-697626
The dates were lost when in render_html as replaced by the one in the context
(None so fallback on today).
Avoid calling twice get_sale_details
Fixes#14789
Replaces and closes#14790
When MRP and Product Extended are installed:
- Define a manufactured product with valuation as 'Periodic (manual)'
- On the product form, click on "Compute from BOM"
Several issues:
- The field "Counter-Part Account" is mandatory
- Account moves are posted although the product valuation is 'Periodic
(manual)'
The problem is that the wizard is originally used for products with
valuation 'Perpetual (automated)', where this behavior makes sense. In
this use case, however, it's an issue.
Making the field not mandatory is not possible without an upgrade of the
module, so this will have to be fixed in master branch. Regarding the
creation of account moves, however, this commit solves it.
opw-697867
The revision
8f48baeda6
broke the ability to search pages in the dialog
allowing to add a menu to the website from the website
(From the website, Content > Edit menu)
as `request.website` was not defined in this case
opw-702020
This reverts commit 8416c2bcfa.
Temporary revert this commit, to have enterprise green again...
Need to replace 'full' args by key in context to don't break override
Need to rewrite account_bank_statement_import_csv from enterprise
In multi company, some followers of a document could be not
readable for a user who has the rights to modify this document.
If the user has the rights to write on a document, he is allowed
to read and modify the followers of this document.
opw:693536
Currently when someone is added as follow to a document default subtypes
are computed if no specific subtypes are given to the subscription. However
if internal subtypes are set as default those are added to all new
followers. It should take into account customers and shared users and avoid
adding them internal subtypes.
Customers and shared users are not notified of messages using an internal
subtype. So currently there is no information leak. However with this fix
we ensure internal subtypes are not followed by external people even if
no notification is created.
From #14704, backport of 03ac47b9
Event with interval > 1 was not correctly computed.
This patch doesn't fix existing event but only the new one created after this fix.
Event 1/1/2015 repeat every 3 months, 6 times
Before this commit : end recurrency = 1/1/2015 + 6 * 1 month
After this commit: end recurrency = 1/1/2015 + 6 * 1 month * 3 (interval)
This commit closes#14332
Nicolas Martinelli