Flyspray - The bug killer!

  • Status Unconfirmed
  • Percent Complete
    0%
  • Task Type Feature Request
  • Category Backend/Core
  • Assigned To No-one
  • Operating System All
  • Severity Medium
  • Priority Very Low
  • Reported Version 0.9.9.1-devel
  • Due in Version Undecided
  • Due Date Undecided
  • Votes 6
  • Private
Attached to Project: Flyspray - The bug killer!
Opened by Srivathsan M - 25.03.2007
Last edited by peterdd - 17.08.2015

FS#1222 - Workflow engine / Role-based State Transition Rules Engine

I have been working with Eventum (http://www.mysql.org/downloads/other/eventum/) for quite sometime now and in Contrast, I like Flyspray for its simplicity and practicality. But one thing I badly miss (and something that Eventum scores high) is a Workflow Engine. If not a sophisticated W.E., I (as an Admin / Manager) should be able define Role-based State Transition Rules of the Tasks reported in a particular Project. For example, I should be able to implement the following Scenario:

  1. For a "Developer", the subsequent tasks from various states.  Likewise for other roles
  2. "Developer" should not be able close out the Bug Reports.  He / She can only flag them as implemented.  The "Reporter" of the Bug(s) or the "Manager" alone should be able  to close out issues
  :
  : - it will go on like that ;-)

This Feature, in my opinion, is very crucial for Corporate Organizations to give a serious consideration to Flyspray.

Admin
Florian Schmitz commented on 25.03.2007 18:20

Isn’t what you mentioned already possible using the permission system? If you give examples for a new feature, they should show what is *not* possible currently.

Admin
Cristian Rodríguez R. commented on 26.03.2007 01:08
This Feature, in my opinion, is very crucial for Corporate Organizations to give a serious consideration to Flyspray.

Flyspray will probably never be suitable for “big corporations” and that is the expected behaviuor. ;) that kind of users needs Bugzilla or something much more better designed like Jira, we dont target them, it is not our goal.

In any case, we will love to hear about what is missing (in detail) and how you think the missing features should be implemented.

Srivathsan M commented on 28.03.2007 07:25

Sorry for the late reply (for the comments of Florian and Cristian).

The Permission System of Flyspray is really better than that of Eventum’s. But what I could not do is to limit / control the Task Statuses available for a particular task, based on the User Role of the currently logged on User, Task Type and the current Task Status. I would prefer that this is achieved through something that is very similar to the Permission System - or even an extension to it.

For example, in our company, we have a workflow by which the Reporter (one who submits bugs) re-checks the Tasks and flag them as “Verified OK” or “Verify FAILED” after which the Project Manager can appropriately close them out (as either “DONE” or “FAILED”). The Reporter should not be able to change to any other Status while he can just view the Status being changed by the Developers.

If the above could be achieved through the current System, I would like to know about it.

Admin
Florian Schmitz commented on 28.03.2007 08:23

No, it cannot. Before we can ever consider implementing it though, we have to find a way how to easlily implement this, without any complexity. Maybe you can give a few more examples what might be needed?

Thorin commented on 09.04.2007 09:57

“Group”, “Task type” - to manage workflow

                  St1,    St2,      St3

  * Status1       chk      chk      chk

  * Status2       chk      chk      chk

  * Status3       chk      chk      chk

It’s a a table with NxN status collumns where chk is check button and defines the horizontally status transition for selected
is how the issue is implemented in the redMine project management system http://www.redmine.org/ :)

sorry for the formatting... :(

Jan commented on 28.08.2007 13:42

I figure I would chime in here.

Our site (http://www.mp3car.com) produces the software 'StreetDeck'. This is a software front end for use with CarPCs to make using CarPCs in the automotive environment easier. Currently this is the bug tracking system I've hacked together using mods with vBulletin: http://www.mp3car.com/vbulletin/streetdeck-bug-reports/

It works ok but it's difficult to keep track of it all and I'm running into issues with the forms and user groups.

By nature, I don't want the users to have the right to assign severity because they all think their issue is the top issue out there. The developers and staff need to be able to assign severity based on work flow.

Admin
Florian Schmitz commented on 28.08.2007 16:45

Such a thing is already possible. In 1.0 you can "force default" of a field, that will only allow users who can modify all tasks to change it.

Jan commented on 28.08.2007 19:55

Just so I can be sure I understand this:

If you select the check box in the 'force default' column, then no matter what the field is, it will only allow users who can modify all tasks to select other items in that list?

Admin
Florian Schmitz commented on 28.08.2007 20:02

Right.

Jan commented on 28.08.2007 23:09

Sorry about the double post. didn't realize I still had it in my browser.

Project Manager
peterdd commented on 10.08.2015 04:49

So it would require such database table for defining the possible task status transitions?:

<table name=workflow">
<field name="project_id" type="I"></field>
<field name="group_id" type="I"></field>
<field name="tasktype_id" type="I"></field>
<field name="from_status_id" type="I"></field>
<field name="to_status_id" type="I"></field>
</table>

Because a user can be in several groups, the available edges of workflows will be calculated dynamic for each user. (like the flyspray permission system)

Managing it for each group and each task type sounds quite complex to maintain.
Maybe needs a 3D matrix cube mit semitransparent nodes and transition lines in a 2d or 3d canvas to visualize. ;-)

And then someone wants different workflows for different projects. What should then happen with the global groups, global task types, and global task statuses?

We probably end with a 5 dimensional array.

Maybe we can go a similiar way like with the permission system.
Do the global workflows with project_id=0 and global user groups. And each project can add his own additional task status transitions.

Maybe shortcuts for simplified maintaining of workflows:

  • group_id=0 to make a transition rule working for every group
  • tasktype_id=0 to make a transition rule working for every task type
  • project_id= 0 to make a transition rule working for all projects

Well, maybe I will check out the competitor projects that have workflows builtin...

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing