development process

Hi,

I have come across Mantis recently as a potential candidate
for  
tracking our projects. We currently have an inhouse system
which has  
some very nice custom features we'd like to bring acrossto
Mantis.  
Many of them can be accomplished with a separate front end
which we  
will write for Mantis, through the SOAP interface,
connecting  
directly to the database, or via the core API functions.
Others  
require minor updates to the Mantis db schema (for instance,
to add a  
random key to the bug table to enable passwordless access to
specific  
bugs by customers).

What is the policy for inclusion of changes to Mantis and of
 
development in general? There appears to be a stable branch
(1.0.7)  
and HEAD. How are features chosen for inclusion in HEAD?

I ask mainly because there are a number of bugs in the
tracker which  
have lingered for a very long time. For instance:

http://
www.mantisbt.org/bugs/view.php?id=4286

The original poster has continued to update the patch for
each  
release, but I wonder why this isn't being incorporated into
cvs and  
then further cleaned up once there?

This particular feature is important to us, but I'm also
interested  
to know how any contributions we might make will be treated.
Assuming  
our code is generally useful and well written, is that
sufficient or  
are there some additional requirements from Futureware as
the  
controlling entity?


The biggest features we would be interested in adding are:

* email lodgment of tasks and appropriate linking of email
responses  
to the original task
* improvement of GUI design for better readability (possibly
the  
integration of some sort of templating engine to make this
easier)
* ability for customers to access a single bug and its
history  
without being given general access

Certainly we are still looking at our choices to see which
bug  
tracker is best suited to our needs, but with our PHP skills
Mantis  
has some clear advantages for us, even if that requires us
to fork  
the project for our needs.


Cheers
Ari Maniatis




-------------------------->
ish
http://www.ish.com.au
Level 1, 30 Wilson Street Newtown 2042 Australia
phone +61 2 9550 5001   fax +61 2 9550 4001
GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E
3E49 102A



------------------------------------------------------------
-------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the
chance to share your
opinions on IT & business topics through brief
surveys-and earn cash
http://www.techsay.com/default.
php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
mantisbt-dev mailing list
mantisbt-devlists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mantisbt-d
ev

On 14/04/2007, at 6:07 PM, Victor Boctor wrote:

> [Victor] Makes sense to me, but I would like us to
write the  
> requirements
> for the feature first.
> http://www.mantisbt.org/wiki/doku.php/mantisbt:requir
ements

I'll try and start such a page. Could you please create
"http:// 
www.mantisbt.org/wiki/doku.php/mantisbt:passwordless_protect
ed_access"

> Questions that I would like to see answered are:
> 1. Does the user get a snapshot or access to future
changes as well.

The current state.

> 2. What access does the user get when accessing this
issue?  For  
> example,
> does the user then get access to private notes?

In our current implementation no. But that could be an
option I  
guess. We use private notes for internal conversations we
don't want  
our customers to read.

> 3. Does the user only have read-only access to the
issue?

For us yes, (but they can add notes). We don't want
customers all  
increasing priority to "extremely high". Sounds
like another  
candidate for some preferences for the Mantis admin to
choose.

> 4. What configuration options are going to be used to
implement this
> feature?

I need to read some more Mantis code to see how this works.

> 5. What are the suggested database changes?

The main one is that we need a random key assigned to each
bug. Then:

http://mantis.company.com.au/task.php?key=987ty
jkhcgwip2uy523hriu

will take you directly to the appropriate page. The way we
use that  
is to put that link into outgoing confirmation emails.
Customers can  
click on the link to be taken directly to the appropriate
task, see  
the (public) notes and history and make another note. It is
very  
important (for us) that this page be highly customised. We
want only  
a subset of fields (for instance we don't want them to know
who is  
assigned to the task, or what priority we decide to set it)
and we  
want a page design which looks pretty.

Here is an example which we were using for testing a while
back:

http://squish.ish.com.au/t?i=4691&w=qxn0CoSqgIi0
NDZ96VSl

