ir.default removal
Nicolas Évrard
Yesterday we talked on IRC, about removing the ir.default object from
tryton.
Our main issues with ir.default are:
- No access right what so ever: anybody can set a default value
for anybody else,
- No multi-company support: A default value set through this
feature will be used for every companies
- Can break workflow or other stuffs: A user can set as default
the value of states to a certain state and thus it might break
some logic that relies on this field.
Moreover it seems that the current use of this feature can be replaced
either by:
- making tryton's modules more clever
- customizing the company object to set default company-wise.
Does anybody have strong feelings about this issue or could we go on
with their removal ?
--
Nicolas Évrard
B2CK SPRL
rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
E-mail/Jabber: nicolas...@b2ck.com
Website: http://www.b2ck.com/
Udo Spallek
good idea to bring ir.defaults into discussion.
Am Donnerstag, den 03.03.2011, 18:27 +0100 schrieb Nicolas Évrard:
> Hello the list,
> Yesterday we talked on IRC, about removing the ir.default object from
> tryton.
> Our main issues with ir.default are:
> - No access right what so ever: anybody can set a default value
> for anybody else,
Why not just remove the field 'apply to all users' from UI and make
field user required in ir.default?
> - No multi-company support: A default value set through this
> feature will be used for every companies
As ir.default is provided from the framework, it does not know anything
about companies.
I would extend the company Model and add the field company required to
ir.default. Like we do with properties.
> - Can break workflow or other stuffs: A user can set as default
> the value of states to a certain state and thus it might break
> some logic that relies on this field.
Here I would avoid to set defaults for readonly fields. But I do not
know if it is easy to do, since we have the states attribute on fields.
> Moreover it seems that the current use of this feature can be replaced
> either by:
> - making tryton's modules more clever
I can not imagine how to bring ir.default functionality from clever
modules? Could you explain, please.
Think about one sales person for French customers will have default
language 'French' on new parties. And the sales person for GB will have
a default language 'Englisch' for new parties. This can not be done with
better default_<field> methods.
> - customizing the company object to set default company-wise.
But company is not available for standard user. It is restricted to
group company-admin. Additionally it is not so easy to edit a table of
fields/defaults then like now, just right click on a field and choose
'set as default'. But maybe I misunderstand, so please explain what to
do here.
> Does anybody have strong feelings about this issue or could we go on
> with their removal ?
I like the right click options: set as default/set default/reset
default. The underlaying code is equal to me and can be better.
Regards
--
Udo Spallek
------------------------------------
virtual things
Preisler & Spallek GbR
Munich - Aix-la-Chapelle
Windeckstr. 77
81375 Munich - Germany
Tel: +49 (89) 710 481 55
Fax: +49 (89) 710 481 56
in...@virtual-things.biz
http://www.virtual-things.biz
Mathias Behrle
Hi Nicolas,
> Yesterday we talked on IRC, about removing the ir.default object from
> tryton.
>
> Our main issues with ir.default are:
>
> - No access right what so ever: anybody can set a default value
> for anybody else,
> - No multi-company support: A default value set through this
> feature will be used for every companies
> - Can break workflow or other stuffs: A user can set as default
> the value of states to a certain state and thus it might break
> some logic that relies on this field.
>
> Moreover it seems that the current use of this feature can be replaced
> either by:
>
> - making tryton's modules more clever
> - customizing the company object to set default company-wise.
>
> Does anybody have strong feelings about this issue or could we go on
> with their removal ?
The feature to enable an user to adapt the application to his preferences is
still very attractive for me. Wouldn't it be able to harden the feature to only
offer per user and company settings without completely removing it?
--
Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg
Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6
Cédric Krier
> Hello Nicolas,
>
> good idea to bring ir.defaults into discussion.
> Am Donnerstag, den 03.03.2011, 18:27 +0100 schrieb Nicolas Évrard:
> > Hello the list,
> > Yesterday we talked on IRC, about removing the ir.default object from
> > tryton.
> > Our main issues with ir.default are:
> > - No access right what so ever: anybody can set a default value
> > for anybody else,
> Why not just remove the field 'apply to all users' from UI and make
> field user required in ir.default?
>
> > - No multi-company support: A default value set through this
> > feature will be used for every companies
> As ir.default is provided from the framework, it does not know anything
> about companies.
> I would extend the company Model and add the field company required to
> ir.default. Like we do with properties.
>
> > - Can break workflow or other stuffs: A user can set as default
> > the value of states to a certain state and thus it might break
> > some logic that relies on this field.
> Here I would avoid to set defaults for readonly fields. But I do not
> know if it is easy to do, since we have the states attribute on fields.
This is not enough. You must understand that this feature allow to overide any
coded default value. This is a bad design as it brings on two places the same
concept/behavior.
>
> > Moreover it seems that the current use of this feature can be replaced
> > either by:
> > - making tryton's modules more clever
> I can not imagine how to bring ir.default functionality from clever
> modules? Could you explain, please.
>
> Think about one sales person for French customers will have default
> language 'French' on new parties. And the sales person for GB will have
> a default language 'Englisch' for new parties. This can not be done with
> better default_<field> methods.
Exactly.
We should identify every cases people wrongly used the ir.default and modify
the code to have a clear way to fix it per example by defining more
configuration values on singletons, on company or on user. And perhaps some
will go on specific modules.
>
> > - customizing the company object to set default company-wise.
> But company is not available for standard user. It is restricted to
> group company-admin. Additionally it is not so easy to edit a table of
> fields/defaults then like now, just right click on a field and choose
> 'set as default'. But maybe I misunderstand, so please explain what to
> do here.
>
> > Does anybody have strong feelings about this issue or could we go on
> > with their removal ?
> I like the right click options: set as default/set default/reset
> default.
This is a decoy. This was a fonctionnality that makes think it is powerful but
indeed it spreads all over the application the business/company rules. So
nobody could have a clear picture of the workflow, rules etc.
--
Cédric Krier
B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Email/Jabber: cedric...@b2ck.com
Website: http://www.b2ck.com/
Cédric Krier
> * Betr.: " [tryton-dev] ir.default removal" (Thu, 3 Mar 2011 18:27:20 +0100):
>
> Hi Nicolas,
>
> > Yesterday we talked on IRC, about removing the ir.default object from
> > tryton.
> >
> > Our main issues with ir.default are:
> >
> > - No access right what so ever: anybody can set a default value
> > for anybody else,
> > - No multi-company support: A default value set through this
> > feature will be used for every companies
> > - Can break workflow or other stuffs: A user can set as default
> > the value of states to a certain state and thus it might break
> > some logic that relies on this field.
> >
> > Moreover it seems that the current use of this feature can be replaced
> > either by:
> >
> > - making tryton's modules more clever
> > - customizing the company object to set default company-wise.
> >
> > Does anybody have strong feelings about this issue or could we go on
> > with their removal ?
>
> The feature to enable an user to adapt the application to his preferences is
> still very attractive for me. Wouldn't it be able to harden the feature to only
> offer per user and company settings without completely removing it?
The current design makes the enforcement very difficult and perhaps
impossible because:
- the dialog box is design in the client (so no module customization)
- the database schema is very simplistic:
- value: Text field
- clause: Text field
- it is not possible to add business rules because it is defined in deeply
in the kernel
--
Cédric Krier
B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Mathias Behrle
+0100):
> > The feature to enable an user to adapt the application to his preferences is
> > still very attractive for me. Wouldn't it be able to harden the feature to
> > only offer per user and company settings without completely removing it?
>
> The current design makes the enforcement very difficult and perhaps
> impossible because:
>
> - the dialog box is design in the client (so no module customization)
>
> - the database schema is very simplistic:
> - value: Text field
> - clause: Text field
I completely agree, that this feature may not supersede application rules. OTOH
for me it *is* a real feature to have such a possibility, that lets the user
adapt the application to his ususal needs. Whenever I showed it to
users/customers they were excited to have such a solution, that is rarely
encountered in other applications.
So, if ever possible, it would be nice to have a user driven model, that
- follows access rules
- is multi-company
- probably should only work on a subset of models (selection, o2m, ...)
> - it is not possible to add business rules because it is defined in deeply
> in the kernel
Business rules should indeed be enforced in a completely other way.
Cédric Krier
> * Betr.: " Re: [tryton-dev] ir.default removal" (Thu, 3 Mar 2011 22:58:05
> +0100):
>
> > > The feature to enable an user to adapt the application to his preferences is
> > > still very attractive for me. Wouldn't it be able to harden the feature to
> > > only offer per user and company settings without completely removing it?
> >
> > The current design makes the enforcement very difficult and perhaps
> > impossible because:
> >
> > - the dialog box is design in the client (so no module customization)
> >
> > - the database schema is very simplistic:
> > - value: Text field
> > - clause: Text field
>
> I completely agree, that this feature may not supersede application rules. OTOH
> for me it *is* a real feature to have such a possibility, that lets the user
> adapt the application to his ususal needs. Whenever I showed it to
> users/customers they were excited to have such a solution, that is rarely
> encountered in other applications.
>
> So, if ever possible, it would be nice to have a user driven model, that
>
> - follows access rules
> - is multi-company
> - probably should only work on a subset of models (selection, o2m, ...)
The only way to enforce correctly the "subset of models" is to forbide every
thing and define what is allow.
So who is able to define which fields can be allowed according to Model
constraint, workflow etc.? It is a developper. So the developper will add a
field somewhere (Company, User, Singleton) which will containt the customized
default value.
Don't you find it is not logical that to define what is the default invoicing
method for sale, you should create a new sale order, set the default value and
cancel the sale creation.
Instead of open company and set the value on a field named "Default invoicing
method".
>
> > - it is not possible to add business rules because it is defined in deeply
> > in the kernel
>
> Business rules should indeed be enforced in a completely other way.
By business rules, I'm talking about invoicing method, product creation
(accounting stuff from category or not) etc.
Default value are part of the business rules.
Udo Spallek
Am Donnerstag, den 03.03.2011, 22:52 +0100 schrieb Cédric Krier:
> On 03/03/11 19:21 +0100, Udo Spallek wrote:
> > good idea to bring ir.defaults into discussion.
> > Am Donnerstag, den 03.03.2011, 18:27 +0100 schrieb Nicolas Évrard:
> > > - Can break workflow or other stuffs: A user can set as default
> > > the value of states to a certain state and thus it might break
> > > some logic that relies on this field.
> > Here I would avoid to set defaults for readonly fields. But I do not
> > know if it is easy to do, since we have the states attribute on fields.
> This is not enough. You must understand that this feature allow to overide any
> coded default value. This is a bad design as it brings on two places the same
> concept/behavior.
or a user default. But you are right, it is not a good idea to allow user
defaults everywhere.
> > > Moreover it seems that the current use of this feature can be replaced
> > > either by:
> > > - making tryton's modules more clever
> > I can not imagine how to bring ir.default functionality from clever
> > modules? Could you explain, please.
> > Think about one sales person for French customers will have default
> > language 'French' on new parties. And the sales person for GB will have
> > a default language 'Englisch' for new parties. This can not be done with
> > better default_<field> methods.
> Exactly.
> We should identify every cases people wrongly used the ir.default and modify
> the code to have a clear way to fix it per example by defining more
> configuration values on singletons, on company or on user. And perhaps some
> will go on specific modules.
Do you mean some kind of functionality, which restrict or declare the
fields/models where the user can set a default?
So every module has to add some xml to allow explicit the fields a
user/company is able to set as default?
What will be the order for applying defaults?
First apply system defaults from default_<field name>, then company,
then user?
> > > - customizing the company object to set default company-wise.
> > But company is not available for standard user. It is restricted to
> > group company-admin. Additionally it is not so easy to edit a table of
> > fields/defaults then like now, just right click on a field and choose
> > 'set as default'. But maybe I misunderstand, so please explain what to
> > do here.
> >
> > > Does anybody have strong feelings about this issue or could we go on
> > > with their removal ?
> > I like the right click options: set as default/set default/reset
> > default.
> This is a decoy. This was a fonctionnality that makes think it is powerful but
> indeed it spreads all over the application the business/company rules. So
> nobody could have a clear picture of the workflow, rules etc.
Yes, thats true. And indeed it is very powerful. Yesterday I set a default on
invoice total amount. Guess what happened... I created a new invoice
which had this total amount, even without an invoice line...
So yes, probably the right click functionality should be removed and
replaced by a new default-system on company and user level.
Cédric Krier
> Hi,
> Am Donnerstag, den 03.03.2011, 22:52 +0100 schrieb Cédric Krier:
> > On 03/03/11 19:21 +0100, Udo Spallek wrote:
> > > > Moreover it seems that the current use of this feature can be replaced
> > > > either by:
> > > > - making tryton's modules more clever
> > > I can not imagine how to bring ir.default functionality from clever
> > > modules? Could you explain, please.
> > > Think about one sales person for French customers will have default
> > > language 'French' on new parties. And the sales person for GB will have
> > > a default language 'Englisch' for new parties. This can not be done with
> > > better default_<field> methods.
> > Exactly.
> > We should identify every cases people wrongly used the ir.default and modify
> > the code to have a clear way to fix it per example by defining more
> > configuration values on singletons, on company or on user. And perhaps some
> > will go on specific modules.
> Do you mean some kind of functionality, which restrict or declare the
> fields/models where the user can set a default?
No.
> So every module has to add some xml to allow explicit the fields a
> user/company is able to set as default?
No.
> What will be the order for applying defaults?
> First apply system defaults from default_<field name>, then company,
> then user?
If we design like that we will have the same bad design of ir.default.
The default value should be set for a field in only one place which is
default_<field name>.
Per example, a module that will add a default value for field will need to
override de default_<field name> method.