Understanding porjects/users/categories

Get help from other users here.

Moderators: Developer, Contributor

Post Reply
demarcao
Posts: 2
Joined: Nov 19, 2018 9:44 am

Understanding porjects/users/categories

Post by demarcao » Nov 19, 2018 9:59 am

Is there a document someplace that gives examples of how to roll out mantis, various scenarios?

I have several distinct development groups that I would like to use this with. Each group has their own set of developers and projects.
So someone from group A only sees group A projects/issues. But each group has their own set of projects and the projects do not overlap groups.

I have been reading through various postings and am confused as to how to best lay this out.

Thank you in advance,

- Alex

Starbuck
Posts: 180
Joined: Feb 13, 2006 9:53 pm
Location: USA
Contact:

Re: Understanding projects/users/categories

Post by Starbuck » Nov 24, 2018 4:10 pm

Looks like there was no answer here so I'll take a crack at it...

Summary:
- Projects can have SubProjects
- Users are assigned to Projects
- Categories can be assigned to Projects
- Tickets can be auto-assigned to a single user identified in a Category

When a ticket is created for a category, the responsible manager can get that first, and then re-assign to someone in their team.
A question there becomes: How do we limit the list of people that can be assigned?
In Product Management there is a list of Accounts=Users who can be assigned to the project. So the assignment options will be limited to people authorized for that project and to anyone in the global access list.

You can create an internal master project for each team, just for organization. Then for any new project, go to Manage Accounts and select Copy Users From that project.

So visibility across projects is limited to those with global access.

I would probably make a high level project/product for each team and then created sub-projects for anything related to them. You need to test this but it's possble that a sub-project inherits the access list from its parent. That sounds like exactly the solution you want.

If your teams are really separate, then consider a different Mantis instance for each team. I don't think that's a good idea here but I'm tossing it out. I think you Do want the benefit of a single user list and probably some other details. This would imply shared tables in a database, shared files (with hard links or bindings). That seem to me to be a fragile environment but someone here might propose a solid way for that to work.

I'll also suggest a FOSSy option. It sure sounds like you have a Lot of development resources there. Any of them know PHP? You could ask for volunteers to help with maintenance of this fine free tracker that you're using. Ask them to create plugins that solve specific challenges that you have there. They can find help and examples on this site, in the docs, the wiki, and in GitHub. Give them something for their effort. Contribute the new plugins back to this project. Everyone wins.

Any help?

Good luck.
If you want Mantis to work differently, use or create a plugin. Visit the Plugins forums.
Ask developers to create a plugin that you need - and motivate them to help you!

demarcao
Posts: 2
Joined: Nov 19, 2018 9:44 am

Re: Understanding porjects/users/categories

Post by demarcao » Nov 27, 2018 10:08 am

thank you... yes this helps...

Post Reply