Re: [tryton-dev] Colors of fields

2015-07-07 Thread Jean Cavallo
2015-07-07 0:50 GMT+02:00 Albert Cervera i Areny alb...@nan-tic.com:

  So here is a screenshot of such invalid form with missing required field
  and wrong value because of domain.
  I think it is really an improvement because now we explain to the user
  what is wrong and experienced user can still anticipate required fields.
 

 I agree it is a very good improvement.


Indeed it looks rather good, and is very informative !

Jean Cavallo
*Coopengo*


Re: [tryton-dev] Colors of fields

2015-07-07 Thread Albert Cervera i Areny
2015-07-06 23:36 GMT+02:00 Cédric Krier cedric.kr...@b2ck.com:
 On 2015-07-04 08:58, Cédric Krier wrote:
 Hi,

 For now, we put a blue color on entries when they are required (and
 switch to red when validated as empty).
 I think it is a bad practice for 2 reasons:

 - the colors are not custumizable and so they could not work on some
   thèmes.

 - it is doesn't help the accessibility [1] as this information is
   only based on color.

 So I was thinking instead about adding a * on the labels of the
 required fields. This still stay quite visual (but not too much) and
 readable for accessibility.

 Indeed the '*' solution is not so beautiful.

 So I worked on an other proposal:

 - make label bold for required field

I think that making the label bold does not solve the problem when a
field has no label.

Of course, adding * has the same problem.

I don't see a better solution than changing the background color. To
circumvent the problem with themes or accessibility maybe we could
make the color configurable as a client side option. That would not be
ideal, but would improve current situation a little bit while not
suffering from the mentioned problems.

 - have a better 'invalid form' message that describe the problem

 So here is a screenshot of such invalid form with missing required field
 and wrong value because of domain.
 I think it is really an improvement because now we explain to the user
 what is wrong and experienced user can still anticipate required fields.

 --
 Cédric Krier - B2CK SPRL
 Email/Jabber: cedric.kr...@b2ck.com
 Tel: +32 472 54 46 59
 Website: http://www.b2ck.com/



-- 
Albert Cervera i Areny
Tel. 93 553 18 03
@albertnan
www.NaN-tic.com


Re: [tryton-dev] Wrong domains in sale/purchase searches in invoices?

2015-07-07 Thread Cédric Krier
On 2015-07-07 20:04, Jordi Esteve wrote:
 In sale and purchase modules the functional sales and purchases fields are
 defined on invoice model with a searcher method.
 
 If these fields are added in the invoice tree view and we search the
 invoices related to the SO001 sale, for example, I get this error SQL error
 because the sales id is compared with a string:
 
 ProgrammingError: operator does not exist: integer ~~* unknown
 LINE 1: ...e ON (e.id = d.sale) WHERE e.id ILIKE '%SO001
 ...
  ^
 HINT:  No operator matches the given name and argument type(s). You might
 need to add explicit type casts.
 
 
 The problem is the last .id in the domain of the searcher method. Removing
 '.id' the search works well:
 
 def search_sales(cls, name, clause):
 return [('lines.origin.sale*.id*',) + tuple(clause[1:]) +
 ('sale.line',)]
 
 Tested in v3.4 but I think v3.6 and trunk have the same behaviour.

Won't fix. You should consider it as the behaviour of this function
field.

-- 
Cédric Krier - B2CK SPRL
Email/Jabber: cedric.kr...@b2ck.com
Tel: +32 472 54 46 59
Website: http://www.b2ck.com/


Re: [tryton-dev] Colors of fields

2015-07-07 Thread Cédric Krier
On 2015-07-07 22:35, Albert Cervera i Areny wrote:
 2015-07-06 23:36 GMT+02:00 Cédric Krier cedric.kr...@b2ck.com:
  On 2015-07-04 08:58, Cédric Krier wrote:
  Hi,
 
  For now, we put a blue color on entries when they are required (and
  switch to red when validated as empty).
  I think it is a bad practice for 2 reasons:
 
  - the colors are not custumizable and so they could not work on some
thèmes.
 
  - it is doesn't help the accessibility [1] as this information is
