Sorting was done using a search on ids that where found in a custom SQL field,
only 1 record among aggregated records with same groupby value was used
when using search for ordering, resulting data ordered on
max(aggregated_data).field_value instead of sum(aggregated_data.field_value).
lp bug: https://launchpad.net/bugs/1060086 fixed
bzr revid: acl@openerp.com-20140217172926-ka2fw8t2l3cqi7h3
self.phantom_js(<page_to_load>, <code_to_run>, <global_object_to_wait>, **options)
example:
self.phantom_js("/", "openerp.module.mytest()", "openerp.module.mytest");
console.log('ok') or console.log('error') should be used to signal success or
failure. Other console.log's will be passed to the test logger.
bzr revid: al@openerp.com-20140210004517-jc2cobc31qshxchm
main problem, view inheritance model field would use model from the
root view (after following inherit_id links) rather than the base view
(the requested one) -> with divergent models, it was possible for the
requested view itself to never be returned.
bzr revid: xmo@openerp.com-20131212134422-uxg6h21w1jhth9ow
weird tests (using broken views, but not just broken in the way the
test expects) were really testing for error on using a field which
does not exist, predicated on full rendering of the view during
validation.
This has been removed from the website branch as it's unfeasible and
nonsensical for model-less views (e.g. qweb), and thus the test blew
up with a completely different error (missing @string) or, once the
test was fixed, wouldn't blow up at all.
bzr revid: xmo@openerp.com-20131211162412-t31bxkpy2yzdnf0q
expectation of view validation errors when creating view referencing
non-existent fields or models, but in website branch models and views
have become independents, these are not context-free errors anymore.
Also fix shit code.
bzr revid: xmo@openerp.com-20131007093328-gjrktqbsoe48ikol
When a new inheriting view is imported during a module
installation, it is validated thanks to the _constraints
on the ir.ui.view model. However the validation uses
a rather convoluted system for validating the whole
view tree at once (root view + all inherited changes)
while only taking into account the views that belong
to modules that are currently loaded.
This complicated system is necessary to be able to
operate on-the-fly at any point during the registry
loading/initialization.
Now because _constraints are checked during create()
this particular validation happens *before* the
external ID (ir.model.data entry) of that new view
can be created (it obviously needs to wait until
the view record is inserted). As a consequence the
view validation cannot determine the module to
which that new view belongs, and was erroneously
ignoring it.
Changing the view filtering to also include views
that have triggered this check.
Manually created views are not check during registry
update.
bzr revid: chs@openerp.com-20130912141018-qmcyase8zqov9d01
Main modifications:
- removed dummy, email (now coming with email_template), loop, sms
- cleaned code, made it easy to override
- improved view to ease the definition of new server actions
- changed/updated fields
- added tests
- added changelog
bzr revid: tde@openerp.com-20130715152424-deucc2rlg2ax3tyc
A view for a given model can inherit from a root view specified for
another model. When applying the modifying views to the root view,
only the views with the same model as the child view must be
considered. This patch restore that behavior.
bzr revid: vmt@openerp.com-20130701145334-ojp1plqjveym7cj7
* Formally make model not required
* Remove idiotic default values on type and arch
* Make type not required (it's a function field!)
bzr revid: xmo@openerp.com-20130426145113-cf0t0xx24lk9mtgs
Now that res.partner.child_ids has an extra domain
attribute the exact number of parameters of queries
using `child_ids` in the WHERE clause is different.
bzr revid: odo@openerp.com-20130419173159-ef1onm3823hsi77n
The name `commercial_partner_id` better reflects its
purpose and the fact that it is a FK to a partner.
An extra indirection through a lambda function was
also added to the definition of the function field
to make it possible to override it in other modules
(otherwise the function is passed by copy directly
and cannot be inherited later)
bzr revid: odo@openerp.com-20130418144533-owupfwn6h83q432x
- res.partner must prevent creating loops in partner
hierarchies, and this can be done easily with an
extra _constraint using the ORM's builtin _check_recursion
- _check_recursion's implementation incorrectly
assumed that the provided 'ids' were unrelated
(not part of a common hierarchy).
- add tests for _check_recursion via extra
tests on res.partner structure
(explains why both patches are in the same
commit)
bzr revid: odo@openerp.com-20130415171732-aj3j2e2mycvzf4kp
It is valid to use the parent address but still set a different
type of address - the name, email, phone, etc. could be different.
bzr revid: odo@openerp.com-20130410123229-9l60sbcks3tpmy7x
Using the commercial entity is not a very good default choice
in many cases. If a new contact is created on-the-fly for a
new document (e.g. sales order), his/her company may be an
empty shell and/or a large corporation that should not be
directly used for e.g. billing/invoicing purposed.
Once a contact/company is set to "invoicing" or "delivery"
we use it, but in other cases we stick to the provided
partner/contact as a saner default.
This should not change anything for cases where advanced
contact management is used and proper address types are
set.
bzr revid: odo@openerp.com-20130410121536-vm93o6vxhi3b8feu
* Commercial fields (bug 1160365)
Fix autosync of accounting/invoicing-related fields on contacts,
just as if they were actually modeled as fields.related to the
parent commercial entity.
This starts with the addition of the new functional field
`commercial_id`, to locate the commercial entity for any partner.
The commercial entity is defined as the first ancestor (starting
at the partner itself) that is either marked `is_company` or has
no parent. [This is Part A of the solution on bug 1160365].
Then, whenever a partner is created or modified:
- if it is a commercial entity, the commercial fields are synced
downstream to all its descendants, stopping at company boundaries.
- if is is not a commercial entity, the commercial fields are
synced from its parent commercial entity.
The list of fields to sync is determined by calling the new
res.partner method `_commercial_fields()` which can be easily
extended by any module that adds commercial fields on res.partner.
A utility method `open_commercial_entity()` was added to
res.partner to make it easy to include a button for editing the
parent commercial entity, to be displayed instead of now-hidden
commercial fields.
[This is part B of the solution on bug 1160365]
The res.partner.address_get() method (used to find child partners
of certain types, e.g. "invoice") was udpated to take the new
"commercial entity" notion into account: it will now look for
matches in children but also parents and siblings that are part
of the same "commercial entity". The default partner `type` is
now "contact" to reflect the new model ; "default" is
inappropriate because it is a wildcard and would stop the type
lookup early.
[This composes parts C and D of the solution on bug 1160365]
Note: This fix comes with a matching addons fix to implement
module-specific extensions of part B, as well as part E of the
solution.
* Address fields (bug 1160425)
Corrected autosync of address fields is also included in the
same branch, because those two mechanisms are closely related
and share some parts of the implementation.
The `use_parent_address` field now defaults to False (except
in the mini-kanban view of contacts on a partner form), and
the autosync of address fields has been modified to only work
downstream and never update a parent company if a child contact
is modified. Instead, the address fields are now displayed
readonly on contacts that use the parent address, with a button
to edit the parent address (new method open_parent(), similar
to open_commercial_entity() but opening the direct parent).
To make the initial creation of a contact + company pair,
a special case was added: when a new contact is created for
a company that has no other contact and no address, the
address of the contact is assumed to be that of the company
so it is moved to the company, then the `use_parent_address`
flag is enabled on the contact, and the `is_company` flag on
the company. This covers a use case where contact and
company are created on-the-fly when creating a new document.
Many logical flaws in the autosync of address fields have been
corrected and are now covered by unit tests.
* Misc related fixes
- checking `is_company` does not reset the parent_id field
anymore, to allow for multi-level structures. The field is
still hidden automatically because having an empty "Company"
field on the form view of a company is quite suprising), but
this UI behavior is easily customized;
- the `email`, `phone`, `fax`, `mobile`, `lang`, etc. that
were sometimes synced when changing parent company are now
properly left alone;
- the `use_parent_address` field is now always visible next
to the parent_id field when a parent is set
lp bug: https://launchpad.net/bugs/1160425 fixed
lp bug: https://launchpad.net/bugs/1160365 fixed
bzr revid: odo@openerp.com-20130408013742-tm8w0w0nmunanokk
That function was kept because its `intersperse` reimplementation
behaves a bit differently but it was a long time ago and no bug
report appeared. So the new function is good enough.
bzr revid: vmt@openerp.com-20130212111244-aayco60ps923fn55
ir.ui.menu was recently changed to use _parent_store,
which precludes using ondelete=set null for the parent_id
column. We nevertheless need to be certain that menus
can always be deleted but *never* cascade-deleted,
due the possible presence of user-created menus.
Overriding menu.unlink() is therefore necessary,
and care must be taken to bypass the default menu
visibility (using the `ir.ui.menu.full_list` context
flag while doing so)
bzr revid: odo@openerp.com-20121213145821-u2ipdvffu00rsgdg
This is a partial implementation with no support for
restricting read/write access via RPC. This first
part only covers the removal of the restricted fields
from the client-side view, i.e. in the results of
fields_view_get() and fields_get().
The second part will come later and will cover the
real low-level access control.
bzr revid: odo@openerp.com-20120518143625-ps9db62vzrc2pylh
- moved a few YAML tests to unittest2 for demonstration purpose
- changed --test-disable to --test-enable (and swapped its meaning)
bzr revid: vmt@openerp.com-20120301134608-szuktuj8imdhmn0r
Anael Closson
Antony Lesuisse
Xavier Morel
Christophe Simonis
Martin Trigaux
Olivier Dony
Fabien Meghazi
Thibault Delavallée
Christophe Matthieu
Denis Ledoux
Vo Minh Thu
Raphael Collet
Antonin Bourguignon
Cecile Tonglet
Quentin (OpenERP)