This makes report registration more uniform, and report rendering be possible
through the ORM (and thus the model service, instead of the report service).
To register a report, always use the database, i.e. a <report> tag within an
XML file. The custom parser, if any, will be specified in the database.
Previously specify a custom parser, the report was declared in Python.
Each model exposes a print_report() method, which will take the report name (as
many report can be defined on a single model) in argument.
bzr revid: vmt@openerp.com-20130327161129-6e7jz7l3lx7z1t18
Either use openerp.modules.registry.RegistryManager when the full
new() signature is needed, or use openerp.registry().
Replaced also some pool.get() with pool[] because KeyErrors
are better than AttributeErrors on None.
bzr revid: vmt@openerp.com-20130327111014-2i0hlvpy5y5ku7hm
When --test-enable is used, it is expected that test output is visible,
thus using log-level INFO is natural.
On the down side you lose the nice blue hint that tests did actually
run when --log-level test was given.
bzr revid: vmt@openerp.com-20130326155844-83e2tcqokvblr0ln
auto=True reports are looked up in the database for each rendering, so they do
no have to be in the report registry any longer.
auto=False reports will register themselves but at this point
they can be updated to use the new `parser` XML attribute.
bzr revid: vmt@openerp.com-20130322153955-s6nyux2pyez6c01w
This is needed so the uninstall process can simply go through
the installed data by using the ir_model_data entries in reverse
order (when ordered by IDs), so that parents are deleted before
children.
bzr revid: vmt@openerp.com-20130321133202-igea1vxlszfpk6pe
- the re-raising of exceptions ignored the "legal" exceptions
(the one used to early abort RPC calls and generate pop-ups)
- re-raising the exception was attempting to re-use the original
exception type but it does not always take only one argument
so it was breaking.
lp bug: https://launchpad.net/bugs/1146256 fixed
bzr revid: vmt@openerp.com-20130320132238-qzo3jptww59ndlch
Example of use : <field name="user_id" string="Project Manager" context="{'default_groups_ref': ['base.group_user', 'project.group_project_manager']}"/> will add Employee (base.group_user) and Project Manager (project.group_project_manager) groups, as well as implied groups.
res_users:
- [add] added support of key in context of default_get. It contains a list of xml_ids of user groups; those groups, if found, are added to the newly created user,
- [ref] refactored simplified (quick create) view that is now more like a contact card, with login and email required because of the login email that will be send to the user
bzr revid: tde@openerp.com-20130318120905-1w9xpoyppnj62wlj
object has no __getattr__, in the usual case super(BaseModel,
self).__getattr__ will blow up with an AttributeError (but the wrong
one).
On the other hand, if a BaseModel descendant class is used in MI
alongside a non-BM descendant (e.g. res_partner inheriting from Model
and format_address) and the non-BM descendant also implements
__getattr__, we want to forward the failed attr search to the other
__getattr__ implementation.
So check if super() has a __getattr__, call it if it does otherwise
AttributeError right there.
bzr revid: xmo@openerp.com-20130315115302-z7jla334gb9a5e43
Vo Minh Thu
Xavier Morel
Fabien Pinckaers
Launchpad Translations on behalf of openerp
Thibault Delavallée
Olivier Dony