Commit ec949ad5 links the extra move to the Sale Order through the
procurement. To be consistent, we also have to link the extra move to
the Purchase Order.
The original issue is that any extra move is not taken into account in
the received quantity calculated.
opw-665398
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.
`event_sale` adds an onchange on the `product_id` of the
sale order lines, which returns values for the fields
`event_type_id` & `event_ok`, which are used for an attrs
domain on the fields `event_id` & `event_ticket_id` in
the sale order line form (dialog). `event_type_id`
& `event_ok` are related to `product.product` fields,
in addition.
Changing the partner of the sale order triggers
the onchange on the lines, which triggers
the onchange of the `product_id`.
As these two fields `event_type_id` & `event_ok` were
not in the sale order lines tree view, as readonly,
they were passed to the write operation when
saving the SO, therefore writing on the product (the
same value than before, in addition).
Indeed, if an onchange returns values for fields
that are reandonly in the view, these are ignored
when saving/writing. However, if the onchange
returns values for fields that are not in the view,
these values are nevertheless passed to the write operation,
even if there was actually no change.
This behavior should probably change, that if an onchange
returns values for fields that are not in the view, these
are ignored, either when saving the record, either when
returning the result of the onchange.
Either way, these are risky changes, that we prefer to avoid
in a stable release such as 9.0. As a workaround,
we therefore add these fields in the sale order line tree view,
as readonly, so they are properly ignored when saving
the record.
This is important to avoid this write on `product.product`, as
users can have the write access to the `sale.order` without
having access to the `product.product`
(e.g. `Sales > See own leads` group)
opw-660716
When you are in form view and came from calendar, a screen refresh
throwed an error from fullcalendar lib. Also when going back to the
calendar view, it would not be loaded.
It is due to fullcalendar not being rendered if it is not visible, and
other part of the Odoo code are dependent on it having been rendered.
This commit hide the calendar after having been rendered.
closes#10253
opw-659314
The links present in forum messages are parsed to integrate "nofollow"
attribuate in it.
In case the content of the link contains some special char (e.g. <a>foo)bar</a>)
the regex fails as it interprates the content as an invalid expression.
The ir.module.module model has a 'url' field (so there is a 'url' field
in db) but the 'url' values in the __openerp__.py files were not used.
Now, the 'url' field is filled with the manifest 'url' value with a
fallback to the manifest 'live_test_url' value.
Despite the fact there is a `company_id` field
on `account.payment.term`, there is no multi-company
record rule on this model. The payment terms
are therefore shared by default accross companies,
even if the company is filled on the payment term.
In addition:
- The `company_id` field on `account.payment.term` is required
- The field is invisible on the payment term form
- The default value is the user company
Adding the record rule would imply to change:
- The fact the `company_id` field is required,
as you probably would like to share some payment
terms accross companies, by leaving empty this field
on the payment term form
- The field should be visible in the form for users
having the multi-company group, so the admins can
create payment terms for other companies than the one
they are currently in.
This cannot be done in a stable release, such as 9.0.
This is for master.
In the mean time, we keep the behavior as it was in 8.0:
We consider that the payment terms are shared among companies,
and the `company_id` field is simply ignored.
This implies that choosing a payment term from another company
in an invoice must not lead to multi-company access rights issues,
as it was the case before this revision: If a user other than
the admin chose a payment term from another company, the on change
on the payment term leaded to access rights issues, as it needed
the read access on the company of the payment term, to get
the currency decimal places.
From this revision, the currency is took from the invoice directly,
through the context, and if not passed in the context, the company
of the user is used instead of the company of the paymen term.
It makes more sense anyway to take the currency from the invoice
instead of the currency of the payment term company to retrieve
the currency decimal places.
opw-659818
project_time_mode_id is the timesheet UoM. However, all timesheet
widgets assume that project_time_mode_id is hours, therefore it is not
supposed to be changed.
Commit fde3a529 unlinks the product and the timesheet. Although we don't
want to use the cost of the product in the timesheet, we still want to
link the timesheet to the product for reporting.
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
Before this, selecting the pricelist from the order form view was
throwing the traceback as there is no 'type' fields exist in
product.pricelist anymore. It was removed in
e4dc50bf58.
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
Opening a view (kanban or list) in a dialog thanks to a target=new
action did not work anymore (only in community).
The cause was the 'search_view' action flag which was set to false
in case of a popup (preventing the view to search the records and so
to display them). This commit sets this flag to true if the popup
has to display a list/kanban view.
Backport of aab enterprise work.
The chatter composer extends the basic composer to, among other things, add
a button to open the full composer next to the button to add an attachment.
In a recent commit, the basic composer template has been slightly changed and
the buttons have been extracted in a sub-template, which seems to break the
template inheritance (the xpath refers to one of those buttons).
This solution simply removes the sub-template and duplicates the code.
When uploading a text document, the indexing was done based on a wrong mimetype
('application/octet-stream'). This was due to the result of mimetype.guess_type
being erased by the following guess_mimetype call.
opw 659328
This commit introduces native notifications (if available) to the
discuss application.
Those notifications will only appear if the user grants the permission
for that. A notification bar will appear in the discuss application if
necessary to prompt the user.
Also, it always is the master bus that will be the one sending the
notification.
For this change, it was necessary to be able to detect if the user has
the focus on some other odoo tabs. For this reason, the bus was
extended.
Since monetary values are stored as float, use the method intented for float
comparison using the maximum number of digits a currency can use.
Until V9, the number of digits used was fetched from table decimal.precision,
but as of V9, the accounting module stopped using it in favour of the digits
number defined on currencies.
When rendering QWeb reports, the user is being browsed without the
context, which means that any translatable field being accessed
through it will be in English.
Nicolas Martinelli