Python 3's hash randomisation means columns can be iterated — and thus
initialised — in any order (within a given model/override anyway),
which means there can be an implicit dependency on column
initialisation order e.g. (res.company).currency_id has a default
which fetches the currency_id of the company_id of the administrator,
and res.company has a _order=sequence,name, if the currency_id field
is created before the sequence the SELECT query will blow up as the
sequence column will not exist yet.
Attempt to always manipulate (iterate & initialize) fields based on
their order of definition using a global sequence number.
* Have the cleaned up style attributes be dumped in the same order
they were originally so that we can easily validate against text
content.
* While lxml's attributes are stored in an ordereddict, namespaces are
not and thus when comparing text serialisation of namespaced
documents the ordering of namespaces can differ between runs.
Fix by comparing the LXML trees directly.
Since we handle rouding error with the last line as
the difference of total and the other (already computed),
the order of lines to process is important.
Calling 'sorted()' on the lines to process allow
to always have the same last one.
Hope this will fix the random rounding bug, and make
the multi currency test always green !
When logging timesheet, no employee is set by
default on the UI. The employee is deduced
from the user_id in the create, but we want to
see it on the list view even if it is not saved
yet.
It's unclear whether that's a recent change or a long-standing issue,
however currently if geocode is called with an empty address string it
will reply with a 400 Bad Request, which gets raised as an exception and
forwarded to the user. That is not a great experience.
Shortcut the entire thing and just return None (= geolocation failed /
no geolocation) on trying to geolocate an empty address.
OPW-746686
Odoo modals are supposed to be instantiated thanks to the Dialog JS
class. This allows to not duplicate modal structures and to properly
handle multi modals (which bootstrap is not supposed to).
Problem since commit 7dcb8fea64:
The support for inline modals has been broken without providing a
solution for all cases. Indeed, some modals are placed directly inside
form view xml. See an example here:
https://github.com/odoo/odoo/blob/dd0533897e397dfd78ad456fea42a5a12db51246/addons/website_twitter/views/website_twitter_settings_views.xml#L24
While waiting for a new way to instantiate these inline view modals,
this commit restores their deprecated support.
Let's create in google calendar a reccurent event with all day
set and a end date.
When synchronising google calendar with Odoo(by clicking on button
"Sync with Google"). It raised on error because the start date had
a time zone but not the end date(the UNTIL in the rrule).
Fine tuning of 20ed57f
opw:746549
stock_landed_costs: on nightly, the localization installed may not have stock properties accounts defined. If it's not, we create them on the fly with a random account
sale, sale_expense: fix broken tests due to mismatch currency:
On 10.0-nightly, the currency of the company is not the same that the product.list0
that leads to assertion errors.
The karma link is an hardcoded page from odoo.com. The information might
therefore not be correct depending on the configuration of the user.
We change to redirect to the FAQ, which also contains Karma information.
opw-746383
When the field use_create_lots is set to False in a picking type, it is not possible
to create lot for a pack operation linked to this picking type.
opw:744862
Add a constrains on user_id field to avoid to recompute manually the team_id.
Eg: action_foward didn't call the onchange manually, so the saleteam not updated.
The website is not ready. It is still too young to understand what the
beautiful `_rpc` function can bring to its life. Someday it will, but
for now, it can at least rely on the `rpc.query` function or to the
'Ace' menu which now understands the beauty of `_rpc`.
---
-> Replace website `_rpc` calls with deprecated `rpc.query` as the
website is not structured enough yet to handle 'trigger_up' events.
-> As the `_rpc` calls cannot be replaced for the ace editor because it
is also used and tested in the backend, promote the 'Ace' menu (which
instantiate the ace editor) to be a `ServiceProvider` so that the
`_rpc` method works in this particular case.
If `d.message` is an empty string, `!!d.message` is false and the
crashmanager will try to display `d.error.data.message`… which does
not exist as it's a warning with an empty message not an upstream error.
That causes the crashmanager itself to crash, and even the warning
name/title to be lost.
Commits 9365482df0 and 8fc81b871d attempted to prevent the creation
of two moves with the same name during reconciliation. It works in most
cases, but it is still possible to reconcile the same statement line
with more than one line.
We add an extra check to make sure duplicate never happen.
opw-742018
This simple return allows submodules to be able to know when a dialog is shown and modify something in it.
Note from GED: I am aware that this is a IMP in a stable version, and I really don't like that... But it looks like it really helps many people, as shown by the PR, and the risk induced by this commit is definitely extremely low, so I will make an exception.
(PR: #15579)
The ModelFieldSelector keeps an internal cache for the fields_get.
This cache needs to be cleared in the tests environment because
a model with the same name may be defined several times accross the
tests modules, but they may contain different fields.
This could also be a problem with studio: when a field is created,
the ModelFieldSelector cache must be cleared as well (in addition
to the data_manager one).
We thus introduce a new 'clear_cache' event on core.bus. When
triggered, the ModelFieldSelector and the data_manager clear their
respective cache.
We use this event in the test environment to ensure that the cache
is cleared at the end of each test using a mockEnvironment. This
rev. also fixes an infinite loop in the override of destroy() in
the mockEnvironment, which occured when both session and config
were specified in the params.
Commit 8911be11d1 moved code from website_portal_sale to
a new sale_payment module, in order to move code down and ease its use in
variou addons. However a called method was forgotten in the process leading
to some issues when using sale_payment. This commit fixes that.
When updating a carrier that is not "fixed" or "base_on_rule", this
method was creating unnecessary delivery.price.rule at each write.
This patch fixes this issue.
Closes PR #17443
In the journal items,
when performing a search
"Journal" "Doesn't contain" "Something"
Both its name AND its code must not contain "Something".
Therefore, with negative operator, the domain must
not be built with a OR connector but with an AND.
Same thing goes for "is equal" and "is not equal".
opw-726029
When the root node of the arch has attribute 'create' set to '0',
the generated DOM element must have classname 'o_cannot_create'.
This is used to correctly display the nocontent helper (when there
is no record).
Before this rev., the helper indicated that the user can click on
'Create' to create a new record, even if the create action was
disabled. This was for example the case in Point of Sale > Orders.
The problem occurred in form views with a many2one field, when the
user reproduced the following steps:
- type some text in the many2one
- click on 'Create ...' in the many2one dropdown to quick create
(name_create RPC) the record
- before the name_create returns, click on 'Save'.
When this happened, the record was saved before the many2one was
updated with its new value. So the record was incorrectly saved,
and the view was again dirty as soon as the name_create returned,
even if it was in 'readonly'. So after saving, a 'Changes will be
discarded' dialog opened when the user tried to leave the form.
We fix this issue by making the controller wait for the name_create
to return, and for the many2one to update its value, before saving.
This issue could also occur in list views.
Attempting to read the field `website_price` directly
with the XMLRPC API failed because, in such a case,
the request is unbound, and attempting to read
anything from it (`request.session` whatever)
resulted to the raise of an exception.
e.g.
This prevented to perform a `search_read`
with all fields on the `product.product` model
Closes#14939
opw-745733
Let's create in google calendar a reccurent event with all day
set and a end date.
When synchronising google calendar with Odoo(by clicking on button
"Sync with Google"). It raised on error because the start date had
a time zone but not the end date(the UNTIL in the rrule).
Fine tuning of 20ed57f874
opw:746549
As a consequence of rev. 76cd8d2558,
imported modules were unable to access their resource files during
import.
Rather than further modifying the file_open API to whitelist paths
(the whole thing needs a redesign in master), we temporarily
whitelist the temporary directory by including it in the global
addons_paths, making sure to undo it afterwards.
This gives all lower level function access the resource files via
file_open, without having to pass around whitelisted paths
through many different calls.
- Use the demo resource calendar (40h/week)
- Create a project forecast for the Administrator
- Set the 'Start date' and 'End date' to 2017-07-07
- Plan 8 hours
The % of time should be 100 %, but it's not always the case.
The core of the issue comes from `get_working_hours`.
Case 1:
Call with start_dt = end_dt = 2017-07-07 00:00:00
`get_working_hours_of_date` is called twice with the following start/end
dt:
- 2017-06-07 00:00:00, 2017-06-07 00:00:00 => 0 hours
- 2017-06-08 00:00:00, 2017-06-08 23:59:59.999999 => 8 hours
This is obviously not correct, we don't care about what happens on
2017-06-08. The number of hours is correct in total, but it comes from
the wrong day.
Case 2:
Call with start_dt = 2017-07-07 00:00:00 and end_dt = 2017-07-07 23:59:59
`get_working_hours_of_date` is called twice with the following start/end
dt:
- 2017-06-07 00:00:00, 2017-06-07 23:59:59.999999 => 8 hours
- 2017-06-08 00:00:00, 2017-06-08 23:59:59.999999 => 8 hours
This is obviously not correct either...
We change how the `until` parameter is computed. This way, the correct
call is the second call (Case 2), and `get_working_hours_of_date` is
calld once with the following start/end dt:
- 2017-06-07 00:00:00, 2017-06-07 23:59:59.999999 => 8 hours
opw-745253
There were two main problems with the datepicker since the lib was
updated:
- it appeared broken in the search view "Filters" menu
- it did not overflow the parent which scrolls
Indeed, before the update, the datepicker was placed in the <body/>.
Now this is a lib option. Unfortunately, the option is broken (I don't
know why they broke it since it worked before the lib update...). As the
lib does not expose its internal functions, the only found workaround was
to patch the lib code itself.
opw-745311
opw-745625
Xavier Morel