← Back to team overview

openerp-expert-framework team mailing list archive

Re: Web widget for Editable Tree views barely usable in trunk

 

On 2012-12-06, at 13:08 , Valentin LAB wrote:
> 
> I'm using the editable tree view widget, and I can't stand the silence around this case.
> 
> This widget is utterly broken. In trunk. I filled a bug report:
> https://bugs.launchpad.net/openerp-web/+bug/1086933

Thank you.

> And I know that's not a precise bug with a clean way to reproduce it, but I won't have time to list all the bugs. See the video if you want quick idea.
> 
> https://bugs.launchpad.net/openerp-web/+bug/1086933/+attachment/3452910/+files/editable-treeview-widget.ogv
> 
> My question are:
> - is the editable tree view officialy known to be in WIP state ?

Not really.

> And will we get a better widget for the final 7.0 ?

If bugs are reported against it, if we don't hit bugs internally and you
don't report the issues you have with it, it's hard to know things don't
work as expected. Thus if we don't hear anything about a component, the
only conclusions we can make are either "works" or "nobody uses it".

> - through which QA process did this code go ?

It was tested by our QA employee, but quite obviously the way QA is done
may or may not match the precise usage of third parties using it
extensively so some problematic usage patterns may not have been
envisioned and thus tested; and QA has a lot of ground to cover.

> Bugs report take time to make it through
> ----------------------------------------
> 
> I've lost time to report this bug to get a first random answer to my bug report which randomly found an example where it works

It's not really a random answer as far as I can see, Jignesh tried to go
through your report and reproduce your various cases in order to triage
the bug, that's his job. Some of the cases you explained he couldn't
reproduce, he indicated so and waited/asked for further information.

Local reproduction is fairly important, if we can't reproduce a bug we
can't fix it as we have no way to diagnose it.

> (yes, I'm using it daily, so I know you can bend it enough to find some way to get the basic tasks done, but you must have a hard learn experience before.). And I had to record my video to show what seems to me complete evidence.

For you it's complete evidence because you're using the tool
automatically in a certain way, somebody else may (and probably does)
use it differently and not hit the snags you do. That's why we need you
to define your baseline "complete evidence" in order to avoid incorrect
assumptions. And it's not specific to external reports, internal reports
have the exact same issues. This is even more important for cases of
"kind-of works but not always".

> Sorry if I might sound pissed off, but that's what frustration leads to usually.

You don't sound pissed-off to me, for what it's worth.

> If there was a better way to report this, please comment.

Shooting a bug when you encounter it, big dumps like this one are much
harder to trawl through and report progress status on. A short video
record is usually greatly appreciated for UI-based issues as — as noted
above — it may provide information about your baseline assumptions to
the triage teams, assumptions which they themselves may not usually
make.

Follow ups

References