only based on color.
 
  So I was thinking instead about adding a * on the labels of the
  required fields. This still stay quite visual (but not too much) and
  readable for accessibility.
 
  Indeed the '*' solution is not so beautiful.
 
  So I worked on an other proposal:
 
  - make label bold for required field
 
 I think that making the label bold does not solve the problem when a
 field has no label.
 
 Of course, adding * has the same problem.

Indeed for me, this is purly accessory. I added only because I know many
of you will cry thinking it is a lost. But in reality, it is realy not
needed to have such information. User must encode all the value he
knows, then if when he tries to perform an action that requires some
missing information, he will be warned (and the focus will be put at the
right place) and he will try to find a solution to fill the missing
value.
Also why required should be a special case compared to other validation
like domain, SQL constraint etc. For me, Tryton should have the strictly
minimal constraint and thus those constraint should be so obvious that
they don't need to be shown.

 I don't see a better solution than changing the background color. To
 circumvent the problem with themes or accessibility maybe we could
 make the color configurable as a client side option.

Options are always the poorest answer.

 That would not be
 ideal, but would improve current situation a little bit while not
 suffering from the mentioned problems.

Except the application will become more complex, you will have to
explain what is the meaning of this option which will not be so easy.
Plus it will create a new vector of issues.

-- 
Cédric Krier - B2CK SPRL
Email/Jabber: cedric.kr...@b2ck.com
Tel: +32 472 54 46 59
Website: http://www.b2ck.com/


Re: [tryton-dev] Wrong domains in sale/purchase searches in invoices?

2015-07-07 Thread Cédric Krier
On 2015-07-07 23:38, Cédric Krier wrote:
 On 2015-07-07 20:04, Jordi Esteve wrote:
  In sale and purchase modules the functional sales and purchases fields are
  defined on invoice model with a searcher method.
  
  If these fields are added in the invoice tree view and we search the
  invoices related to the SO001 sale, for example, I get this error SQL error
  because the sales id is compared with a string:
  
  ProgrammingError: operator does not exist: integer ~~* unknown
  LINE 1: ...e ON (e.id = d.sale) WHERE e.id ILIKE '%SO001
  ...
   ^
  HINT:  No operator matches the given name and argument type(s). You might
  need to add explicit type casts.
  
  
  The problem is the last .id in the domain of the searcher method. Removing
  '.id' the search works well:
  
  def search_sales(cls, name, clause):
  return [('lines.origin.sale*.id*',) + tuple(clause[1:]) +
  ('sale.line',)]
  
  Tested in v3.4 but I think v3.6 and trunk have the same behaviour.
 
 Won't fix. You should consider it as the behaviour of this function
 field.

Indeed now, the implementation of the searcher of many2one behaves the
same as the searcher on one2many. So yes, removing the '.id' should
allow to also use string as search value.

-- 
Cédric Krier - B2CK SPRL
Email/Jabber: cedric.kr...@b2ck.com
Tel: +32 472 54 46 59
Website: http://www.b2ck.com/


Re: [tryton-dev] Colors of fields

2015-07-07 Thread Cédric Krier
On 2015-07-06 23:36, Cédric Krier wrote:
 On 2015-07-04 08:58, Cédric Krier wrote:
  Hi,
  
  For now, we put a blue color on entries when they are required (and
  switch to red when validated as empty).
  I think it is a bad practice for 2 reasons:
  
  - the colors are not custumizable and so they could not work on some
thèmes.
  
  - it is doesn't help the accessibility [1] as this information is
only based on color.
  
  So I was thinking instead about adding a * on the labels of the
  required fields. This still stay quite visual (but not too much) and
  readable for accessibility.
 
 Indeed the '*' solution is not so beautiful.
 
 So I worked on an other proposal:
 
 - make label bold for required field
 - have a better 'invalid form' message that describe the problem
 
 So here is a screenshot of such invalid form with missing required field
 and wrong value because of domain.
 I think it is really an improvement because now we explain to the user
 what is wrong and experienced user can still anticipate required fields.

FYI, the feature https://bugs.tryton.org/issue4861

-- 
Cédric Krier - B2CK SPRL
Email/Jabber: cedric.kr...@b2ck.com
Tel: +32 472 54 46 59
Website: http://www.b2ck.com/