This commit improves performances of the scheduler when the database
is big (lots of products with lots of fields). This avoids prefetching
all the fields for every 1000 products while we only use 2 of them.
Format_tz allow to format a date, but if the format was '%B', it was always January regardless lang in context
Now, it possible to use babel, to get the date in the customer language.
So:
format_tz(object.date_order, format='short', context={'use_babel':1, 'lang': 'fr_BE'})
will return '5/01/16 22:20'
format_tz(object.date_order, format='short', context={'use_babel':1, 'lang': 'en_US'})
will return '1/5/16, 10:20 PM'
format_tz(object.date_order, context={'use_babel':1, 'lang': 'en_US})
will return 'Jan 5, 2016, 10:20:31 PM'
format_tz(object.date_order, context={'use_babel':1, 'lang': 'fr_BE'})
will return '5 janv. 2016 22:20:31'
When configuring the payment acquirer with the confirmation
`at_pay_now`, meaning the sale order has to be
confirmed when clicking on the "Pay now" button, instead
of waiting for the payment confirmation,
the confirmation email wasn't not sent.
opw-665697
This revision is related to 6efc371291
The return URL parameter key has changed: The capital letters
are not the same than before.
Besides, send a dict in the `ADD_RETURNDATA` doesn't seem
to be supported by Buckaroo. We therefore no
longer uses a dict but a string to avoid problems.
opw-665697
If anybody adds a new modal in the `then()` part of the promise, without
this code, all `.modal-backdrop` elements will be deleted, and further
dialogs will not be modal; with this, only the current modal's backdrop
will be deleted.
Commit 64e1c28e3 introduced timezoning in resource_calendar in resource already.
This broke the stock_calendar module, but as such, the timezoning in the module
is not necessary anymore. All dates calculated from the times in the calendar
are calculated back to UTC and the results are without timezone in UTC. That way,
timezones are also not needed for calculating the leaves.
The keep_query() function has to **keep** all or selected query parameters
or add new ones but not change them by merging those with the same name.
That unnecessary parameter merge breaks the *Change language* feature in the
website_sale module when *Website -> Customize -> Product Attribute's filters*
is enabled and there's 2 or more select type attributes created and at least
one of them is selected.
Merging params was added in:
* 8.0: commit 7759af7c4c
* 9.0: commit daf8bdf688
The quantity is not correctly computed, and therefore the weight is
wrong.
The fix uses the appropriate _compute_qty method to convert the
quantity.
Closes#10204
opw-660801
The system showed different Description for product in invoice when you generate invoices based on delivery
orders compared with based on the sales order lines. But the invoice is in the two cases attached with the SO.
Then the description of the product must be the description linked to the SO line.
opw:660723
When cancelling a `stock.move` with as invoice status
`To be invoiced`, the invoice status was left that way.
Therefore, the `stock.picking` to which this `stock.move`
belonged remained in the "Deliveries to invoice" list,
even if all other moves of the picking were invoiced,
and this one cancelled.
Setting the invoice status to "Not applicable" on
the `stock.move` cancellation solves this issue
as the `stock.picking` will no longer be considered
as to be invoiced if all its moves are
invoiced or `not applicable`
opw-660729
When creating a tax movement, the sign of the amount tax must be
the tax_sign in the normal case or ref_tax_sign in the refund case.
Inspired from the function create defined in model "account.move.line"
opw:658378
When a purchase order is created through a procurement order,
the purchase order pricelist is taken from
the partner `property_product_pricelist_purchase`,
which is a property, which therefore can be different
according to the company. This is therefore
important to force the company to the procurement company
when browsing the partner, to get the correct pricelist,
from the right company. Otherwise, it take the pricelist
from the `SUPERUSER` company (when running the schedulers/cron),
which can be different than the procurement company.
The same as to be applied when browsing the product,
as the `standard_price` field (Cost Price) is a property
as well, and can be different according to the company,
in order to get the correct price unit on the purchase
order line, from the correct company.
Fixes#5329Closes#5330
In "Search Journal Items", for the the field 'journal_id', the name
of the current searched journal was written in the context with the key
'journal_id'. Then in the function "view_header_get", the 'journal_id'
was expected to be an id. This is why the key has been replaced in the
view as 'journal_name'.
opw:660591
Fixing several issues in the computation of the sha1 signature:
- Removing BRQ_SIGNATURE parameter was only tested in uppercase.
The parameters returned by Buckaroo are case insensitive and we can not ensure
it will be uppercase. Check all keys instead.
- Sorting should be done case insensitive (e.g. 'AA' before 'bb') but the case
must be preserved in the final string to sign.
- The values returned should be URL decoded before being signed.
The value "J.+de+Tester" should be decoded to "J. de Tester"
- The final string may contain unicode and fail to be used by sha1() method.
Based on Buckaroo Payment Engine 3.0
http://pronamic.nl/wp-content/uploads/2013/04/BPE-3.0-Gateway-HTML.1.02.pdf
Happy New Year Odoo! 🎉🎆📯
In current safari (tested on 8 and 9) it seems things like:
content: "\f000";
are transformed when getting them javascriptally to:
content: \f000;
which seems to make no sense with CSS specifications but tests verified
this happened.
This broke sending mass mailing in some instance, which is solved by
this commit.
opw-665496
Commit 704b3cec9f introduced a bug which led to be on page -1 on
empty o2m. So when adding a record to such a o2m, the reload content
function chose to stay on page -1 therefore not displaying the new
added record.
Quoting Buckaroo Payment Engine 3.0 Implementation Manual:
Note: parameter names are not case sensitive (both in the request and in the
response). Parameter values are case sensitive.
Using data.get(BRQ_PAYMENT') is unreliable and may break in the future.
Update test to use different case.
opw 665439
Commit b3f3c67eea corrected the o2m view manager template which was
useless in its previous version because of a dead selector. It appeared
that some fonctionnality relied on the fact that this was dead code.
This commit removes the dead code.
Thanks LeartS (see #5711).
when going through different form view records
For example, when being on page 4 of a o2m then switching to next form
view record, if this new record did not have 4 pages for this o2m, the
o2m was shown empty (and if there was no page, the o2m became unusable)
One2many fields bring in the entire viewmanager widget.
When there is only one view though (e.g. only kanban view for contact
tab of partners), we want to hide the viewmanager header because we
don't need it (it's where the view switcher would go).
Odoo had the widget logic to do that, but it was wrongly implemented,
resulting in a always present oe_view_manager_header div with all
its elements (although empty).
The wrong javascript operation should have triggered a client error
when loading the view, but for pure chance it didn't because the
t-jquery selector was wrong too so the javascript was never evaluated.
These menus are supposed to display the message
to: me / to do that matches the `To Read` filter.
The filter was correctly displayed in the search
view, but the records displayed were not the
result of the search, because the call to
`message_read`, in `message_fetch` was done
too early, with the wrong domain.
This is because `searchview.has_defaults`
& `searchview.ready` have disapeared in saas-6,
with the refactoring of the search view.
opw-659137
When uploading an image in the client list in the POS with Firefox an
error was thrown complaining about event not being defined.
jov note: the reason it worked in other browsers like IE and Chrome is
that in those browsers `event` resolves to `window.event`. In Firefox
this doesn't happen which is why JQuery provides us with the event in
the callback function.
closes#10078
If one set a carrier_tracking_ref on a stock.picking,
but the carrier_id is not set, the button Tracking
will appear but crash as this button calls a method on
the carrier.
opw-660659
Ludovic Laffineur lla