It has no sens to map a tax by a tax included in the price because
when a tax is included in the price, the price must be computed
according to this tax.
If the whole view relates to a specific group,
apply the group on the view itself instead of
each view part (each fields, each page, each div,...),
so the view is loaded / added to the base view
only if the user is in the right group.
So the view is not loaded uselessly
and the fields are not read for nothing
(performances & security).
Indeed, when a group is applied on a field itself, the field content
is read, but hidden, therefore reading the content of the field
uselessly, and potentially leading to accesses issues
if the user hasn't the rights to read the field.
(e.g. reading a property when not having access to the model
of the proprty, pricelists on partners for instance)
opw-634402
"Invoiced" stat button on the res.partner form view must not include cancelled and draft invoices.
The button triggered an action which shows a tree view with invoices where:
type in ['out_invoice'] and all states.
Now the button triggers a tree view with invoices where: type in ['out_invoice' , 'out_refund']
and state not in ['draft', 'cancel'].
opw:472318
When having account installed, but having as only
access right "Contacts creation", it wasn't possible to
display the partner form.
Setting the "groups" on the button itself has as effect
to hide the button, but not to prevent its value computation.
If you did not had the access rights required to compute the
buttons values, it leaded to security issues.
Put the "groups" on the view instead prevent the button to be loaded,
and its value to be computed. It therefore avoids both
a useless computation (computing the value of a hidden button
is not really useful), and prevent any access rights warnings.
Besides, 3 different groups were needed to display the
three buttons:
- account.group_account_invoice
- account.group_account_user
- analytic.group_analytic_accounting
Not having one of these tree groups could lead to security
warnings. We therefore split this view into three sub-views,
with each one a group set (and a button)
opw-628668
First match a fiscal position for the given country, then for a country
group containing the country. If none found, search a fiscal position
without country nor country group
Add group of countries res.country.group
Add get_fiscal_position method a method to compute a fiscal position based on company_id, partner_id, delivery_id
The meaning of res.partner.fiscal_position is now a forced a fiscal position.
The default implementation should handle simple cases, like VAT in UE and sales
tax in the US, but the method can be overriden to handle more complex ficals
rules.
This branch adds contextual buttons for the various items contained
in the history tab that are removed.
res.partner:
- in crm: re-ordered of the various Leads/Meetings/Opportunities buttons
- in crm_claim: added a Claims button, removed claims in history tab
- in event: removed one2many field towards event.event and event.registration, as well as other data related to history tab
- in marketing_campaigns: removed on2many field toward workitems (workitem_ids)
- in project: removed task from history; added Tasks button
- in project_issue: removed issues from history; added Issues button
bzr revid: tde@openerp.com-20130614121020-zl1l18iz9gv1smaa
The same action was erroneously used in two incompatible
cases: once for openining the list of analytic accounts
from a partner form view (requires a special context
with a client-side `active_id` variable) and the second
one for the main Analytic Account menu item (which
cannot have `active_id` in the context - it would crash).
The fix includes setting an empty ({}) context explicitly
on the original action to be sure the incorrect context
is removed upon update.
The error was introduced at rev.8685
revid:qdp-launchpad@openerp.com-20130418125951-8p0tfexd9jj8l75b
bzr revid: odo@openerp.com-20130507165113-67lam91046t56ky8
Fixes handling of accounting/invoicing-related fields on partners
that are not "commercial entities" (either marked as "is_company"
or parentless).
The corresponding fields are also hidden from form views on these
partners and replaced by a short sentence and a link to edit the
"master fields" on the commercial entity.
This corresponds to part B of the solution described on bug 1160365.
lp bug: https://launchpad.net/bugs/1160365 fixed
bzr revid: odo@openerp.com-20130407235013-j3tv4uxy46eej43i
This is the second part of the fix for bug
1068822.
res.partner.bank overrides fields_get() and sometimes adds
extra `states` attributes on the fields. This requires the
presence of the special `state` field in all views.
lp bug: https://launchpad.net/bugs/1068822 fixed
bzr revid: odo@openerp.com-20130225141014-zqbzbldqkl997lfu
Goffin Simon
Denis Ledoux
Christophe Matthieu
Olivier Dony
Antony Lesuisse
Fabien Meghazi
Gery Debongnie
Denis Ledoux
Jaydeep Barot
Randhir Mayatra rma-openerp
Thibault Delavallée
Paramjit Singh Sahota
Quentin (OpenERP)
Josse Colpaert
Vishmita
Alexis de Lattre
Fabien Pinckaers
Hardik
Atul Patel (OpenERP)
Turkesh Patel (Open ERP)
Fabien Pinckaers
Harry (OpenERP)
Khushboo Bhatt (Open ERP)
Jigar Amin - OpenERP
ajay javiya (OpenERP)
Sanjay Gohel (Open ERP)
Vo Minh Thu
Twinkle Christian (OpenERP)
Mayur Maheshwari (OpenERP)