0022745: Grant Access in VIEW mode (Read Only) 'skipping' user threshold - MantisBT - Signup temporarily disabled due to spam

ID	Project	Category	View Status	Date Submitted	Last Update

0022745	mantisbt	feature	public	2017-04-19 10:01	2017-04-21 02:51

Reporter	fman	Assigned To
Priority	normal	Severity	feature	Reproducibility	N/A
Status	new	Resolution	open
Product Version	2.3.1

Summary	0022745: 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: Mantis was installed 15 years ago, and is used to track development tasks and user issues. Mantis has been upgraded to 2.1.0 I've 1200 projects (we use a lot project/subproject structure) and more than 50 developers, with a total user population of 200 users. 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
Tags	No tags attached.

atrol 2017-04-19 10:12 developer ~0056618	Is this 0022203 what you need?

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: user is logged on Mantis user has an issue number he/she put the issue number on the search issue box. 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 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 2017-04-19 17:48 reporter ~0056626 Last edited: 2017-04-21 02:49	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).