Gjallar brainstorm (was Re: [Setools] Gjallar (previously known
as Q2) next steps!)
Stéphane Ducasse
stephane.ducasse at univ-savoie.fr
Fri Aug 4 08:01:03 UTC 2006
>
> 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
More information about the Setools
mailing list