Re: More than one user per bug and more than one user per category.

I'm going to follow your instructions, thanks a lot.

On Friday 26 October 2007 17:51, Victor Boctor wrote:
> Hi all,
>
> I am totally in agreement that the addition of support for groups
> would be very useful.  This will allow admins to associate access
> rights to groups, then manage memberships to such groups.  Will also
> allow assigning an issue to a group, or the default handled of a
> category to a group.  If we write a wiki page on this, review, and
> implement it, then I will be happy to integrate it into Mantis core.
>

Good idea.

> However, I am not as convinced that assigning an issue to multiple
> users/groups adds value.  In my mind, if an issue is to be assigned to
> multiple users, then there is no accountability.  In such case, we
> should create child issues with the appropriate scopes and assign them
> to the right resources.

I think that the advantage is in the fact than a group is a association of 
users less dynamic. The people who asked me that functionality at the 
university really need it, but maybe it is not a general case.

>
> A general note,a big patch with multiple features is less likely to
> get integrated compared to smaller ones with separate features.  So as
> much as you can submit the features separately to the bug tracker.
>



It's understandable. I will try to separate this functionality as much as I 
can.


> Checkout the following link for more details:
> http://www.mantisbt.org/wiki/doku.php/mantisbt:howto_submit_patches

usefull :)

>
> Thanks in advance for your contribution.
>
> On 10/26/07, Zuzel Vera Pacheco <zuze-70/qqqu8D0M@xxxxxxxxxxxxxxxx> wrote:
> > I think that we can have both.
> > I'm going to add that functionality to my project. When I have something,
> > I send my changes to the list :) .
> >
> > On Friday 26 October 2007 14:47, James Hanley wrote:
> > > The ability to create groups would be a great enhancement, but having
> > > the ability to assign an issue to multiple users is still important.
> > > I could picture someone wanting to mix groups and users depending on
> > > the issue associated with an issue.
> > >
> > > Quoting Zuzel Vera Pacheco <zuze-70/qqqu8D0M@xxxxxxxxxxxxxxxx>:
> > > > At the moment, I make groups of users using the categories inside the
> > > > projects, but I will think about your comment.
> > > >
> > > > Thanks
> > > >
> > > > On Friday 26 October 2007 13:59, David A. Desrosiers wrote:
> > > >> On Fri, 2007-10-26 at 15:12 +0200, Patrick Schoenfeld wrote:
> > > >> > > The changes consist in permit to have more than one user
> > > >> > > assigned to one issue and more than one user per category. I had
> > > >> > > to do changes in the schema of the database.
> > > >> >
> > > >> > thats a great idea, IMHO. I could use that a lot in our company.
> > > >> > Victor, could this eventually be integrated upstream?
> > > >>
> > > >> A better, and more scalable way to do this, would be to implement a
> > > >> groups system, where you assign a bug to a group, or an individual,
> > > >> for example:
> > > >>
> > > >> Assign to:
> > > >>    | John Smith      |
> > > >>    | Mary Jones      |
> > > >>    | Fred McDonald   |
> > > >>    | Jesse James     |
> > > >>
> > > >>    . ----------------.
> > > >>
> > > >>    | Developers      |
> > > >>    | Marketing       |
> > > >>    | Sales           |
> > > >>
> > > >>    `-----------------'
> > > >>
> > > >> Then you put those users (or other users) into those groups.
> > > >> Whomever solves the issue/bug within that group, has permissions to
> > > >> mark it as resolved, escalate it, or close it.
> > > >>
> > > >> It makes management of the bugs a LOT easier, and also doesn't break
> > > >> when you delete a user who happens to be assigned to a bug (i.e.
> > > >> someone leaves the company).
> > > >
> > > > I
> > > >
> > > > ---------------------------------------------------------------------
> > > >---- This SF.net email is sponsored by: Splunk Inc.
> > > > Still grepping through log files to find problems?  Stop.
> > > > Now Search log events and configuration files using AJAX and a
> > > > browser. Download your FREE copy of Splunk now >>
> > > > http://get.splunk.com/
> > > > _______________________________________________
> > > > mantisbt-dev mailing list
> > > > mantisbt-dev-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx
> > > > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
> > >
> > > ----------------------------------------------------------------
> > > This message was sent using IMP, the Internet Messaging Program.
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc.
> > Still grepping through log files to find problems?  Stop.
> > Now Search log events and configuration files using AJAX and a browser.
> > Download your FREE copy of Splunk now >> http://get.splunk.com/
> > _______________________________________________
> > mantisbt-dev mailing list
> > mantisbt-dev-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx
> > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> mantisbt-dev mailing list
> mantisbt-dev-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx
> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/