(Yes, it is just coincidence that our internally developed
bug  
tracker (about 10 years old now) has a similar logo to
Mantis. But  
where yours looks like something evil from Aliens, ours
looks like a  
zombie from a C grade film.... 


Ari Maniatis


-------------------------->
ish
http://www.ish.com.au
Level 1, 30 Wilson Street Newtown 2042 Australia
phone +61 2 9550 5001   fax +61 2 9550 4001
GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E
3E49 102A



------------------------------------------------------------
-------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the
chance to share your
opinions on IT & business topics through brief
surveys-and earn cash
http://www.techsay.com/default.
php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
mantisbt-dev mailing list
mantisbt-devlists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mantisbt-d
ev

This feature is something I was thinking about lately, so I
would like
to make some additional questions:

On 4/14/07, Aristedes Maniatis <ariish.com.au> wrote:
>
> On 14/04/2007, at 6:07 PM, Victor Boctor wrote:
> > Questions that I would like to see answered are:
> > 1. Does the user get a snapshot or access to
future changes as well.
>
> The current state.

Do this means the link is a "one time" password to
the page, so that
once seen the access will be denied? Or it means the ticked
will
"embed" somehow the info needed to show the
snapshot at the in the
given state even after more modifications will go into the
page?

>
> > 2. What access does the user get when accessing
this issue?  For
> > example,
> > does the user then get access to private notes?
>
> In our current implementation no. But that could be an
option I
> guess. We use private notes for internal conversations
we don't want
> our customers to read.

I think it makes sense to hide private notes, but I wonder
what
happens with private projects: IIRC all notes on private
projects are
marked private, so there will be nothing to read.
Maybe we just need to add a "Make public" button
to notes so
developers/administratrors could select which notes are
going to show
on the snapshot page.


>
> > 3. Does the user only have read-only access to the
issue?
>
> For us yes, (but they can add notes). We don't want
customers all
> increasing priority to "extremely high".
Sounds like another
> candidate for some preferences for the Mantis admin to
choose.

Looks sane as well.


>
> > 5. What are the suggested database changes?
>
> The main one is that we need a random key assigned to
each bug. Then:
>
> http://mantis.company.com.au/task.php?key=987ty
jkhcgwip2uy523hriu
>
> will take you directly to the appropriate page.

I think special care is needed to make sure the key will be
unpredictable, and even more if the user gain some
"privilege" using
that link.

> The way we use that
> is to put that link into outgoing confirmation emails.

Confirmations emails of what? issue submission?

> Customers can
> click on the link to be taken directly to the
appropriate task, see
> the (public) notes and history and make another note.
It is very
> important (for us) that this page be highly customised.
We want only
> a subset of fields (for instance we don't want them to
know who is
> assigned to the task, or what priority we decide to set
it) and we
> want a page design which looks pretty.

I think we can add to this a really minimal companion page
for
submitting new issues

Cheers

Gianluca

------------------------------------------------------------
-------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and
take
control of your XML. No limits. Just data. Click to get it
now.
http://sourcefor
ge.net/powerbar/db2/
_______________________________________________
mantisbt-dev mailing list
mantisbt-devlists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mantisbt-d
ev

Hi Gianluca,

On 4/15/07, Gianluca Sforna <giallugmail.com> wrote:
> > On 14/04/2007, at 6:07 PM, Victor Boctor wrote:
> > > Questions that I would like to see answered
are:
> > > 1. Does the user get a snapshot or access to
future changes as well.
> >
> > The current state.
>
> Do this means the link is a "one time"
password to the page, so that
> once seen the access will be denied? Or it means the
ticked will
> "embed" somehow the info needed to show the
snapshot at the in the
> given state even after more modifications will go into
the page?

I think there should be no limit on the number of times a
customer can
use this link to access the bug.  However, we might want to
include a
feature to re-generate such key, if that is done, then users
who have
the old link will get access denied.

I also don't think we "can" or "should"
provide a snapshot, we should
always reflect the latest state of the issue.

> > > 2. What access does the user get when
accessing this issue?  For
> > > example,
> > > does the user then get access to private
notes?
> >
> > In our current implementation no. But that could
be an option I
> > guess. We use private notes for internal
conversations we don't want
> > our customers to read.
>
> I think it makes sense to hide private notes, but I
wonder what
> happens with private projects: IIRC all notes on
private projects are
> marked private, so there will be nothing to read.
> Maybe we just need to add a "Make public"
button to notes so
> developers/administratrors could select which notes are
going to show
> on the snapshot page.

You can have a private project, with a private issue, but
have public
notes on it.  There is no relation between the project/issue
being
private and a note being private.

> > > 3. Does the user only have read-only access
to the issue?
> >
> > For us yes, (but they can add notes). We don't
want customers all
> > increasing priority to "extremely high".
Sounds like another
> > candidate for some preferences for the Mantis
admin to choose.
>
> Looks sane as well.
> > > 5. What are the suggested database changes?
> >
> > The main one is that we need a random key assigned
to each bug. Then:
> >
> > http://mantis.company.com.au/task.php?key=987ty
jkhcgwip2uy523hriu
> >
> > will take you directly to the appropriate page.
>
> I think special care is needed to make sure the key
will be
> unpredictable, and even more if the user gain some
"privilege" using
> that link.

Regarding the key, we already have similar techniques for
doing RSS
authentication and verification after signup.  We should use
a similar
technique.

I was thinking that we don't log the user in, we just do a
one page
temp login, similar to what we do in scripts (e.g.
MantisConnect
webservice).  No cookies are set in this case.

> > The way we use that
> > is to put that link into outgoing confirmation
emails.
>
> Confirmations emails of what? issue submission?

Should this be the case or should we have a button that
allows sending
a public link to an issue for the specified email(s).  This
will allow
users to forward emails about the issue without necessarily
giving
future or direct access to it.

This also allows us to potentially create multiple keys to
one issue
and be able to expire one without expiring the others.  Also
will
allow us to keep track of the email addresses of the users
who have
access to the issue.  I think it is important to have some
visibility
for users above certain thresholds of the number of users
who have
direct access to the issue without being registered users. 
Also we
may even go one step further and have multiple keys that
provides
multiple levels of access.

> > Customers can
> > click on the link to be taken directly to the
appropriate task, see
> > the (public) notes and history and make another
note. It is very
> > important (for us) that this page be highly
customised. We want only
> > a subset of fields (for instance we don't want
them to know who is
> > assigned to the task, or what priority we decide
to set it) and we
> > want a page design which looks pretty.
>
> I think we can add to this a really minimal companion
page for
> submitting new issues

The problem with allowing submit is that we will have a new
issue in
the system without a proper reporter. We can associate this
with a
common user, but we won't have the email of the user so that
we can
get feedback and answers to questions.  This will be like
enabling
submit for anonymous.

It would be great if we can consolidate in this in the Wiki
page for
this feature.  Anyone up to it?

Regards,
Victor

------------------------------------------------------------
-------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and
take
control of your XML. No limits. Just data. Click to get it
now.
http://sourcefor
ge.net/powerbar/db2/
_______________________________________________
mantisbt-dev mailing list
mantisbt-devlists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mantisbt-d
ev

On 16/04/2007, at 3:59 AM, Victor Boctor wrote:

> On 4/15/07, Gianluca Sforna <giallugmail.com> wrote:
>> Do this means the link is a "one time"
password to the page, so that
>> once seen the access will be denied? Or it means
the ticked will
>> "embed" somehow the info needed to show
the snapshot at the in the
>> given state even after more modifications will go
into the page?
>
> I think there should be no limit on the number of times
a customer can
> use this link to access the bug.  However, we might
want to include a
> feature to re-generate such key, if that is done, then
users who have
> the old link will get access denied.
>
> I also don't think we "can" or
"should" provide a snapshot, we should
> always reflect the latest state of the issue.

Absolutely. This is just another way to see the task detail
page in  
its current state. And this isn't a one time key, it can be
used many  
times, hence the requirement to add another field to the bug
table  
with the random value. I propose that this random key is
added at bug  
creation whether or not this new feature is being used.


>> I think it makes sense to hide private notes, but I
wonder what
>> happens with private projects: IIRC all notes on
private projects are
>> marked private, so there will be nothing to read.
>> Maybe we just need to add a "Make public"
button to notes so
>> developers/administratrors could select which notes
are going to show
>> on the snapshot page.
>
> You can have a private project, with a private issue,
but have public
> notes on it.  There is no relation between the
project/issue being
> private and a note being private.

Good, the two should be separate concepts. I don't yet know
enough  
about Mantis, but it appears the concept of 'private' is
slightly  
flawed. It has the sense of 'elevate the permissions for
this bug/ 
note' but it doesn't say by how much or to whom. Surely it
is better  
to have 'access groups' of users and instead of a boolean
field here,  
there should be a relationship between a bug/note and an
access  
group. So, marking it as 'private' actually means 'restrict
this bug/ 
note to access group: management'. What I'm saying is that
it might  
be a popup, not a checkbox. Anyhow, that isn't part of this
proposal,  
so let's leave that to another conversation.


>> I think special care is needed to make sure the key
will be
>> unpredictable, and even more if the user gain some
"privilege" using
>> that link.

PHP has a perfectly good random function.

>>> The way we use that
>>> is to put that link into outgoing confirmation
emails.
>>
>> Confirmations emails of what? issue submission?
>
> Should this be the case or should we have a button that
allows sending
> a public link to an issue for the specified email(s). 
This will allow
> users to forward emails about the issue without
necessarily giving
> future or direct access to it.
>
> This also allows us to potentially create multiple keys
to one issue
> and be able to expire one without expiring the others. 
Also will
> allow us to keep track of the email addresses of the
users who have
> access to the issue.  I think it is important to have
some visibility
> for users above certain thresholds of the number of
users who have
> direct access to the issue without being registered
users.  Also we
> may even go one step further and have multiple keys
that provides
> multiple levels of access.

Possibly for some installations, but that has never proved
to be  
useful for us. Remember that the way we use this is almost
as an  
alternative to email. Rather than having an email
conversation, we  
will have a conversation in the task tracking system. So,
the process  
is this:

1. customer sends an email to mantiscompany (or to support who  
redirect it to mantis)
2. mantis accepts the email, creates a bug with the
appropriate details
3. mantis sends a confirmation email which includes in the
footer the  
passwordless login URL for this bug
4. developers (us) fix the problem, require more info, etc
and add a  
note to the task. This causes an email to go to the customer
with  
that note. Again, it has the link in the footer. This allows
them to  
read the history of the task without having to get an email
with  
dozens of notes quoted in it.
5. The customer replies to the email and their reply gets
added to  
the task notes.
etc.

I added some notes to http://www.man
tisbt.org/wiki/doku.php/ 
mantisbt:reporting_via_email already.

>
>>> Customers can
>>> click on the link to be taken directly to the
appropriate task, see
>>> the (public) notes and history and make another
note. It is very
>>> important (for us) that this page be highly
customised. We want only
>>> a subset of fields (for instance we don't want
them to know who is
>>> assigned to the task, or what priority we
decide to set it) and we
>>> want a page design which looks pretty.
>>
>> I think we can add to this a really minimal
companion page for
>> submitting new issues
>
> The problem with allowing submit is that we will have a
new issue in
> the system without a proper reporter. We can associate
this with a
> common user, but we won't have the email of the user so
that we can
> get feedback and answers to questions.  This will be
like enabling
> submit for anonymous.

This isn't really a problem for us in our current system.
Yes, it is  
submit for anonymous and what we do is record the email
headers in  
the first note. I know you guys are really sensitive to spam
 
problems, but in all our years this has never been an issue
for us,  
perhaps because there is little to be gained by spamming our
task  
tracking system which has no public web site.

I think it is important to associate the task with '[no user
 
assigned]'. That way a user (us) can go in, create the user
in the  
system if needed, and assign the task to them. Usually this
happens  
because a known user reported with a different email
address.

Remember this feature is not just about users who are not
registered  
in the system. It is also to give them an easy way to look
at the bug  
history without logging in.


> It would be great if we can consolidate in this in the
Wiki page for
> this feature.  Anyone up to it?


Yes, me. Since we have this feature working already (and in 

production for over 5 years) I think I can explain it pretty
well and  
try to describe some of the potential problems. Give me a
couple of  
days.


Ari Maniatis




-------------------------->
ish
http://www.ish.com.au
Level 1, 30 Wilson Street Newtown 2042 Australia
phone +61 2 9550 5001   fax +61 2 9550 4001
GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E
3E49 102A



------------------------------------------------------------
-------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and
take
control of your XML. No limits. Just data. Click to get it
now.
http://sourcefor
ge.net/powerbar/db2/
_______________________________________________
mantisbt-dev mailing list
mantisbt-devlists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mantisbt-d
ev