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

[Stéphane Ducasse]

>
> In Gjallar there are two kinds of filters:
> - the freetext filter using the external free text engine Swish-e.
> - the normal filter which is either:
> 	- an arbitrary boolean expression of predicates
> 	- a simple conjunction of predicates (p1 AND p2 AND p3)
>
> There are different kinds of predicates but typically all fields or
> other attributes of a case can be used. For example, a multiselect  
> list
> box of all stages in the workflow.
>
> Then to top it off you can stack filters on top of each other - like a
> pipeline.
>
> 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.


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

> 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.

>
>> 	- 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?

Stef