View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0015299 | mantisbt | security | public | 2012-12-16 19:43 | 2013-01-02 02:54 |
Reporter | thraxisp | Assigned To | atrol | ||
Priority | normal | Severity | minor | Reproducibility | always |
Status | closed | Resolution | duplicate | ||
Product Version | 1.2.12 | ||||
Summary | 0015299: Tags exposed between private projects | ||||
Description | With multiple private projects, the list of prospective tags to be added includes tags from all projects, including those that the user has no access to. | ||||
Tags | No tags attached. | ||||
duplicate of | 0009716 | acknowledged | Seperation of tags between projects |
My understanding of tags is that they are global, not project-specific so I would think that the behavior you report is as expected (as long as the tags don't actually provide undue visibility to issues) |
|
In our case, the problem was caught because product names from one private project leaked into another. I could control this with a configuration flag. I would restrict tags to the current project if private, rather than being global. |
|
The problem as I see it, is that the tag table does not contain a project_id field, so I'm not sure how you could differentiate a private / project-specific tag from a global one. Maybe a feature request for a future release including a schema change ? |
|
I was going to infer the project from the bugs the tags are attached to. Having a separate field is a simpler / faster idea. Should this be 1.3 only then? |
|
Then how would you differentiate "global" tags from project-specific ones ?
I think it would be better, yes |
|
Hava a look at the discussion at 0009716 and also the attached patch. |
|