[Setools] Gjallar let's go

[Hans N Beck]

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.
> 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  
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  
to differ semantic links (like merge, subcases) from workflow links  
(a test a requirement which is linked to a bug notice or customer  
complaint)

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

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 :-)
>
>
> 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

Hans
>
> regards, Göran
> _______________________________________________
> Setools mailing list
> Setools at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/setools