[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120523191054.GA6893@debian>
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.
