View Issue Details

IDProjectCategoryView StatusLast Update
0005933mantisbtfeaturepublic2005-08-22 12:36
Reportertoddpw Assigned To 
Status newResolutionopen 
Product Version1.0.0a3 
Summary0005933: thoughts on public vs. private projects, subprojects, and bug view status usage

First let me start by saying that mantis is SO CLOSE to what I have been searching for for years, I can almost taste it. I am amazed that somebody finally "gets it" and really focuses on everyday usability instead of simply providing all the bullet items and then drifting towards bloat.

I just converted all my issues to private tonight so we could take advantage of the view private thresholds, and the sudden appearance of little lock icons everywhere confused some of my users. Some thoughts on the whole interplay of public vs. private, subprojects, and bug view status usage:

Additional Information
  1. Default bug view status (and btw MANY of your global settings) would be very nice if they could be set/overridden on a per project basis. Then again, maybe this policy decision is important enough to be even more visible, for instance having four "types" of projects: public, protected, private, secure -- where public & private mean bugs are normally public, and protected & secure mean bugs are normally private.

  2. Could there be an "exposed" icon counterpart for the lock icon, and only display them when the view status of the bug does not match the default view status of the project it is in. Or perhaps display both all the time. I would want to set this display policy for an entire installation and not allow it to be overriden; others may disagree.

  3. If I allow reporters to handle issues, but don't allow them to view private issues, then a private issue lets me assign the bug to reporters BUT I get a failsafe "access denied" page. Why can't it let me grant temporary viewing rights to the assignee since we have decided their participation is needed. I have a real usage case right now where a project manager asked me why we couldn't do this. She's going to solve it by temporarily adding those people to her project.

  4. It would be nice if we could control the viewing threshold for public bugs too. I want to allow general signup BUT if somebody we don't know discovers our mantis page, I don't want them to see much until a manager adds them to a project or an admin grants them a baseline access level. So I am going through the drill of trying to prevent "viewers" (heh) from viewing any issues.

  5. I like public projects because we can take advantage of baseline access rights, but then I can't make a bug public and still hide it from new accounts. So it forces me to make all bugs private even when I would rather use the view status to implement need-to-know bugs within a project. I know I can always use a private subproject to accomplish this but then I have yet another user list to keep up-to-date.

  6. Say I want to use mantis to track action items for an org chart hierarchy. Ideally I would create nested subprojects and list the people specific to each level as added users on that project. What's missing is the ability to 'export' users up and down from a project. Automatically adding users to all child projects implements management oversight of the underlings. Automatically adding users to the parent project implements department- or division-wide cross-functional areas. With public projects this provides a lot of transparency with less project administration overhead. With private projects it would be ideal for representing discussions of internal affairs at various levels.

TagsNo tags attached.




2005-07-13 07:54

reporter   ~0010750

oops, I thought the sponsor button was going to take me to a donation page.

Anyway, if you can work some of these ideas into the roadmap, it's certainly worth $100 to me. I wish I had the time to hack and submit patches myself, but I don't because of a 100+ member volunteer organization that I help run which is adopting mantis to track action items and general requests like website updates.