The old-api model._all_columns contains information about model._columns and
inherited columns. This dictionary is missing new-api computed non-stored
fields, and the new field objects provide a more readable api...
This commit contains the following changes:
- adapt several methods of BaseModel to use fields instead of columns and
_all_columns
- copy all semantic-free attributes of related fields from their source
- add attribute 'group_operator' on integer and float fields
- base, base_action_rule, crm, edi, hr, mail, mass_mailing, pad,
payment_acquirer, share, website, website_crm, website_mail: simply use
_fields instead of _all_columns
- base, decimal_precision, website: adapt qweb rendering methods to use fields
instead of columns
We keep fold, because it has a meaning in kanban view, and is kind of
'drop' stage, for won / lost / cancel / dead.
New stage is now the stage with the lower sequence, not necessarily the
stage with sequence 1. Note that this could break the _track because it
checks for stages with sequence <= 1; however with OpenERP values it
works fine. In some specific stage configuration, some subtypes could
not be tracked precisely.
bzr revid: tde@openerp.com-20131023100429-a3vfxi5zkn18v6qq
After some experiments, having colors does not seem to give an
usable result on statusbar widget. Indeed we need to have the
current stage highlited, and maybe something to tell that some
stages have a special meaning and/or are the end of the pipe.
The closed field already gives that meaning.
Moreover the issue with the statusbar widget is that it indicates
state and action. Having both dimensions with colors / icons
is quite difficult to understand. We therefore stand on a simpler
version of the widget, only with stages and the current stage
highlighted.
bzr revid: tde@openerp.com-20131021104912-8ybhw0svdoghheh3
- stages: added some fields
-- closed: indicates whether this stage close the working process, for
example task ended, lead lost, applicant hired
-- bar_fold: whether to hide the state in the statusbar; this is different
from fold that is used for kanban views. Viewing a pipe or a specific
record are effectively different things and should use different fields.
-- bar_color: field to customize the stage in the statusbar (still WIP)
- impacted addons: crm, project, project_issue, hr_recruitment
- removed 'closed' addition in project_mrp as this is now in base project
module
bzr revid: tde@openerp.com-20131018132120-h0pv01q2bagtp99x
Added an end date in the read_group domain. Indeed having results outside the date range
made the result computation crash because of list limits. There is now a begin and end
date for groupby domain.
bzr revid: tde@openerp.com-20131003082736-tw50xk2vmhpjh1e5
The delete-rule was initially set to `cascade` in revision
6897.16.13 revid:odo@openerp.com-20120705141706-5gm5mmqode3bvkuc
because the ORM would not allow anything else for the FK of
an _inherits relationship.
This constraint was later lifted in 7.0 server at revision
4681 revid:odo@openerp.com-20121212210247-emrz5rf9ewcwdggu
so we can now switch to the intended default behavior:
when deleting mail aliases we never want to cascade delete
the child records, as that could lead to unwanted deletions.
On the other hand the aliases are automatically deleted when
the record they belong to is deleted, as a kind of internal
dependency. This is the intended safe way to delete them.
There is a special case when the same alias is manually set
on multiple records, in which case you will not be able to
delete any of those records. This is an acceptable exception
and should be manually handled if ever needed, by temporarily
linking the records to delete to new dummy aliases.
bzr revid: odo@openerp.com-20130827150708-62hqk8p7twd527n0
The parent record is the record that holds the alias. It is different
from the record updated or created using the alias. For example
projects have aliases whose parent is the given projet, and that creates
new task inside the project.
Updated alias creation and management accordingly.
This ownership concept is used to compute the 'followers' contact
settings of aliases.
bzr revid: tde@openerp.com-20130516164207-1zr0q6abw6a34ndf