[Setools] Gjallar let's go

[goran at krampe.se]

Hi!

Hans N Beck <hnbeck at t-online.de> wrote:
> Hi,
> >>
> >> In this context, I would ask if this was a requirement of customer
> >> that cases can not change type. Of course, that makes things easier.
> >
> > Well, it is not a requirement, rather a decision from me that avoiding
> > type changing makes things MUCH simpler and less error prone.
> 
> :-) I think so....
> 
> > Not really - I again think that linking is a much better mechanism. A
> > very common scenario at the customer is support cases that literally
> > spawns a flurry of sub cases in the form of development. But that does
> > not mean that the support case disappears or changes type.
> 
> This would be fine if it would be possible that a parent Case could  
> be filtered out from view, so that only the child cases are in the  
> game. The problem is, depending on the application, there are both  
> cases:  To see only that, what is valid (by splitting, the old  
> requirement is garbage, or even danger, because it introduces  
> redundancy) and to see both, if one want to show an overview (non  
> spilttet Cases) and detailed view (the splittet Cases). Hmm. Linking  
> and such filtering could mangage this, I think.

The links in Gjallar are bidirectional and there is no intrinsic "father
child" relation.
So when I say "sub case" that is just a mental image - there is no
difference between the two cases.

When viewing one of them, you see incoming and outgoing links (if you
are allowed to see them).

> > Merging of cases could be used when there are duplicate cases - but
> > linking seems to be just as easy and causes less confusion IMHO.
> >
> > What we want to do is make linking very easy (currently it is slightly
> > awkward) and also add viewing mechanisms so that you for example can
> > view a case with all its linked cases in an "interweaved" manner  
> > showing
> > all events and notes in a chronological merged view.
> 
> Yes, and the opposite, too. That would be good. Possibly it would be  

Not sure what the "opposite" is. Currently when you view a case you
don't see anything more about the linked cases than the link itself. If
you click on a link you suddenly are viewing that case instead.

So normally you are not getting overflowed with information here - just
two simple lists of hyperlinks, incoming and outgoing.

> good for using it if one have same relations as linking, like  
> "include", "expand" etc from UML Use Case (and more, of course). On  
> this relation class a filter could act on..... And it would be useful  

Yes, a Q2Link has a Q2LinkType. And a Q2LinkType is simply a named
object (with a description) that each Process can define its own.
There are a few builtin link types (subclasses of Q2LinkType) like "is
duplicate of" etc.

> to differ semantic links (like merge, subcases) from workflow links  
> (a test a requirement which is linked to a bug notice or customer  
> complaint)

Right.
 
> So we are not far away that linked Cases  assemble a graph - so this  
> could be input for GraphViZ ?

It could yes.

> BTW: of course it is important to have one working first version,  
> especially for your customer, but if I see a software the dreams  
> immediatly coming up what could be next,  its some kind of my  
> personal freakiness :-)

Sometimes dreaming is ok. :)

> > So to summarize:
> >
> > - A case belongs in one and one Process only.
> > - A user has access to n Processes. Each Process then decides  
> > internally
> > what permissions that user has in that Process.
> > - A Process imports "visible subsets" of all global objects, which
> > inclused users but also other things.
> 
> Ok
> 
> >
> > One fantasy scenario with having an imported user that does not have
> > access would be for example a Process that deals with personnel - the
> > managers have access to it and can for example assign users in  
> > roles or
> > a field in a case, without that user having access to the Process.
> >
> Yes, that would be really welcomed.
> >
> > I am working right now on "vacuuming" the sources and writing a guide
> > for the code. Might be able to publish later today/tonight.
> 
> Be cool man, don't work too much :-)

:)

regards, Göran