I can't see the logic of this. I'm an admin on my mantis install and over 50% of the bugs are assigned to me. The combo boxes do not give any indication of which users are admins. I would (and have) remove the default "admin" account and replace it with your own account that is assigned admin priveleges anyway.

reopened a Luebbe's request

Comment from Luebbe:

The logic behind this is, that I always distiguish between user and admin accounts. I like to keep admin accounts out of sight of the normal users. I also don't surf the web with root privileges.
If I use mantis, I'm logged in with my user account. If I want to administer something I'm logged in as admin. This way I notice easily if something does not work as a normal user.
It's true that the comboboxes dont't give an indication of which users are admins, but people keep asking me, who "John D" is. "He's not working on the project is he?"
In short:

• I like to separate admins from the rest
• I don't like accounts who are implicitly part of a(ny) project

Greetings

• Lübbe

I prefer to have every user know one password and one account only. I might want more than one admin but I don't want to give them all the same admin account/password. Permission systems should separate authentication from authorization. Authentication is then logging in as yourself using your password. Once I know for sure who you are, I can set up permissions that authorize you to perform appropriate actions. This is much more fine-grained than having one admin account.

I also don't want to have to log in and log out to perform different actions.

That said, you're obviously welcome to have whatever policy you want on your site. The problem is, the current system doesn't prevent you from carrying out the policy you desire - and admin accounts aren't even identified as such. If we were to remove admin accounts from the list that would prevent people such as myself from carrying out the policy /we/ want.

It's for this reason that I object to implementing this request.

I also don't think security-by-obscurity is particularly effective which is what hiding the name of the admin account amounts to - but like I said, the effectiveness of this policy is irrelevant since it prevents another (and arguably more standard) policy from being implemented.

Hi Julian,

I agree with all your points. That makes it a bit difficult to make my points clear :-|.
The admin privileges are just too powerful. That's why I prefer to have as few admins as possible, preferrably one.
I'm just unhappy with admins automatically being part of any project. Imagine you got 5 admins, 20 developers, 100 customers and 30 projects. The admins could be assigned any task from any project, which might be a bit confusing. Currently, if somebody is admin, he's got godlike permissions on any project. If he's manager he is lacking some permissions on a specific project. So what shall I do? Maybe I'd like some people to have godlike permissions on some projects but not even see other projects? Currently I don't see how I can make this work with mantis.
I think an intermediate role between manager and admin permissions can solve the issue.

well, I think managers need to be able to more completely control a project...

Agreed, Managers should be able to:
1) not only add / remove people from projects & reassign their permissions (up to manager level), but also to create new users (Viewer Level).
2) Maybe even delete users that aren't assigned to any project.
3) Add / Remove / Edit categories for their projects
4) Copy categories from / to any of their projects
5) Add / Remove / Edit release / version numbers for projects
6) Add / Remove / Edit definitions / Listbox contents for custom fields

more ideas?

I think there should be a seperation of who is assigned to a project and who can be assigned as a handler for a bug. I mean, having multiple managers and developers in a project causes the BTS to display them all in the combo box (of handler), while in fact managers have nothing to do with resolving the actual bugs. I admit that there may be situations not like this, where managers actually resolve bugs or they at least handle new feature requests, but I think a seperation for these two things would be quite nice to have. Thanks.

Huseyin

edited on: 11-11 02:11

I absolutely agree with Huseyin, it would be great to seperate handlers of a bug and users who involved in project organisation (all kind of users such as reporters, handlers, ..., managers and admins).

I'm also admin as well as developer of our mantis and I didn't want to add an seperate admin account (because than people gets the idea to assign bugs to the admin and this isn't senseful in our case) so I give my user admin rights. The problem is that when upgrading mantis sometimes rights must be changed but I don't recognize the wrong permissions because I have no "normal" developer account. So first the other developers have to recognize problems which I could have recognize long before if I had a developer user.

Maybe we could add an option to the config file if admins should be visible in handler lists or not. Doesn't this fit both sides here?

where does this stand in the road map?

Part of this has already been implemented in 0005341. Administrators can be eliminated from some tasks through configuration (either GUI, or special coding).

A number of the thresholds listed have been added since 0.17.5. I'm not sure that this issue is relevant any more.

ah ok, now you can remove the admin from the 'assign to list'. Is it possible (or even senseful) to set this config on a per-project base? We have some projects where the Manager is also a developer and some where he isn't. Otherwise I would create two accounts, one for the managing activity and one for the developing.

GUI based thresholds are on a per project basis. In the case mentioned, you could downgrade the manager to a developer for that project in the Manage Project pages.

but if i downgrade him, he isn't be able to manage the project anymore. What I asked for, was a per-project threshold for $g_handle_bug_threshold. So that in one project managers are visible in the 'assign to' drop down lists and in other projects only developers are visible for example.

But of course I can set $g_handle_bug_threshold to = array(DEVELOPER) and give the manager/developer person to accounts, one for each role if this isn't possible.

In Mantis 1.2, this can be (partially) achieved by customizing the workflow thresholds:

• Manage -> Configuration -> Workflow Thresholds
• Under 'Handle an issue', uncheck 'administrator'
• Under 'Receive reminders', uncheck 'administrator'
• Click 'Update configuration'

That should remove admins from 'Handler' selection lists, althought they would still be listed in the Reporters