Date: Wed, 23 May 2012 23:10:54 +0400 From: Aleksey Cherepanov <aleksey.4erepanov@...il.com> To: john-users@...ts.openwall.com Subject: Re: existing collaboration tools suitable for MJohn On Mon, May 21, 2012 at 08:09:44PM +0400, Aleksey Cherepanov wrote: > So I'd like to investigate request-tracker. Request-tracker attracted > my attention because while it is a full featured site engine with cms > it is implemented in perl, supports web, email, and command-line > interfaces. Other systems of that class are similar but are not > implemented in perl and often lack support for multiple uis. I tried request-tracker. I noticed some things. Some are good, some are not so good. First feeling seeing it was that there are too many things and it is uncertain how to do even something. Then this feeling subsided rather fast without reference to documentation. Also there are things that could be used by advanced users (for instance "my todos") or by pentest companies (for example CCing) but could be stripped down to ease ui. There are themes that I think could be used for that but I am not sure. In general request-tracker is highly customizable: one could add custom fields to tickets, write callbacks/hooks/autocommands (called scrips) on any actions/events, write custom searches and store them, configure dashboard for easy access. But I am not sure how much things are covered by customization possibilities and how easy it would be for things that are not intended to change. I was unsure about amount of documentation available about request-tracker because company developed it sells a book about it and it seems that there are less documentation than for other projects of such level. But I found documentation within distribution (though not a separate package) and due to its age (since 1996) it seems there are enough of recourses about request-tracker. There are no votes but there are priorities and we could add any custom field we want. That should be enough for searches based on votes but the voting process could be tricky. The most closest thing to attack description is a ticket. Also there are queues and tickets are live in queues so we could have one queue for attacks and use others for not attack specific talks. Tickets could reference each other. For patterns we could use articles or separate queue that pattern is a ticket in. To the of that mail I convinced myself that request-tracker is a good choice but I am still have a feeling that I should at least look on one other solution before any further actions in this direction. Regards, Aleksey Cherepanov
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.