DB editor does not always allow to change parameter

[jkiviluo]

• I have a selected object_class, parameter_name (type scalar), alternative_name and double click the value field
• I realize I actually have wrong parameter_name, because I wanted a parameter based on a value_list and I don't see a list
• I go back to parameter_name and try to change it to the right parameter (that would be based on value list)
• Will not change (presumably because value field is now of type scalar and it does not want to change to value list based parameter)
• This is quite confusing, because user does not understand why it's not possible to change (the value field is empty)
• I think one should be allowed to change. Even if there was an actual value. Another option to give a warning, but I think that's too much pampering in this case. The value could stay there until the user has chosen a value from the value list (and the row is not 'ready' before that is done).

[soininen]

We indeed prevent the completion of rows in the parameter tables that would break database integrity because once the row is completed, it gets integrate into the 'machinery' as a trusted member of the database (of course, you need to commit before the data is actually stored). I agree the behavior can be frustrating and not only in the case described above. I think we should consider a more general solution.

What I have in mind is to mark rows that have issues by e.g. different background color until user fixes them. Only rows without issues would be added/updated.

[jkiviluo]

I like the idea of color coding rows (or even cells) that have issues.

[jkiviluo]

Could this be small enough to be squeezed into 0.7?

[soininen]

There is some work here but it would improve usability a lot.