View Issue Details

IDProjectCategoryView StatusLast Update
0022745mantisbtfeaturepublic2017-04-21 02:51
ReporterfmanAssigned To 
PrioritynormalSeverityfeatureReproducibilityN/A
Status newResolutionopen 
Product Version2.3.1 
Target VersionFixed in Version 
Summary0022745: Grant Access in VIEW mode (Read Only) 'skipping' user threshold
Description

I will try to explain why this feature can be useful presenting my current installation:

  1. Mantis was installed 15 years ago, and is used to track development tasks and user issues.
  2. Mantis has been upgraded to 2.1.0
  3. I've 1200 projects (we use a lot project/subproject structure) and more than 50 developers, with a total user population of 200 users.
  4. We user PRIVATE PROJECTS, then developers are added/removed according needs.

Some times user need to access an issue on a project he/she is not assigned, and this is not possible.

IMHO it will be a good thing if users can skip project authorization checks using a simple criteria like: all users with email in domain xxxxx.yy (where xxxxx.yy in my situation will be our company domain), can access issues no matter PROJECT VIES STATUS and/or ISSUE VIEW STATUS.

I've done a hack (not a good one) that implement this, but I think a better implementation will be useful.
Unfortunately I was not able to understand how to implement this as a plugin.

Hope my explanation is not so confusing.

Thanks for this great product

TagsNo tags attached.

Relationships

related to 0003444 confirmed Add user groups to streamline user management 
related to 0022203 assignedcommunity Public / external access to tickets by unique URL 
related to 0006758 feedback Access level for users authenticated via LDAP determined by LDAP group membership 

Activities

atrol

atrol

2017-04-19 10:12

developer   ~0056618

Is this 0022203 what you need?

fman

fman

2017-04-19 10:31

reporter   ~0056619

First, thanks a lot for your quick answer. I'm sorry I was lazy enough to do not search before reporting.
I'm going to give a look.
I will try to explain better: a use case can be:

  1. user is logged on Mantis
  2. user has an issue number
  3. he/she put the issue number on the search issue box.
  4. user is NOT ENABLED TO access the project where issue belongs, but instead of receive message "Access Denied", he/she access to full issue information (view page) in READ ONLY Mode.

Right now my hack does not allow this, user will access with full rights, this means he/she can change the issue, but this is not really a drawback (at least IMHO) because issue history will record actions and author.

Hope now is a little bit clear.
The idea (may be silly) is to avoid all the administration work needed to add/remove users, in addition to all mail user receive when is part of a project (OK he/she can configure this)

Best regards

atrol

atrol

2017-04-19 17:23

developer   ~0056625

he/she put the issue number on the search issue box.

That means that another user sent him/her the issue number to have a look at the issue. Right?

Instead of the issue number, 0022203 allows to send a so called Public Share Url 0022203:0055198
This is nothing more than the issue number and a access token.

Also related 0006758 where a user implemented access level driven by LDAP group.

0022203 and 0006758 are certainly not exactly what you want, but might help some way.

fman

fman

2017-04-19 17:48

reporter   ~0056626

Last edited: 2017-04-21 02:49

View 2 revisions

Thanks again for your help.

That means that another user sent him/her the issue number to have a look at the issue. Right?

Not really, the user can get the issue number when looking to commit logs on git, then IMHO is easier just get the number and put on the search box on mantis, than have th public share url.
As I've explained I've a solution up & running because I've modified a function (right now I do not have the code to check) on the access_api file, but of course this means I need to apply changes at any mantis update.
May be the custom function mechanism can do the trick but do not know if can be applied on access_api
I'm going to give a look to 0006758, anyway I think 0022203 can be useful for other uses.

My intention was to have something that require no configuration (I suppose if/when user groups will be supported may be this can be another solution).

Issue History

Date Modified Username Field Change
2017-04-19 10:01 fman New Issue
2017-04-19 10:12 atrol Status new => feedback
2017-04-19 10:12 atrol Note Added: 0056618
2017-04-19 10:31 fman Note Added: 0056619
2017-04-19 10:31 fman Status feedback => new
2017-04-19 17:23 atrol Note Added: 0056625
2017-04-19 17:48 fman Note Added: 0056626
2017-04-21 02:49 atrol Note Edited: 0056626 View Revisions
2017-04-21 02:51 atrol Relationship added related to 0003444
2017-04-21 02:51 atrol Relationship added related to 0022203
2017-04-21 02:51 atrol Relationship added related to 0006758