Some more recent versions of etherpad can have newlines in the pad
content. Allowing newlines should not break anything that worked
before and allow more etherpad versions to be used.
closes#14877
opw-703173
In multi-company:
- Create 2 companies A and B
- Set the superuser on company B
- Set the website on company A
When a SO is generated from the eCommerce, it is defined on company B,
while it should be on company A.
opw-695253
With Company A (Warehouse Wa) and Company B (Warehouse Wb)
When making inventory adjustments for Warehouse Wb in company A,
the inventory lines displayed must only be the lines of the company A in
the Wb.
In this way, the user avoids confusion with the adjustments he is creating.
opw:697182
When making an inventory adjustments in multi company, the company field
must be set according to the location_id set. In this case, it avoids creating
by default different inventories for the same warehouse.
opw:697182
This is related to revision dfcc0c40b1
If the invoice line provided the amount currency, but
set to False, the amount_currency must be computed anyway
opw-702045
When selling in a foreign currency,
A double currency rate change, one in each way, was applied when creating the good cost
move line of the invoice, which leaded to some precision loss when the decimal accuracy was
set with a number of digits greater than the currencies digits rounding
e.g.
Product cost price: 52.56422
CAD to USD rate: 0.7383
The product cost price is always in the company currency
while `_anglo_saxon_sale_move_lines` always returned the price
in the currency of the invoice. A first conversion rate was applied
from the company currency to the invoice currency.
52.56422 * 0.7383 = 38.808163625999995, rounded to 38.81
Then, when validating the invoice, and creating the move line,
the price was then converted again, to the company currency,
as the debit/credit of a move line is always in the company currency:
38.81 / 0.7383 = 52.566707300555336, rounded to 52.57
The cost price of the product in the good cost move line was therefore
set to 52.57, insteaf of 52.56, because of this precision loss.
With this revision, we avoid to do the currency rate conversion
two times, in both ways, to avoid the precision loss.
opw-702045
If website_sale_delivery is installed, when we choose same invoice
address as shipping or another one, a new set of country/state are
displayed.
It is done since if we are using the invoicing address as shipping, the
address must be in the allowed shipping countries and states.
This was solved for some instances with 164b8ed01a but failed in other
instances.
With this fix the two state select tags have references to their own
options which allow us to have it alright for the several possibilities.
opw-693127
The product quantity in Orders Analysis must be expressed in the uom
of the product like in the Sales Analysis. In a POS order line, the uom
is always expressed in the uom of the product.
Closes#14599
opw:696927
The where_clause needed a "AND" to work.
The where_clause didn't contain allias for "account_move_line" so when
injecting a condition with "account_move_line" it crashed.
opw:702538
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 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
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
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
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
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
Fix datetime where the return of rrule is sometime a list,
sometime a set according to the datetime version.
list(set) == list(list) and works in both cases.
Similar fix: #9f09c62
DO NOT FORWARDPORT!!!
An issue occurs when a PO line is updated following a reordering rule or
a MTO rule.
As an example, a product is configured as follow:
- UoM: Units
- Purchase UoM: Box of 25 Units
To reproduce:
- Sell one unit of product, then run the scheduler
=> it creates a procurement for one unit, but since the product is
purchased by box of 25, it creates a PO with a box of 25.
- Sell one unit of product, then run the scheduler
=> it creates a procurement for one unit, find the existing PO line,
round in the purchase UoM (so it gives one box of 25), then add it to
the PO line.
The solution is to recomputed the necessary quantity at the very end of
the process. For a given PO line, list all procurements and adjust the
quantity.
This is a partial fix, since it doesn't take into account the potential
new price of the seller. However, that would require a major rewrite of
this part of the code, since it was originally written for v8 which
handles the PO line quantity recomputation sequentially instead of
batch.
opw-688916
The amount (=credit - debit) of the first line must be equal to the total included
to reconcile balanced entries.
Before the fix, it just worked with included taxes because the amount of
the first line was already equal to the total included.
But with excluded taxes, it didn't work because in this case the amount was equal
to the total excluded. Then it raised: "Cannot create unbalanced journal entry"
due to the second line which includes all the taxes.
opw:697129
The default value for the optional parameter `date` was evaluated at server
launch while it should have been at method execution.
The bug was not detected as it is always called with a date value in standard
modules.
Noticed at #11413
Daniel Dico