private issue and private note

[thewolf]

Hi,

I think I know what a private project is, but I'm not sure about private issue and private note, I couldn't find anything about them in the documentation.

Can anyone explain what they are for?

Does the private status only affect viewing or also email notification?

Thanks.

[thewolf]

Hi,

Can anyone point me in the right direction to figure out what is the minimum level of access (e.g. developer) to access private bugs and private notes?

Thanks.

[ed]

$g_private_bug_threshold
$g_private_bugnote_threshold

in config_defaults_inc.php

[cemper]

Hi,

thanks, I'm struggeling with this too

my goal is to have a set of (external) developers,
and to only allow them see THEIR bugs assigned

So I would set all bugs to private,
but if I set the "private" level to DEVELOPER, then
all developers could see ALL bugs

I need something like an "view OWN private bugs" privilege

anything like that?

I'm ready to sponsor such feature
see http://www.mantisbt.org/bugs/view.php?id=7673

thanks,christoph

[atomoid]

If you're looking for an alternate solution to the connundrum above and dont want to mess around with a patch:

You can limit developer's access to only thier own assigned bugs in a round-about fashion by creating new subprojects for the developer's aspect of the project and giving them 'developer' access to their subproject, while only giving them 'reporter' access to the parent project (i also have set the config_inc.php switch to limit reporters to their own bugs to make this work). The end result is they can still write bugs to the parent project without having access to anyone else's bugs except those written to their own subproject.


...but yep, the drawback to the method i outlined above is its sort of a pain with a large list of developers, and there is currently no way in Mantis 1.0.6 to filter out sub-projects in a search, and if you use a lot of custom fields you have to recreate the whole listing per subproject since you cant copy custom fields from another project like you can for users and categories, so it would be great if Mantis could be enhanced to be able to set up the permissions per project to have its developers only be able to see bugs that are currently assigned to them (such as a config_inc.php switch "$g_limit_handlers = ON;" to yield "Limit developer access to their assigned and own issues" on the Workflow Thresholds page), to make it easier and more useful for everyone.

[vboctor]

Did you consider having two levels of developers? CONTRACTORS and DEVELOPERS. CONTRACTORS can be assigned issues, but can't see PRIVATE issues. DEVELOPERS can do both.

[cemper]

Hello,

thanks for this tip

I wasn't aware you could create an own group called "Contractors" , at least I don't see that group in my Mantis 1.1.0a2 version

Can you point me to the FAQ/Wiki on that?

thanks!

[vboctor]

Check the following pages in the manual:

- http://www.mantisbt.org/manual/manual.c ... ations.php
- http://www.mantisbt.org/manual/manual.c ... values.php

[juanrestrepo91]

Hi,

thanks, I'm struggeling with this too

my goal is to have a set of (external) developers,
and to only allow them see THEIR bugs assigned

So I would set all bugs to private,
but if I set the "private" level to DEVELOPER, then
all developers could see ALL bugs

I need something like an "view OWN private bugs" privilege

anything like that?

I'm ready to sponsor such feature
see http://www.mantisbt.org/bugs/view.php?id=7673

thanks,christoph

hello anyone been able to solve this, thanks

[vasut]

Any solution for this?

[aavagyan]

If you want solution based on configuration then the closest is to use private projects. You'll have one or more private projects (let's call these 'Internal Projects') where your general staff will have access to all tickets. Externals won't have access to these. You'll also have private project (let's call it 'External Project'), where general staff AND externals will have access to tickets. When you want externals to work on a ticket you move it from the 'Internal Projects' to 'External Project'. At the end, if you like, you can move it back to original project.

If setup above is not fine for you, then of course you can go hacking Mantis - this is not really advisable because with every upgrade you'll have to redo things. If you still like to do something like this let me know - I did something similar some time ago and can point you to the files where change is needed.