Gjallar brainstorm (was Re: [Setools] Gjallar (previously known as Q2) next steps!)

[Stéphane Ducasse]

Tx man
I got it (more or less).

For now we will focus on the workflow for bug tracking and see how it  
works.

Stef

> Hi!
>
> Have just gone through the original design document and revised it for
> public consumption:
>
> 	http://swiki.krampe.se/gjallar/uploads/1/OriginalDesign.pdf
>
> =?ISO-8859-1?Q?St=E9phane_Ducasse?= <stephane.ducasse at univ-savoie.fr>
> wrote:
>>> These filters can then be constructed by the user and are typically
>>> owned by the user. Think of a filter as a complex select:
>>> expression (or
>>> SQL expression). :)
>>
>> Yes I understood that but I could not link that to the rest. Where
>> filter were coming into play.
>
> Mainly searching in the web UI, producing reports and exports and  
> in the
> email notification mechanism.
>
>>> One way is to create a Process called "Todo lists", then create a  
>>> very
>>> simple workflow for it, like New->Working->Done. Then make a simple
>>> form
>>> - all cases already have Subject, Description, Reporter,  
>>> Responsible,
>>> Attachments and a few other things built in. But you can add more
>>> fields
>>> or even extra forms, which will appear as separate tabs in the  
>>> tab UI
>>> for the case.
>>
>> Why are you talking about forms.
>> Forms for me are UI elements that render some data (which can be
>> readonly, selected from lists, editable...)
>
> Well, a Form in Gjallar is the *domain object* representing a  
> collection
> of Fields. It is not the runtime Seaside component that renders it  
> (that
> is called FormComponent).
>
> So we tell the user that he can "add forms to cases". In the UI he  
> sees
> a drop down list with named Forms and when he picks one it is being
> added to the tab book of the case. Then he can select that tab and  
> enter
> data into the fields. In the domain model an instance of Q2Form is  
> added
> to an OrderedCollection in the Q2Case. So each Case knows that Forms
> have been added to it.
>
> This way a case first has perhaps only a single tab with the most  
> basic
> information entered. Then during the lifecycle of the case users can
> decide to add extra Forms as extra tabs. It can even be done
> automatically if the case enters a stage where there are rules that  
> says
> that a specific named Form must exist in the case before it can  
> move to
> the next stage.
>
>>> Then to "classify" todo list items you typically create a  
>>> CustomObject
>>> which is like a table with fields. The simplest CustomObject  
>>> could be
>>> one called say... "Severity" with values like "Annoying", "Minor",
>>> "Major", "Disaster".
>>>
>>> Then you tie that CustomObject to a drop down list box in a Form,  
>>> like
>>> for example the default case creation form.
>>
>> Why this domain object is linked with a UI element that way.
>> Do I care that I get a drop down list when I'm talking about the
>> domain: ie that my bug has
>> a status taken out of several possible choices.
>
> Well, this is because a case (the domain object) has a dynamic set of
> fields added to it (in the form of Forms).
>
> Or in other words - when the case is being rendered we ask the case  
> what
> Forms it has. Then we render each such Form as a tab in a tab book  
> - or
> rather we create Q2FormComponents and Q2FieldComponents that are  
> Seaside
> components representing that Form and its Fields. Each field component
> in those form components then ask the case what value it has - and the
> case has all such field values in a single Dictionary. So let's say it
> has the value "Disaster" in the Dictionary keyed by the field id.
>
> The values are typically atomic - they do not know the value domain.
>
> So instead the list field knows a "values provider" that it asks to  
> get
> the list it should present. Normally in this case that would be the
> CustomObjectType (Severity) which knows all CustomObjects in it
> (Annoying, Minor etc).
>
> Not sure if this explained it, but that is how it works today. :)
>
>>>> 	- bugs life-cyle that could be attached to different squeak
>>>> projects.
>>>
>>> The life cycle is described by the Workflow. We could either  
>>> create a
>>> standard Workflow for bugs, then createt a Process prototype with  
>>> that
>>> workflow and clone it once for each Squeak project. But that would
>>> create a bit too many Processes, so again, a good way is to express
>>> which Squeak project a bug belongs to by using a CustomObject and a
>>> drop
>>> down list to select from - much like in Mantis.
>>>
>>> So typically you use one Process if all cases can share the same
>>> workflow (same stages and transitions with rules), the same  
>>> permission
>>> model and the same set of users (but the permission model can let
>>> different people do different things).
>>
>> What kind of nodes and transitions do you have in your workflow:
>> join? split?
>
> The nodes are only of one class at the moment (Q2WorkflowStage) but  
> they
> are distinguished using isNew and isClosed which gives us three  
> "types"
> - new, open and closed. Several (ehm, this is actually a recent  
> change)
> stages can be considered "new" (if they are marked as isNew) and  
> several
> are "closed" (if marked with isClosed). Only one stage isInbox (and
> automatically isNew) - by convention the first stage in the collection
> of stages.
>
> I think we did this right before vacation so that cases could actually
> move between some initial stages and still be considered "new". When
> they eventually move to a stage that is not marked isNew or isClosed
> then they are considered "open" (being worked at typically).
>
> The transitions are directed. The case can only be in a single  
> stage at
> a given point in time so we have no split/join functionality - we felt
> it would make the model and system too complex for its use.
>
> Then we attach Criteria to the stages and transitions to restrict
> movement of the cases based on their content (entered values in forms
> and fields etc). This means that most of the validation rules are
> expressed as Criteria in the Workflow graph - and not as attributes of
> the Forms and Fields themselves. So you can edit the case, enter a  
> "bad"
> value, and save. But then the case will be restricted in movement  
> to the
> next stages.
>
> regards, Göran
> _______________________________________________
> Setools mailing list
> Setools at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/setools