Project

General

Profile

Actions

Feature #337

closed

Private issues

Added by Nikolay Solakov almost 17 years ago. Updated almost 10 years ago.

Status:
Closed
Priority:
Normal
Category:
Issues permissions
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Resolution:
Duplicate

Description

Hi,
I think it would be great if you implement private issues in redMine.
This is an issue that is viewable only if you have the permission to view private issues and for example the end client
will not see the issues in the company...
If it is possible now in redMine, please tell me how to do it. I don't see a way now...

Thanks!
Regards,
Nikolay


Files

redmine-private_issues.patch (13.2 KB) redmine-private_issues.patch Paul Zubarev, 2009-01-02 04:09
redmine-private_issues.v.0.1.patch (21.4 KB) redmine-private_issues.v.0.1.patch Paul Zubarev, 2009-01-07 22:35
p.patch (1.05 KB) p.patch Wessel Louwris, 2009-01-12 16:57
redmine-private_issues.v.0.1.fix.patch (1.03 KB) redmine-private_issues.v.0.1.fix.patch Paul Zubarev, 2009-01-12 21:18
private_issues.v.0.2.patch (23.4 KB) private_issues.v.0.2.patch Paul Zubarev, 2009-02-01 01:01
private_issues.v.0.3.patch (11.5 KB) private_issues.v.0.3.patch for trunk version (3629) Oleg Volkov, 2010-04-09 14:02
private_issues.v.0.4.patch (70 KB) private_issues.v.0.4.patch Oleg Volkov, 2010-04-09 14:51
private_issues.v.0.5.patch (88.8 KB) private_issues.v.0.5.patch for trunk version (3629) Oleg Volkov, 2010-04-17 09:41
private_issues.v.0.5-0.9.3.patch (84.5 KB) private_issues.v.0.5-0.9.3.patch for version 0.9.3 Oleg Volkov, 2010-04-18 07:51
private_issues.v.0.6.patch (90.3 KB) private_issues.v.0.6.patch for trunk version (3629) Oleg Volkov, 2010-04-20 21:31
private_issues.v.0.6-0.9.3.patch (87.1 KB) private_issues.v.0.6-0.9.3.patch for version 0.9.3 Oleg Volkov, 2010-04-20 21:31
private_issues.v.0.7.patch (78.4 KB) private_issues.v.0.7.patch for trunk version (3629) Oleg Volkov, 2010-04-23 17:10
private_issues.v.0.7-0.9.3.patch (75.4 KB) private_issues.v.0.7-0.9.3.patch for version 0.9.3 Oleg Volkov, 2010-04-23 17:10
private_issues.v.0.7-0.9.3_changes.diff (3.25 KB) private_issues.v.0.7-0.9.3_changes.diff changes made to private_issues.v.0.7-0.9.3.patch Wytze Keuning, 2010-04-28 23:15
private_issues.v.0.7-0.7.1.diff (1.62 KB) private_issues.v.0.7-0.7.1.diff for v.0.7 and v.0.7-0.9.3 Oleg Volkov, 2010-04-29 21:32
errors.txt (11.4 KB) errors.txt Karolina -, 2010-07-16 11:37
private_issues_including_additional_patch_for_issues_count_and_unit_tests_for_redmine_1.0.5.r4569.patch (75.4 KB) private_issues_including_additional_patch_for_issues_count_and_unit_tests_for_redmine_1.0.5.r4569.patch Patch for private issue including correct issue count. To be applied on Redmine 1.0-stable (r4569) Adrien Crivelli, 2011-01-19 10:29

Related issues

Related to Redmine - Feature #1554: Private comments in ticketsClosedJean-Philippe Lang2008-06-30

Actions
Related to Redmine - Feature #3384: issue permissionsClosed2009-05-18

Actions
Related to Redmine - Feature #7412: Add an issue visibility level to each roleClosed2011-01-22

Actions
Has duplicate Redmine - Feature #1491: Show the issuse/board message of other users.Closed2008-06-18

Actions
Has duplicate Redmine - Feature #6336: Privat IssuesClosed2010-09-09

Actions
Has duplicate Redmine - Feature #6923: Roles that allow users to view and comment on only issues they have createdClosed2010-11-17

Actions
Is duplicate of Redmine - Feature #7414: Private issuesClosed2011-01-22

Actions
Actions #1

Updated by Jean-Philippe Lang almost 17 years ago

A patch was proposed for this feature by Jeffrey Jones.
http://rubyforge.org/tracker/index.php?func=detail&aid=10381&group_id=1850&atid=7162

I may integrate it in the future, so any comment is welcome.

Actions #2

Updated by Nikolay Solakov almost 17 years ago

Hello,
I almost convinced my bosses to use redMine in a presentation yeasterday :)
The issue that was on the table with it was exactly these private issues.

The patch proposed by Jeffrey Jones is about internal/external users.

I'm asking now for the ability when reporting issue to make it private for the user who reported it. There has to be a permission for this feature - View others private issues.
redMine is a great innovative tool, and we want to use it as a project management solution, by posting to it not only developers tasks but the jobs of project managers. It suits our organization for now but, the lower levels of the hierarchy should not see the work of the higher level.

I hope you understand me :)
Thanks and regards,
Nikolay

Actions #3

Updated by Jean-Philippe Lang almost 17 years ago

Hi,

I almost convinced my bosses to use redMine in a presentation yeasterday :)

I'm very proud of it :-) Thanks

I understand your need. It's different from internal/external issues.
Instead of adding one more flag on issues, maybe I could implement a common solution:

  • just a "Private" flag on issues
  • a new permission "View private issues" at role level
  • a "No private issue" flag on user accounts

If a user has a role with "View private issues" permission, he will see private issues on the corresponding project.

If a user has the "No private issue" flag checked on his account (not modifiable by himself of course), he won't see any private issue and won't be able to create private issues. It could be set for clients for example.

What do you think ?

Actions #4

Updated by Nikolay Solakov almost 17 years ago

Hi,
I think this is the solution, Jean-Philippe. :)

There is something I don't understand indeed...
What is the meaning of the "No private issues"?
If a user has "View private issues" or just "Private issues" in the role "Clients" for example, maybe he should not be allowed to see and create them... Or I missed something?

Thanks,
Nikolay

Actions #5

Updated by Jean-Philippe Lang almost 17 years ago

It's just to allow a same role to be used for internal and external (eg. client) users, as requested by Jeffrey Jones.

That role could have the "View private issues" permissions, but you can prevent clients who have this role to view private issue by checking "No private issue" on their account.

Actions #6

Updated by Nikolay Solakov almost 17 years ago

Got it, but will it works like the patch Jeffrey proposed?

Because I think the internal/external feature is a whole new solution for redMine, because external users are commonly clients in Trouble Ticketing sistem. Jeffrey made some filtering on assignment of issues to internal/external users etc...
This separation of the users in redMine will make it not only project management and issue tracking, but and trouble ticketing system which on its side is great :)

Thanks,
Nikolay

Actions #7

Updated by Nikolay Solakov almost 17 years ago

Hi,
another thought: when creating an issue and assign it to somebody, there has to be a possibility to make it private for that user, so only he can see it (like the boss assigns tasks for project managers, but the developers are not allowed to see this tasks).
I thinking of a tree, in which the lower level users don't see the issues of higher level users.

Thanks,
Nikolay

Actions #8

Updated by Jeffrey Jones almost 17 years ago

Heh, I will soon be leaving the company I am currently employed at and unfortunately the main drive to install redMine will leave with me. Therefore I can't really give much more information.
Off the top of my head this sounds like it is more complex than a simple user based internal/external separation.

Cheers

RJ

Actions #9

Updated by Marcin Gil over 16 years ago

An idea similar to private issues is, I think, a private task list - so not to clutter "official" trackers.

Each user could be given a simple tracker for his daily tasks/duties.

Actions #10

Updated by Geordee Naliyath about 16 years ago

First of all, Redmine is a great product. I liked the workflow feature and I see enough potential to be customized for purposes other than project management. Only if I could make all issues visible only to certain roles, and for others only their issues are visible.

In my opinion, it would be great if this feature can be enabled as part of permissions - something like "View All Tickets" could be a permission which is set to checked by default. If we uncheck, members with that role can see only their ticket.
That also means, they will not be able to see others issues, activities, calendar, issue summary etc.

I am not sure how difficult the implementation is. I am new to Ruby and trying to figure out how permissions work in Redmine (some hash table?)

The other "issue" is the name "issue". I would have preferred some neutral terms like "ticket".
Anyway, I edited en.yml and changed the word issue to ticket.

Actions #11

Updated by Robert Lemke about 16 years ago

I agree with Geordee - really great software you created there, Jean-Philippe. As you know we recently started using it for TYPO3 (http://forge.typo3.org).

Private issues are also one of the most important features we will need for TYPO3. We have a security team which takes care of any security issues. Currently we track them with Mantis. All security issues are submitted as private issues which only the security team can see.

I propose that a "private" flag can be set for a whole tracker. All issues for that tracker are not visible to the public (but probably to the team members). The question is, how we can give the security team access to all these trackers without having to add each team member to each project. The easiest - but not very clean -solution would be to let all security team members be administrators. But maybe there are alternatives?

Actions #12

Updated by Thomas Lecavelier about 16 years ago

I agree on that point: private issue (this may be called "security issues", too) is a must-have for redmine. Private trackers should be easy to get too.

Actions #13

Updated by Jean-Philippe Lang about 16 years ago

Thanks for your contributions. Here is what I propose:

  • a '_private_' flag on issues (so that the tracker won't be the only way to set an issue as private)
  • a '_view private issues_' permission at role level
  • an additional setting at account level to set the ability of the user to see private issues, with the following options:
    • never: the user can never see any private issue
    • always: the user can see any private issue
    • according to his role: the user only see private issues on projects for which he has a role that is allowed to view private issues

Robert, you could use this option to enable security team users to view any private issues without having to give them a role on all projects.

A flag could also be added at tracker level so that an issue attached to a private tracker is automatically private.
A user should be able to view a private issue if he is its author or assignee, whatever his permissions are.

One more question: who should be allowed to create or set issues as private ?
For example, anyone could be allowed to create private issues but only specific role(s) could be allowed to set an existing issue as private.

What do you think ?

Actions #14

Updated by Nikolay Solakov about 16 years ago

Hi,
Jean-Philippe, all your proposals are pretty enough I think.
Only that:
Robert, you could use this option to enable security team users to view any private issues without having to give them a role on all projects.

I can't get the meaning. If a user is not assigned to a project with a particular role, he don't see any issues in this project (not public project), right?
Then, how he will see the private issues? Am I missing something?

Regards,
Nikolay

Actions #15

Updated by Jean-Philippe Lang about 16 years ago

Nikolay, I was speaking about public projects (which is the case of Robert I think).
Of course, if a project is private, only its members can see it.

Actions #16

Updated by Nikolay Solakov about 16 years ago

Great! I think it's a really good start.

Regards,
Nikolay

Actions #17

Updated by Thomas Lecavelier about 16 years ago

It sounds good to me, too.

Actions #18

Updated by Robert Lemke about 16 years ago

Hi Jean-Philippe,

great to hear that you want to work on that feature. In my opinion all of your proposals make sense and they would certainly satisfy our demands.

One more question: who should be allowed to create or set issues as private ?
For example, anyone could be allowed to create private issues but only specific role(s) could be allowed to set an existing issue as private.

In our case anybody should be able to create private issues and it would be okay if anyone would be allowed to set an existing issue as private. However, I could understand if someone needs the feature that only certain people are allowed to mark existing issues as private. Maybe that shouldn't be an extra feature but rather be determined from the rights someone has to edit a whole issue.

Best,
robert

Actions #19

Updated by Jos Yule about 16 years ago

I'd just like to add my voice to this one too. I will quickly out line our use-case, which i think is covered by the above description that JPL described above.

I have a team which work on a project. There are many non-team members which create new issues (features, bugs, etc). I would like to have the non-team members able to create items, and then the team "update" the items (with notes) which are not viewable by the non-team members.

It would be helpful to have an option to make "updates" private by default.

Thanks

Actions #20

Updated by Thomas Löber about 16 years ago

This could be accomplished by adding a "private" flag to journal entries.

Actions #21

Updated by Jean-Philippe Lang about 16 years ago

  • Target version set to 0.8

Sounds good to me.

Actions #22

Updated by Adrian Bridgett almost 16 years ago

Private bugs are also an issue for us, however our use case is I believe slightly different - I'll put it here in case it's a helpful. As I understand it, what you are proposing above is the ability to restrict certain issues to effectively "superusers" - in case they are sensitive.

Our use case is if we use redmine to track bugs in a product, we would want company Foo to raise bugs and also company Bar to raise bugs in the same project - however whilst Foo could see all bugs Foo had raised, we would not want them to see bugs that Bar had raised (and vice versa). This seems very similar to the proposed solution, but rather than private/not-private it requires the ability to set them private/not-private at a company wide level (to be honest, even if it was limited to "person from Foo who raised the bug and all developers" that'd probably be sufficient).

Thanks - redmine looks very interesting!

Actions #23

Updated by Thomas Lecavelier almost 16 years ago

Adrian, your request concern another matter: user-groups. There's a bunch of feature request about that, like #1018. Once this feature will be implemented, another improvement will be to enable users from a certain group to view restricted/private/security trackers.

Actions #24

Updated by Sepp _ almost 16 years ago

Anoter Idea:
Why not let us use Custom Keywords for that.
Let us specify something like "Use this Keyword as permission"...

It this Keyword-Flag is checked, I can set all things from above like

    * just a "Private" flag on issues
    * a new permission "View private issues" at role level
    * a "No private issue" flag on user accounts

for those Keywords and so, I am much more flexible...

I can name Keywords: Internal, externals Developer, High security team, ....

Actions #25

Updated by Thomas Lecavelier almost 16 years ago

I just imagine the mess with keywords: this issue went just private. Imagine all the other issue that become private without warning. Sound funny :)

Actions #26

Updated by Thomas Kauders almost 16 years ago

YES, PLEASE! There is a need for some way to hide certain issues from the customer. We use Redmine for tracking our software developemnt project. Not all issues are for the customer to be seen.

Simply make a checkbox "Private" which will make the issue invisible for customers.

Actions #27

Updated by Karl DeBisschop almost 16 years ago

I sort of like the idea of keywords. Yes there is some complexity there, but its generality just seems naturally appealing to me. More so than coding a hodge-podge of private/public, personal/non-personal, internal/external, financial/non-financial, and so on.

I can also think other levels of access. For instance, in our shop the developers would never want to prevent the user from seeing the internal of what we do, they generally don't want to. It would be nice to be able to hide developer tickets from non-technical staff by default, but allow them to choose to see them if the want.

Actions #28

Updated by F T over 15 years ago

We are using Redmine for internal purposes. We would like to see "Private tickets" as Nikolay Solakov described them: a user should be able to see only its own reported tickets.

P.S. I opened issue #1491 asking same thing than I found this. Sorry.

Actions #29

Updated by Thomas Lecavelier over 15 years ago

P.S. I opened issue #1491 asking same thing than I found this. Sorry.

Duplication relation marked, #1491 closed. Thank you for pointing it out.

Actions #30

Updated by Ewan Makepeace over 15 years ago

I dont think all the different posters on this page are talking about compatible use cases (or at least the proposal being proposed by Jean-Philippe Lang will solve some users problems but not others). One of the blissful things about Redmine is that so far it achieves so much out of the box with a 'lightness of being' - it is not weighed down by hundreds of modes, options and checkboxes. What I am worried will happen here is that this proposal will be implemented, but will only silence 50% of the requests so then further layers of control get put on top until you end up with a Lotus Notes-esque multi layered security model nobody can understand...

Here are some real life scenarios as far as I can tell from the discussion:

A - Customer vs Customer

Acme CAD systems wants to collect bug reports from clients Boeing and Airbus, but clients should not be able to see each others issues.

B - Internal vs External

Acme Banking Systems wants to let the customers have access to file and track issues but dont want them to see issues found by the QA/QC team during development.

C - Internal vs Internal

Apple computer want the general development team to work on outstanding issues but keep new features tightly controlled and visible to key developers only.

The proposed solution (private flag and associated permissions) is too blunt to solve all these needs - it marks some issues as private and then grants some roles the ability to see private issues. This will solve the goal of B above (since internal roles will be senior to external roles) but will be a problem for A and C because they are peer to peer type access control problems (although clearly there are workarounds).

Perhaps instead we could implement user groups (as requested elsewhere... ) as collections of users. Allow issues to have project visibility or group visibility (perhaps have a group field and if null visibility is default). Neatly partitions access within the members of a project and separately from role. Works great where multiple clients exist in the same project ect. Completely backwards compatible.

Actions #31

Updated by gabriel scolan over 15 years ago

I think the group visibility is great.
But just keep in mind that when a new bug/feature is raised, "someone" need to setup the visibility for each group; this could be a long uninteresting work, and shall be reserved to some people (Project Leader for example) ... So depending on the cases you've presented above, default visibility should be automatically setup.
For example,
- when Boeing open an issue, everyone can see within ACME (or some groups only), excepts the one registered as Airbus.
- when an issue is open internally, everyone can see it within ACME (or some groups only), and customers can not see them.

To summarize, a configuration panel shall exist per group to determine the default visibility to set up to the other groups in case one member of a group raises an issue.

Actions #32

Updated by Ewan Makepeace over 15 years ago

Good points. To properly suggest an answer I need to solicit feedback on another question first. If Groups get implemented should they be exclsuive or not (ie can I belong to multiple groups?).

If groups are exclusive they are fairly easy to implement - when adding members to a project there would need to be an additional column group. A project member could be assigned to 0 or 1 groups. Alternatively groups could be a global attribute (same across all projects) in which case users would be assigned to a group from the user admin screen.

Either way you could set a project level flag: Default Issue Visibility: <Group | Project>

Then all new issues created by anyone would default to the group that person was a member of if:

  1. That user was in a group (group not null)
  2. That project had a default visibility of Group

On the other hand if Groups were implemented in a more flexible way where any user could be a member of any number of groups then it gets harder because the above logic would not work. I am having difficulty thinking of a fooproof mechanism in that scenario.

Actions #33

Updated by Thomas Lecavelier over 15 years ago

Ewan Makepeace wrote:

If Groups get implemented should they be exclsuive or not (ie can I belong to multiple groups?).

From my POV, exclusive groups are just useless: they could be replaced by a system of credential copy. Of course, non-exclusive groups are far harder to implement, since we have to define rules of precedence between groups rights, but that's the only way to get powerfull right management.

Actions #34

Updated by Marc Liyanage over 15 years ago

Am I right in assuming that the original patch by Jeffrey Jones from 2007-04-30 no longer works? It seems the source code has changed quite a bit since then, the patch won't apply anymore.

Did anyone ever update it? It would make a nice stopgap until private tickets in 0.8 are available...

Actions #35

Updated by F T over 15 years ago

Sorry for noise in your mbox but, please, any update about this topic?

Actions #36

Updated by Jean-Philippe Lang over 15 years ago

  • Target version changed from 0.8 to 0.9.0
Actions #37

Updated by Paul Zubarev about 15 years ago

Jean-Philippe Lang wrote:

Thanks for your contributions. Here is what I propose:

  • a '_private_' flag on issues (so that the tracker won't be the only way to set an issue as private)
  • a '_view private issues_' permission at role level
  • an additional setting at account level to set the ability of the user to see private issues, with the following options:
  • never: the user can never see any private issue
  • always: the user can see any private issue
  • according to his role: the user only see private issues on projects for which he has a role that is allowed to view private issues

Robert, you could use this option to enable security team users to view any private issues without having to give them a role on all projects.

A flag could also be added at tracker level so that an issue attached to a private tracker is automatically private.
A user should be able to view a private issue if he is its author or assignee, whatever his permissions are.

One more question: who should be allowed to create or set issues as private ?
For example, anyone could be allowed to create private issues but only specific role(s) could be allowed to set an existing issue as private.

What do you think ?

Hi!

I have compared openSource systems like SourceForge (Savanah, GForge, RedMine) and I think that Redmine is the best among them. As to me I am necessary to have the private issues, I have made a patch for 0.8.0-release(30/12/2008). I have included two kinds of permissions on my decision:
  1. Add private issues permission
  2. View private issues permission

These permissions can be added in any of roles under Redmine.

P.S. I am a newbe in Ruby and Ruby on Rails.

Actions #38

Updated by Eric Davis about 15 years ago

Paul Zubarev wrote:

As to me I am necessary to have the private issues, I have made a patch for 0.8.0-release(30/12/2008).

Thank you for the patch. I've only had a change to read the code but I have a couple of questions:

  1. Are there unit and functional tests to support the patch? With a feature like this, I'd trust the code more if there were tests to make sure the issues were displayed properly.
  2. Does this patch affect the Activity page also? If a user doesn't have permission to see an issue, then they shouldn't see any updates on their Activity page
  3. Similar to above, does this patch affect the Atom feeds?
Actions #39

Updated by Paul Zubarev about 15 years ago

Eric Davis wrote:

Thank you for the patch. I've only had a change to read the code but I have a couple of questions:

  1. Are there unit and functional tests to support the patch? With a feature like this, I'd trust the code more if there were tests to make sure the issues were displayed properly.
  2. Does this patch affect the Activity page also? If a user doesn't have permission to see an issue, then they shouldn't see any updates on their Activity page
  3. Similar to above, does this patch affect the Atom feeds?

You are absolutely right. I will change a patch and I will improve my errors within the next few days.

Actions #40

Updated by Paul Zubarev about 15 years ago

Eric Davis wrote:

  1. Are there unit and functional tests to support the patch? With a feature like this, I'd trust the code more if there were tests to make sure the issues were displayed properly.
  2. Does this patch affect the Activity page also? If a user doesn't have permission to see an issue, then they shouldn't see any updates on their Activity page
  3. Similar to above, does this patch affect the Atom feeds?

I have made the new version of a patch with support private issues in Activity page and Atom feeds.
This patch include unit and functional tests for private issues.

Actions #41

Updated by Wessel Louwris about 15 years ago

I have made the new version of a patch with support private issues in Activity page and Atom feeds.
This patch include unit and functional tests for private issues.

I tried this patch on the current svn trunk (0.8.0.devel.2261).

Patching lib/redmine.rb failed, apparently in current trunk the :destroy_attachment was removed from line 38.

I attached a working patch file for redmine-0.8.0/lib/redmine.rb

Actions #42

Updated by Guillaume Lecanu about 15 years ago

Hi everybody,

Redmine is a very great app ! Thanks to everyone you have help to have this project so good.
We want to move from Mantis to Redmine, but there is this missing feature that make us some problems.

I would like to know if Redmine will permit to make visible a ticket only for some specified users (or role) ?

We have 3 kind of roles : client, freelance, admins(us)

When a client ask us a feature, we create a ticket only visible between us and the freelance.
After the negociation price with the freelance, we create a ticket only visible between us and the client.

Do you think this will be possible in Redmine ?

Thanks

Actions #43

Updated by Wessel Louwris about 15 years ago

Wessel Louwris wrote:

I have made the new version of a patch with support private issues in Activity page and Atom feeds.
This patch include unit and functional tests for private issues.

btw: the patch works great and was just what we needed. Hope it get's implemented in someway in the trunk sometime. Thanks!

Actions #44

Updated by Wessel Louwris about 15 years ago

Guillaume Lecanu wrote:

Hi everybody,

Redmine is a very great app ! Thanks to everyone you have help to have this project so good.
We want to move from Mantis to Redmine, but there is this missing feature that make us some problems.

I would like to know if Redmine will permit to make visible a ticket only for some specified users (or role) ?

We have 3 kind of roles : client, freelance, admins(us)

When a client ask us a feature, we create a ticket only visible between us and the freelance.
After the negociation price with the freelance, we create a ticket only visible between us and the client.

Do you think this will be possible in Redmine ?

Thanks

The redmine-private_issues.v.0.1.patch from Paul Zubarev in this thread provides a 'Add private issues' and 'View private issues' right which you could assign to roles. But that would not be sufficient in your situation it seems, since you have 2 kinds of private.

Actions #45

Updated by Guillaume Lecanu about 15 years ago

Wessel Louwris wrote:

The redmine-private_issues.v.0.1.patch from Paul Zubarev in this thread provides a 'Add private issues' and 'View private issues' right which you could assign to roles. But that would not be sufficient in your situation it seems, since you have 2 kinds of private.

Thanks for your help Wessel Louwris.
Do you know if there is another way where I could do this negociation in private but into Redmine ?
I have read there is a new rights managements for the Wiki, or may be by creating a Forum with the good rights perms ?

Actions #46

Updated by Paul Zubarev about 15 years ago

I have checked this patch on http://osll.spb.ru and see that it contains a little bug. This bug is described on http://osll.spb.ru/issues/show/3 . I will fix it soon.

I have a question: how patch can be added in redmine trunk?

Actions #47

Updated by Paul Zubarev about 15 years ago

This patch fixes my mistake in version 0.1 (:
You shoud patch the file redmine/app/controllers/projects_controller.rb that has been patched early by redmine-private_issues.v.0.1.patch

Actions #48

Updated by Stanislav German-Evtushenko about 15 years ago

It's very necessary feature!

  • I tried the patch and took an error then user have no permissions to view private issues (http://localhost:3000/projects/show/test2):
    SQLite3::SQLException: no such column: false: SELECT count(DISTINCT "issues".id) AS count_all, tracker_id AS tracker_id FROM "issues" LEFT OUTER JOIN "projects" ON "projects".id = "issues".project_id LEFT OUTER JOIN "issue_statuses" ON "issue_statuses".id = "issues".status_id LEFT OUTER JOIN "trackers" ON "trackers".id = "issues".tracker_id WHERE (((projects.id = 2 OR projects.parent_id = 2) AND issues.private = false) AND issue_statuses.is_closed='f') AND (projects.status=1 AND (projects.is_public = 't' or projects.id IN (1,2))) GROUP BY tracker_id
    Problem has gone when I comment single line
    # issue_cond += " AND #{Issue.table_name}.private = false"
    in app/controllers/projects_controller.rb
  • I think owner must able to see own tasks.
Actions #49

Updated by Stanislav German-Evtushenko about 15 years ago

In addition: I'm using sqlite3 db.

Actions #50

Updated by Paul Zubarev about 15 years ago

Are you have private field in issues table in your database? Maybe you have forgotten execute rake db:migrate RAILS_ENV="your_environment".

Actions #51

Updated by Stanislav German-Evtushenko about 15 years ago

I have this one. I found some about this problem http://snippets.dzone.com/posts/show/2086.

In addition:
  • It will be useful to able set default state (private or not) for new issue for any project separately.
Actions #52

Updated by Paul Zubarev about 15 years ago

  1. I have fix problem with sqlite3.
  2. If user adds private issue, he will be able to browse his issue even if he does not have view_private_issue permission.

This patch for 0.8-stable svn branch.

Actions #53

Updated by Greg Burri about 15 years ago

I think it should be possible for a given ticket to define a set of user or user group which can access to this ticket. Set to All by default.

A role permission should be also added : Access to all ticket. It permits to bypass the access rights. Only used for project admin.

Actions #54

Updated by Sepp _ about 15 years ago

Why not add this feature the same way as you did with watchers. It should simply be possible to define groups.
Adding Groups for watchers would be a nice feature too...

Actions #56

Updated by Javier Barroso about 15 years ago

When I test http://www.redmine.org/attachments/1473/private_issues.v.0.2.patch with redmine 8.1, I can't see project pages, this exception is launched:

Mysql::Error: #42S22Unknown column 'issues.private' in 'where clause': SELECT count(DISTINCT `issues`.id) AS count_all, tracker_id AS tracker_id FROM `issues`  LEFT OUTER JOIN `projects` ON `projects`.id = `issues`.project_id  LEFT OUTER JOIN `issue_statuses` ON `issue_statuses`.id = `issues`.status_id  LEFT OUTER JOIN `trackers` ON `trackers`.id = `issues`.tracker_id WHERE (((projects.id = 9 OR projects.parent_id = 9)) AND issue_statuses.is_closed=0 AND issues.private=1) AND (projects.status=1)  GROUP BY tracker_id 
/opt/gems-1.8.6/gems/activerecord-2.1.2/lib/active_record/connection_adapters/abstract_adapter.rb:147:in `log'

Should #48 patch be added to the 0.2 patch ?

Actions #57

Updated by Thomas Pihl about 15 years ago

There is a migration in the patch, so do a rake db:migrate as well.

/T

Actions #58

Updated by Shaun Gilroy almost 15 years ago

So I applied the 'private_issues.v.0.2.patch' patch to my development version of the 0.8.3 and I noticed something...

You still get emails if you belong to the project and have your preferences set to send emails for all projects you're involved in, regardless of your permissions.

This doesn't seem right...

Actions #59

Updated by Javier Barroso almost 15 years ago

Hi,

We would like apply this patch in trunk, is there any notice about ?

Regards,

Actions #60

Updated by Justin Grevich almost 15 years ago

I am also looking to apply this patch asap. I have been holding off since it looks like it will be merged with the trunk pretty soon. Is there any update on that?

Thanks,

justin

Actions #61

Updated by Jose Luna almost 15 years ago

My company is also in need of a way to hide issues based on a specific criteria. As Ewan points out, many of the suggested solutions are to solve a specific use case, leaving many other desired use cases unsolved. A more generalized approach is necessary.

I propose that a new feature be implemented that allows users to define their own permissions for viewing tickets. This feature would be analogous to the filter on the /issues page (in fact, the interface would be nearly identical). The admin would be able to define a new permission filter based on the same set of criteria available in the issue filters. For example, the admin may select the criteria:

 Assigned to is <<me>>
 Tracker is Bug
 Target version is [1.0]

The admin can save this "permission filter" and assign it to a specific role. Like normal issue filters, this would work on custom fields. So you could add a "private" custom field that is binary, if all you need is private vs. non-private permissions. I would imagine that custom fields in the permission filter would have to be limited to custom fields that are marked "For all projects" and "Used as filter".

The Cons

  • The user will be affected by the current limitations that are in the issues filter. For example, what if I want to filter for all tickets that are priority "Normal" AND priority "High". (Note: I think this can easily be addressed by making improvements to the filtering.)

The Pros

  • The approach is very flexible, and can be used to solve all use cases described so far.
  • Much more complex permission systems can be created using this solution.
  • It could be made possible to assign a permission filter to a user, not just a role.
  • I am not familiar with the Redmine source (or Ruby for that matter), but it seems as though much of the code for this proposed feature is already written. The developer would be adapting existing code that has already been heavily tested.

Let me know if there are any more pros/cons that I'm missing.

Actions #62

Updated by Jens Goldhammer almost 15 years ago

In my eyes, it is important to finally have this feature in redmine. I don´t understand why the patch of Paul is not already integrated into the core as a first step. Maybe later there is time for the more generic solution of Jose.

Actions #63

Updated by Tiago Queirós over 14 years ago

Paul Zubarev wrote:

  1. I have fix problem with sqlite3.
  2. If user adds private issue, he will be able to browse his issue even if he does not have view_private_issue permission.

This patch for 0.8-stable svn branch.

With this patch (in 0.8-stable) the atom feed from the issues tab still displays the private issues the users shouldn't be alllowed to see according to the permissions set on the roles.
Any tips on where I should start to debug this problem?

Also in the project overview it also shows the number of current private issues to the user.
Is this intended?

Actions #64

Updated by Tiago Queirós over 14 years ago

Tiago Queirós wrote:

Paul Zubarev wrote:

  1. I have fix problem with sqlite3.
  2. If user adds private issue, he will be able to browse his issue even if he does not have view_private_issue permission.

This patch for 0.8-stable svn branch.

With this patch (in 0.8-stable) the atom feed from the issues tab still displays the private issues the users shouldn't be alllowed to see according to the permissions set on the roles.
Any tips on where I should start to debug this problem?

Also in the project overview it also shows the number of current private issues to the user.
Is this intended?

I get the same behaviour in the export to CSV and PDF features of the Issues Module.
It exports everything, including the private issues.

Actions #65

Updated by Bruno Medeiros over 14 years ago

Shaun Gilroy wrote:

...
You still get emails if you belong to the project and have your preferences set to send emails for all projects you're involved in, regardless of your permissions.

This doesn't seem right...

I can confirm that it does really occurs. I have this patch applied to Redmine 0.8.2 and people that don't have permission to see private tickets are receiving emails from private tickets changes and comments if they mark to "send emails for all projects you're involved in".

I would love to help you, but I'm a noob in rails.. All I can do is report that! :)

Private tickets is a really great and useful feature and I think the way this patch implements it is a good way, That could be better in the future.
With this email issue and the Atom issue resolved, I think its mature enough to be integrated with Redmine trunk and come in the first 0.9 stable release.

Thanks for Paul for the patch and all others for the feedback and ideas!

Actions #66

Updated by li wei over 14 years ago

I have patched redmine-private_issues.v.0.1.fix.patch. Following is private_issues patch's some defects:
  • The private issue's Assigned member should be able to view the private issues.
  • Watchers should also have permission to view tasks.
  • Recommended to increase the csv & PDF export's access control function.
Actions #67

Updated by Redmine Fan over 14 years ago

I am using a test installation of 0.8.5. I am a bit confused about the various comments here.
Is there a better version of the private issues being worked on for 0.9, or is it going to be
the patch being integrated into the trunk.

Also, which file should I use for applying the patch as there are several on this page. Sorry
for any novice comments

Actions #68

Updated by Bruno Medeiros over 14 years ago

Redmine Fan wrote:

I am using a test installation of 0.8.5. I am a bit confused about the various comments here.
Is there a better version of the private issues being worked on for 0.9, or is it going to be
the patch being integrated into the trunk.

This patch will be integrated into the trunk as soon as it's mature enough. As I can see, we still have some problems in this feature. Below is a list of current problems (sorry if i forget something):

  • "People that don't have permission to see private tickets are receiving emails from private tickets changes and comments if they mark to "send emails for all projects you're involved in"". (Shaun Gilroy and Me)
  • "The atom feed from the issues tab still displays the private issues the users shouldn't be alllowed to see according to the permissions set on the roles." (Thiago Queiróz)
  • "I get the same behaviour in the export to CSV and PDF features of the Issues Module." (Thiago Queiróz)
  • "The private issue's Assigned member should be able to view the private issues." (li wei)
  • "Watchers should also have permission to view tasks." (li wei)

Also, which file should I use for applying the patch as there are several on this page. Sorry
for any novice comments.

The file is private_issues.v.0.2.patch. I've applied here in Redmine 0.8.2 and everything is ok. (Except for the known issues above)

I hope someone could solve this minor issues and integrate this patch into trunk ASAP.
Thanks!

Actions #69

Updated by Pablo 09 over 14 years ago

I tried to apply on Redmine 0.8.5 (current trunk) and i have a error when i want to see private issues

NameError in Issues#show
Showing app/views/issues/show.rhtml where line #1 raised:
undefined local variable or method `private' for #<Issue:0xb59008fc>

Application Trace
/usr/lib/ruby/gems/1.8/gems/activerecord-2.3.4/lib/active_record/attribute_methods.rb:260:in `method_missing'
/home/redmine/app/models/issue.rb:271:in `visible?'
/home/redmine/app/views/issues/show.rhtml:1:in `_run_rhtml_app47views47issues47show46rhtml'
/home/redmine/app/controllers/issues_controller.rb:119:in `show'
/home/redmine/app/controllers/issues_controller.rb:118:in `show

What can i do?

Actions #70

Updated by Ho Nguyen over 14 years ago

Hi redmine-ers, pls anyone confirm when this feature is available for the trunk e.g. 9.0? This feature is really necessary ... thanks.

Actions #71

Updated by Yaroslav Shvetsov over 14 years ago

Ho Nguyen wrote:

Hi redmine-ers, pls anyone confirm when this feature is available for the trunk e.g. 9.0? This feature is really necessary ... thanks.

Yes, approve request for this feature.

Actions #72

Updated by Stanislav German-Evtushenko over 14 years ago

I think issue #2653 is better way to separate clients from each other than "Private issues". Private issues will involve some chaos to project management.

Actions #73

Updated by Bruno Medeiros over 14 years ago

Stanislav German-Evtushenko wrote:

I think issue #2653 is better way to separate clients from each other than "Private issues". Private issues will involve some chaos to project management.

I think they're not the same think. I my company, for example, it's not a internal/external user problem. We use private tickets to avoid all (even internal users) to see tickets that have private information.

If someone will use this to 'separate clients from each other', putting all internal tickets as private, I agree with Stanislav. It will be a big chaos.

I believe both solutions could be applied, couldn't they?

Actions #74

Updated by Stanislav German-Evtushenko over 14 years ago

Bruno Medeiros wrote:

Stanislav German-Evtushenko wrote:

I think issue #2653 is better way to separate clients from each other than "Private issues". Private issues will involve some chaos to project management.

I think they're not the same think. I my company, for example, it's not a internal/external user problem. We use private tickets to avoid all (even internal users) to see tickets that have private information.

If someone will use this to 'separate clients from each other', putting all internal tickets as private, I agree with Stanislav. It will be a big chaos.

I believe both solutions could be applied, couldn't they?

I think you right.

Actions #75

Updated by Tadeusz Zimirski over 14 years ago

Another concept (or: a short summary of the above ideas) which hopefully covers all the use cases mentioned above + one case I recently heard of (from a friend to whom I recently recommended redmine). A non-software company has external users who should be able to view issues which were explicitly made available to them but no other issues (no project-wide rights, only per-issue viewing rights). Security is a concern.

I'm not familiar with redmine code.

There is some similarity to multiple user assignment, but this idea is related more to data security/access control than the workflow.

1. Project-wide settings: Private Issues, Watchers and Editors
  • enable private issues (if disabled, no point in specifying Private Editors an issue in the project)
  • are new issues private by default?
  • when security is a big concern: to prevent mistakenly revealing too much information to outsiders: all issues of this project are locked to private (only private issues allowed in the project and its subprojects?)

2. Add permissions under "Issue tracking"

  • View Private Issues
  • Become a Watcher - Only project participants with this permission will appear in the UI control (list?) which allows to add Watchers to an issue. Watchers of a given private issue can see it listed or see its details although they have no View Private Issues right. Implementing explicit permission to Become a Watcher is not a must, but would add security (prevent mistakenly authorizing a third party to view a private issue).
  • Implement the permissions of an Editor in a similar fashion: Edit Issues is already present, to be added: Become an Editor of an Issue, Add Editors, Show Editors List, Delete Editors
3. Specifying access rights when creating/editing issues
  • Issues can be made private or visible to all participants (public) by the creator (or editor with relevant permissions)
  • If the issue is made private, creator / editor of the issue selects users (or groups) as Watchers and Editors (UI controls only becoming visible when you check the private checkbox, unless it's on by default)
4. Hidden updates, especially for hiding attachments
  • When updating an issue, specify whether Watchers of this issue can see the update (i.e. you want to upload a file not for Watchers' eyes. Could be useful if you want outside Watchers to track progress of your work, but not access too much data (i.e. documents you create).

5. Allow groups to be specified as Watchers and Editors

If all 5 of the above are implemented, then this should cover all the cases mentioned in this discussion (including Guillaume Lecanu's case with freelancers and clients). It would also remedy some but not all of the concerns of people who requested assign to multiple users. Still, Jose's idea is very appealing as well.

Sometimes you will want to
  • specify access rights project-wise, like using a filter by the admin in Jose's idea or using few pre-determined access rights in the above idea.
  • specify access rights on a per-issue basis (especially important when security is a concern and very little info should be made available to users automatically).

I think the per-issue aspect is something easier dealt with in the above case (although I'm not sure - not a redmine dev myself). It is of course also possible in Jose's permissions-like-filters idea. It could probably be implemented using the same 'engine' as the rest of permissions-like-filters, but the filters concerning individual issues should also have UI options in create/edit issue screens. The individual, per-issue filters should probably be hidden by default from the admin permissions-like-filters interface (there could be v. many of them)

What do you think?

Actions #76

Updated by Tadeusz Zimirski over 14 years ago

in short:

  • A project can have Private Issues enabled -> then the users can select if a given issue is private
  • A project can have Private Issues forced -> then all issues are private
  • Private Issues can be viewed/edited by users with View Private Issues or Edit Private Issues permissions. Other users can view/edit if they were added as a Watcher / Editor of the particular issue.
  • Groups of users can be specified as Watchers or Editors of private issues.
  • Hidden Updates to a private issue (and their attachments) would be hidden from the Watchers

Some projects will mostly use user or group permissions to control access, projects with tight security will force private issues and use explicit issue-level permissions to grant access (Watchers and Editors lists for issues)

Actions #77

Updated by Thomas Oppelt over 14 years ago

Is there for now a workaround or simple solution to allow private issue setting for owner, assigned to and watchers resp. groups?
Similar to basecamp, simple checkbox.
We really need that.

thx & regards

Actions #78

Updated by Aron Rotteveel over 14 years ago

This would be a great feature, also making Redmine more usable as a customer ticketing system.
We currently use OTRS for our supportdesk, but the interface and translation is incredible lacking.

The only two features that would be needed for us in this case are:

  • Trivial: support of per-user signatures
  • Important: private ticketing.

In this case, I can image creating a public project for "general" company wide support. I'd then setup an e-mailadres to point to this project, making all e-mail conversations private to the user.

Actions #79

Updated by Jean-Philippe Lang about 14 years ago

  • Target version changed from 0.9.0 to 1.0.0 (RC)

This feature has to wait for some refactoring of the access control to tickets, that should occur for the next stable release.

Actions #80

Updated by Mischa The Evil about 14 years ago

  • Category set to Issues permissions
Actions #81

Updated by Mike Heininger about 14 years ago

Jean-Philippe Lang wrote:

This feature has to wait for some refactoring of the access control to tickets, that should occur for the next stable release.

Would be great if this would then also make Feature #1554 (Private comments in tickets) possible.

Thanks for all your work!

Actions #82

Updated by carlos Jimenez about 14 years ago

Hello
I have a problem with privacy in Redmine.
I have the version 0.9 Stable. When trying to update private_issues.v.0.2.patch (23.4 KB) Paul Zubarev, 2009-02-01 01:01 gives me errors. Not find the routes.
Someone can help me? I need users can not see the information between them.
How do I install the PATCH?
I await your response.

A greeting

Actions #83

Updated by Edward Stone about 14 years ago

Hi Carlos,

Unfortunately that patch is against a pretty old version of redmine, as far as I can tell, and won't work against the current version. Unless your knowledge of ruby is pretty good, you'll need to wait until this feature is in a release, which isn't scheduled until version 1.0, due in about 4 months (http://www.redmine.org/projects/redmine/roadmap)

cheers

Ed

Actions #84

Updated by Sergey Belov almost 14 years ago

I'm adapting this patch to 0.9.3 and have few problems because I'm new to Ruby and redmine.
Could anybody look at this forum thread - http://www.redmine.org/boards/2/topics/12717

Thanks

Actions #85

Updated by Oleg Volkov almost 14 years ago

For patch v.0.2:

sed 's/visible/visible_private/'

TODO: Watchers should also have permission to view tasks.

Actions #86

Updated by Oleg Volkov almost 14 years ago

You used the patch v.0.2, except the file app/models/issue.rb
I combined the two "visible?" in one.

--- redmine_3629/app/models/issue.rb    2010-04-08 12:11:59.000000000 +0400
+++ redmine/app/models/issue.rb    2010-04-09 12:34:08.702249117 +0400
@@ -74,8 +74,9 @@
   after_destroy :update_parent_attributes

   # Returns true if usr or current user is allowed to view the issue
-  def visible?(usr=nil)
-    (usr || User.current).allowed_to?(:view_issues, self.project)
+  def visible?(usr=User.current, project=self.project)
+    is_private==false && usr.allowed_to?(:view_issues, project) ||
+    is_private==true && (usr.allowed_to?(:view_private_issues, project) || author == usr || watched_by?(usr))
   end

   def after_initialize
@@ -204,6 +205,7 @@
     category_id
     assigned_to_id
     priority_id
+    is_private
     fixed_version_id
     subject
     description

Actions #87

Updated by Oleg Volkov almost 14 years ago

New version patch supported:
1. Private issue view only for
- all, with "View private issues"
- author
- assigned to
- wathes
2. Create private issue
- all, with "Add private issues"
3. Create non private issue
- all, with "Add issues"
4. Create privat/non privat issues
- all, with "Add issues" and "Add private issues"
5. Edit privat flag (for issue)
- all, with "Add issues" and "Add private issues" and "Edit issues"

Actions #88

Updated by li wei almost 14 years ago

Oleg Volkov wrote:

New version patch supported:
1. Private issue view only for
- all, with "View private issues"
- author
- assigned to
- wathes
2. Create private issue
- all, with "Add private issues"
3. Create non private issue
- all, with "Add issues"
4. Create privat/non privat issues
- all, with "Add issues" and "Add private issues"
5. Edit privat flag (for issue)
- all, with "Add issues" and "Add private issues" and "Edit issues"

 ActiveRecord::StatementInvalid in ProjectsController#show

Mysql::Error: Unknown column 'issues.is_private' in 'where clause': SELECT count(DISTINCT `issues`.id) AS count_all, tracker_id AS tracker_id FROM `issues`  LEFT OUTER JOIN `projects` ON `projects`.id = `issues`.project_id  LEFT OUTER JOIN `issue_statuses` ON `issue_statuses`.id = `issues`.status_id  LEFT OUTER JOIN `trackers` ON `trackers`.id = `issues`.tracker_id WHERE (((projects.id = 1 OR (projects.lft > 1 AND projects.rgt < 120))) AND issue_statuses.is_closed=0 AND issues.is_private=1)  GROUP BY tracker_id 
Actions #89

Updated by Oleg Volkov almost 14 years ago

Add database migration file, add field on all language.

Actions #90

Updated by Oleg Volkov almost 14 years ago

In new version:
- Add tests
- Add field "Private Issue" for CSV export
- Minor changes

INSTALL:
1. get trunk (3629)
2. patched
3. rake db:migrate

New version patch supported:
1. View private issues available for:
- all, with "View issues" and "View private issues"
- author, with "View issues"
- assigned to, with "View issues"
- watchers, with "View issues"
2. The creation of private issue
- all, with "Add private issues"
3. The creation of non private issue
- all, with "Add issues"
4. Creating any issues
- all, with "Add issues" and "Add private issues"
5. Changing status "Private Issue" (in editing issue form)
- all, with "Add issues" and "Add private issues"

Actions #92

Updated by Sergey Belov almost 14 years ago

Have tested trunk 3629 with this patch.
Works like charm. Passed all tests

Actions #93

Updated by Bruno Medeiros almost 14 years ago

Some month ago I collected all problems i found on this patch:

  1. "People that don't have permission to see private tickets are receiving emails from private tickets changes and comments if they mark to "send emails for all projects you're involved in". (Shaun Gilroy and Me)
  2. "The atom feed from the issues tab still displays the private issues the users shouldn't be alllowed to see according to the permissions set on the roles." (Thiago Queiróz)
  3. "I get the same behaviour in the export to CSV and PDF features of the Issues Module." (Thiago Queiróz)
  4. "The private issue's Assigned member should be able to view the private issues." (li wei)
  5. "Watchers should also have permission to view tasks." (li wei)

Are these problems still present? It seems that Oleg fixed 3, 4 and 5. Can someone that's using the patch confirm? Let's keep these problems status to help some developer to merge this patch into trunk ASAP.

Thanks for all!

Actions #94

Updated by Oleg Volkov almost 14 years ago

I corrected all the problems. Please test my patch and write the problems that really have.

Actions #95

Updated by Oleg Volkov almost 14 years ago

In new version:
- Add "Private Issue" to filter in issues list
- Fix Atom, CSV and PDF export in issues list
- Minor changes

Actions #96

Updated by Oleg Volkov almost 14 years ago

Bruno Medeiros wrote:

Are these problems still present? It seems that Oleg fixed 3, 4 and 5.

Patch v.0.6 is free from problems 1-5.

Actions #97

Updated by F T almost 14 years ago

Any chances to see this patch included in main prior 1.0.0? In 0.9.5 for example.

Thanks.

Actions #98

Updated by Holger Just almost 14 years ago

Definitely not. See ReleaseManagement.

Actions #99

Updated by Sergey Belov almost 14 years ago

This is not a big patch and was tested a lot. Patch has new tests and passes all redmine exists tests.
So, why not include it into 0.9.4?

Actions #100

Updated by Oleg Volkov almost 14 years ago

Patch requires migration of the database, so it does not include in 0.9.x.

Actions #101

Updated by Oleg Volkov almost 14 years ago

Optimize code.
Fixed:
- pagination issue list
- visibility issue page in the xml / atom / pdf representations

Actions #102

Updated by Juraj Soft almost 14 years ago

We need to limit visibility of Issue just for creator and envolved people.

Possible solution:
It could be possible to set new permission Create Private only.

How it could work:
If user have role with this permission, every new issue will be private and such user can not change the private flag (e.g. will be not visible for him).

Now private issue is ok for such use:
  • Issue is visible for Reporter (enabled Create Private only)
  • Issue is visible for Developer (enabled View private issues)
  • Two different reporters DON'T see each other issues.

Nice work, Oleg.
Thanx

Actions #103

Updated by Sergey Belov almost 14 years ago

Juraj Soft,

Just set permission to add private issues and remove add normal issue
Then user will create private issue by default.

Private issue is visible for creator, assigned to and watchers

Actions #104

Updated by Oleg Volkov almost 14 years ago

Operation "Add issue" "Add private issue" "Edit issue"
Can not create any issue no no any
Create only non-private issue yes no any
Create only private issue no yes any
Create any issue yes yes any
Change the status of a private issue (when editing) yes yes yes
Operation "View issue" "View private issue"
Can not view issue no any
View non-private issue yes any
View any private issue yes yes
View created private issue yes no
View assigned private issue yes no
View watching private issue yes no
Actions #105

Updated by Oleg Volkov almost 14 years ago

Permission Non-private issue Created private issue Assigned private issue Watching private issue Other private issue
Unset "View issue" Not view Not view Not view Not view Not view
Set "View issue" and unset "View private issue" View View View View Not view
Set "View issue" and set "View private issue" View View View View View
Actions #106

Updated by Stanislav German-Evtushenko almost 14 years ago

I seem there is some confusion with the "private" meaning here.
Let there are two people: A (issuer) and B (supporter). "A" create new issue with "private" option and assing that task for "B". "A" think that issue is shown only for him and for "B" but really it's shown for A,B,C,D,F,etc, who have permissions to view "private" issues. There is some confuse here.
It would be nice to rename "private" issues to "hidden" issues or something like that.

Stas

Actions #107

Updated by Wytze Keuning almost 14 years ago

Private issues are visible on the project overview even without the "View private issues" privilege. My test project is public. I added three issues, one of them is marked as private. Only I have the "View/Add private issues" privilege. Our guest user, who has the "View Issues" privilege and no other privileges, can see two (the non-private) issues. On the project overview page he can also see there is one more issue, a private one.

Incident: 3 open / 3 (1 private)

Actions #108

Updated by Oleg Volkov almost 14 years ago

So conceived.

Actions #109

Updated by Stanislav German-Evtushenko almost 14 years ago

  • Assignee set to Thomas Lecavelier

Wytze Keuning wrote:

Private issues are visible on the project overview even without the "View private issues" privilege. My test project is public. I added three issues, one of them is marked as private. Only I have the "View/Add private issues" privilege. Our guest user, who has the "View Issues" privilege and no other privileges, can see two (the non-private) issues. On the project overview page he can also see there is one more issue, a private one.

Incident: 3 open / 3 (1 private)

As I think Oleg meant that's a feature not a bug.

Actions #110

Updated by Stanislav German-Evtushenko almost 14 years ago

  • Assignee deleted (Thomas Lecavelier)
Actions #111

Updated by Stanislav German-Evtushenko almost 14 years ago

However I seem it quite strange.

Actions #112

Updated by Wytze Keuning almost 14 years ago

Thanks. I did interpret "so conceived" as "by design". ;) But why was this "conceived" that way? Why am I allowed to see that there are private issues if I'm not allowed to view private issues? The same does not apply for public/private project does it? People who are not added to a private project will never know of it's existence. Shouldn't the same rule be applied to issues?

Actions #113

Updated by Oleg Volkov almost 14 years ago

We see only the number, names and contents are not visible.

Actions #114

Updated by Wytze Keuning almost 14 years ago

Oleg Volkov wrote:

We see only the number, names and contents are not visible.

True. But why? If I'm not allowed to view the issue, should I know of it's existence? Would the following solution (if at all possible) not be more appropriate:

Example:
Users with the "view private issue" will see: Incident: 3 open / 3 (1 private)
Users without the "view private issue" will see Incident: 2 open / 2

Actions #115

Updated by Sergey Belov almost 14 years ago

Oleg started to adapt patch v0.2 made by Paul Zubarev for redmine 0.8.x version.
This patch has this changes and that nobody was complained we decided to keep it as is. Because user only see number of private tickets, but can't see a list of this tickets or any other details

Actions #116

Updated by Oleg Volkov almost 14 years ago

The project has the total number of issues, the user can view a smaller number of issues.
If you do not have status "view private issue" he can still see some particular issues.

Actions #117

Updated by Wytze Keuning almost 14 years ago

Oleg, thansk for your reply.

I made some changes to the patch you submitted. Basically for my own usage since I don't like the idea that our customers, who have a basic "view role", can see (some) issues are hidden for them. The way I see this is: only users with the correct privilege (view_private_issues) should be able to see totals including private issues. Therefore I changed "/redmine/app/controllers/projects_controller.rb" and "/redmine/app/views/projects/show.rhtml". I included my changes as a diff to your pacth so that you can decide for yourself if you like these changes. I did some basic testing and it seems to work the way I described it; however; since I'm new to redmine and ruby, I might have missed something.

To summarize; I added the following functionality:

- only users with the "view_private_issues" privilege will see issue totals including private issues in the project overview.
- users without this privilege will see totals minus private issues.

I will add: private_issues.v.0.7-0.9.3_changes.diff

Actions #118

Updated by Sergey Belov almost 14 years ago

Oleg,

It looks as reasonable changes. I was thinking about this issue, but it's fine for me as is.
I don't think we should count private issues which you can see (created by or assigned to you). And just check "view_private_issues" privilege as Wytze suggested

What do you think?

Actions #119

Updated by Michael Sanders almost 14 years ago

I have done my best to keep up with this conversation, although it is spanned over the period of 3 years, so it is really difficult to be able to read ALL of it.

Has a solution been proposed to being able to restrict non-members and anonymous from initially reporting/creating issues as well as solving the problem of allowing them to change many fields at their user-level, including the problem this very Redmine has with people potentially assigning bugs, changing priority, assigning the issue to a version, changing the date, and work remaining

We want to publicize our Redmine much like the Redmine running on this website. However, we do not wish people to be able to do those things mentioned above when they create an issue, or it potentially requires too many cases in which the project managers have to do A LOT of oversight.

Any insight into this would help a lot, if it can already be done, that would be great.

Actions #120

Updated by Oleg Volkov almost 14 years ago

Fixed Activity list on user's page (like /user/1). But unfortunately it's hot-fix and not the best solution.

Actions #121

Updated by Jean-Philippe Lang almost 14 years ago

  • Target version changed from 1.0.0 (RC) to 1.1.0

As discussed today at the meeting, private issues will be part of 1.1 release.

Actions #122

Updated by Sergey Belov almost 14 years ago

Jean-Philippe,

Sorry, I was not on this meeting, why was it moved to 1.1 instead of 1.0? This functionality is necessary for many people

Actions #123

Updated by Michael Sanders almost 14 years ago

I agree with Sergey, that it is amazingly necessary.
Although it is good that it is at least on the roadmap.

Actions #124

Updated by Oleg Volkov almost 14 years ago

Simple patch #2653

Actions #125

Updated by Sergey Belov almost 14 years ago

Oleg found other patch/issue which is much easier to program and understandable by user that this "private issue". I'm using this new patch and it more interesting.

It will work even for old issues and don't need db migration

issue is #2653

Take a look. Oleg submitted patch to this issue.
I would like to say a BIG thanks to Oleg to working on some issues!

Actions #126

Updated by yannick quenec'hdu almost 14 years ago

Sergey Belov wrote:

Jean-Philippe,

Sorry, I was not on this meeting, why was it moved to 1.1 instead of 1.0? This functionality is necessary for many people

+1 to integrate this feature into release 1.0

Actions #127

Updated by F T almost 14 years ago

+1 for 1.0

I can't believe this will be postponed again.

Actions #128

Updated by marcob marcob almost 14 years ago

+1 for 1.0 -- or, at least, please add a few details on the reasons of postponing it again,
since it seems a highly requested, well documented, quite tested feature at this point.

Actions #129

Updated by Razi Baluchi almost 14 years ago

Wondering if anyone has come across this error:

Applied patch to 0.9.3 and did a DB:Migrate - no errors, however when attempting to view issue lists I get:

SELECT count(DISTINCT "issues".id) AS count_all FROM "issues"  LEFT OUTER JOIN "issue_statuses" ON "issue_statuses".id = "issues".status_id  LEFT OUTER JOIN "projects" ON "projects".id = "issues".project_id WHERE ((issues.status_id IS NOT NULL) AND (issues.assigned_to_id IN ('14')) AND (projects.status=1 AND projects.id IN (SELECT em.project_id FROM enabled_modules em WHERE em.name='issue_tracking') OR issues.is_private=0 OR issues.author_id=11 OR issues.assigned_to_id=11 OR issues.id IN (SELECT watchers.watchable_id FROM watchers WHERE watchers.watchable_type='Issue' AND user_id=11)) AND projects.id IN (1) AND projects.status=1 AND projects.id IN (SELECT em.project_id FROM enabled_modules em WHERE em.name='issue_tracking'));
ERROR:  operator does not exist: boolean = integer
LINE 1: ...ERE em.name='issue_tracking') OR issues.is_private=0 OR issu...
                                                             ^
HINT:  No operator matches the given name and argument type(s). You might need to add explicit type casts.

Creating works fine.

DB is PostGresSQL 8.3

Actions #130

Updated by Razi Baluchi almost 14 years ago

looks like PostgresSQL expects "f" or "t" for boolean values

changed "is_private=0" to "is_private='f'" and "is_private=1" to "is_private='t'" in app/models/query.rb and it seems to be working

Actions #131

Updated by Jack Hong over 13 years ago

Razi Baluchi,

Would change 'is_private=0' to 'is_private is true' be more 'sql standard'?

Actions #132

Updated by Oleg Volkov over 13 years ago

I tested patch #337 with MySQL.

Note the patch #2653 does not require changes to the database.

Actions #133

Updated by Anonymous over 13 years ago

I found a bug in this patch (v0.7). Suppose the following: a person (XYZ), who has privileges to "View Issues" but not to "View private issues", is member of a project which has some Administrator's users. These Administrators are solving issues in this project, but all of them in private. The expected is that XYZ shouldn't be able to access these issues, right?
Ok, then... If our person clicks in "Issues" tab in the project, nothing is displayed: alright! But if this person clicks in "Overview" tab, and then in the name of any Administrator, it will be redirected to this user's page. In this page, on the "Activity" part, the person will be able to see the names, status and comments of the issues, even though clicking on them will redirect to an Forbidden Access page...

Any idea/patch to fix it?
Thanks in advance!

Actions #134

Updated by Oleg Volkov over 13 years ago

Sorry, I do not support this patch.
I recommend using # 2653.

Actions #135

Updated by Anonymous over 13 years ago

The problem in #2653 (for my needs, of course) is that I need many clients, with "View private issues" access, and they MUST see each others issues (so they don't duplicate them). This (#337) is still better to what I need, but maybe I'll have to take some Ruby classes and try to submit a patch myself :)

Actions #136

Updated by Oleg Volkov over 13 years ago

Differences: 337 can control the visibility for each task individually, 2653 - no.
Различия:337 позволяет управлять видимостью для каждой конкретной задачи индивидуально, 2653 - нет.

Actions #137

Updated by Karolina - over 13 years ago

Can you help me to install this patch?
I have redmine v 0.9.3.
I download private_issues.v.0.7-0.9.3.patch
I try to do:
patch -p0 < private_issues.v.0.7-0.9.3.patch
but I have got lots of errors (logs in attachment).
I'm not a programer an I dont know what to do with them, but I would love to have this patch.

Actions #138

Updated by Oleg Volkov over 13 years ago

cd /patch/to/redmine/home/dir
patch -p1 < /patch/to/file/private_issues.v.0.7-0.9.3.patch

Actions #139

Updated by arthur me over 13 years ago

I applied this patch to http://redmine.rubyforge.org/svn/tags/1.0.0
This applied pretty well- some of the localization files had rejections. The only important one was in lib/redmine.rb. The rejection is:

***************
*** 52,57 ****
                                    :queries => :index,
                                    :reports => [:issue_report, :issue_report_details]}
      map.permission :add_issues, {:issues => [:new, :update_form]}
      map.permission :edit_issues, {:issues => [:edit, :update, :reply, :bulk_edit, :update_form]}
      map.permission :manage_issue_relations, {:issue_relations => [:new, :destroy]}
      map.permission :manage_subtasks, {}
--- 52,59 ----
                                    :queries => :index,
                                    :reports => [:issue_report, :issue_report_details]}
      map.permission :add_issues, {:issues => [:new, :update_form]}
+     map.permission :add_private_issues, {:issues => [:new, :update_form]}, :require => :loggedin
+     map.permission :view_private_issues, {}, :require => :member
      map.permission :edit_issues, {:issues => [:edit, :update, :reply, :bulk_edit, :update_form]}
      map.permission :manage_issue_relations, {:issue_relations => [:new, :destroy]}
      map.permission :manage_subtasks, {}

I manually did the change and things work after running rake db:migrate RAILS_ENV="production". I haven't tested extensively, but just a report for people running on 1.0

Actions #140

Updated by Oleg Volkov over 13 years ago

arthur me, see #2653.

Actions #141

Updated by arthur me over 13 years ago

Hi Oleg-
I read through the thread on #2653 and from my understanding of the functionality on that thread this was more what I was looking for- the note at the top of #2653 indicates that these are different approaches- perhaps I misunderstand?

If this functionality is being covered completely in #2653, should the feature be updated to indicate this?

Also, thank you Oleg for writing this patch- this is a critical piece of functionality for a possible migration to redmine!

Actions #142

Updated by Oleg Volkov over 13 years ago

Patches are different in that #337 allows you to tag individual tasks as private.
#2653 - can only manage privileges.
This #2653 is made easier and more qualitative.

Actions #143

Updated by Tim Vazquez over 13 years ago

I added this patch to 1.0 and when you add or update an issue the is_private column does not get updated. If I edit the database by hand, the issue is hidden. What file handles the addition to the databse?

Actions #144

Updated by Tim Vazquez over 13 years ago

Looking at the logs with a debug level, I can see the Parameters are set correctly "is_private"=>"1", but in the "Issue Create" entry the value of "is_private" is 0. at what point are the parameters pass to the SQL statement and what could I have missed when using the last patch?

Actions #145

Updated by Jean-Jacques Mérillon over 13 years ago

Please don't postpone this features anymore. I really need it.

Actions #146

Updated by Ве Fio over 13 years ago

You guys really already have the necessary path work to implement it too, don't delay, people can use this!

Actions #147

Updated by Ве Fio over 13 years ago

patch work*

Actions #148

Updated by Eric Davis over 13 years ago

  • Target version changed from 1.1.0 to Unplanned backlogs

I need a few things before this feature could be reviewed:

  1. I can't tell which patch is valid. Many of them are are missing a description and appear as partial patches.
  2. Several patches are using a "redmine/" prefix. Please create a patch at the root of Redmine.
  3. I don't see any tests in these patches. With a feature this large and one that affects data visibility, there must be tests to cover all of the new code and possible edge cases.

Once these concerns are addressed, then it would be possible to review this patch and see about adding it to Redmine.

Another thing to keep in mind: the patch proposed here is different that what Jean-Philippe Lang wants to do with private issues:

# From logs at http://www.redmine.org/wiki/redmine/TeamLeadMeeting0
jplang: the patch in 337 is not what I want to do with private issues
jplang: we need to share issues between groups of users
edavis10: Khalsa: yea, bugmash'ing includes tracker cleanup
jplang: not just can see / can not see private issues
rchady: the changes to properly implement private issues will be fairly far reaching and have a lot of impact
rchady: Trying to squeeze it in to a release is just a bad idea
Actions #149

Updated by Maciej Czub over 13 years ago

Is there a chance to put a higher priority on this feature? I know many people who claims that lack of this one functionality keeps them from migration to Redmine. I understand that list of features waiting for solid implementation is long, but this one is critical - just ask anybody.

Actions #150

Updated by Ве Fio over 13 years ago

Eric, I understand where you're coming from, I really do, but there must be some way to work this issue out and get it done faster, while still maintaining a solid implementation. As the person before me said, it should be higher priority, and this feature alone would get more people to use this software thus making it more popular, which is what every software always needs. (:

Actions #151

Updated by Felix Schäfer over 13 years ago

Oh for Christ's sake, I'm really getting tired of people having the impression we are sitting on our hands and not giving sh*t about this issue. Breaking news: we do care, and we know it's important to a lot of people. This just in: There's over 2300 other open issues, some of them structural and deep-reaching which would make implementing this thing here "now" one more thing to take care of (and potentially break backwards compatibility of) when those changes are made.

Ве Fio wrote:

but there must be some way to work this issue out and get it done faster

To put it bluntly: part of the hold-up here is JPL, if you can get him to either admit he has no time/interest in taking care of a developer community and hand over control to someone(s) else, or to fork over the work he has already done and which we are somewhat waiting for here so that others can pick it up, or to just drop the ball on this one and tell us that he won't get said work out in any foreseeable period of time so that Eric/we can implement something else, then yes, it could speed things up.

Oh, and I forgot the classics: fork the project, have someone maintain the patches in your installation, and so on…

</rant> (oh, and before flames redmine for having unfriendly devs or whatever: those are my opinions and mine only, though I'm quite certain they reflect to some degree those of most other people working on redmine too)

Actions #152

Updated by Ве Fio over 13 years ago

I'm really getting tired of people having the impression we are sitting on our hands and not giving sh*t about this issue. Breaking news: we do care, and we know it's important to a lot of people. This just in: There's over 2300 other open issues, some of them structural and deep-reaching which would make implementing this thing here "now" one more thing to take care of (and potentially break backwards compatibility of) when those changes are made.

I'm sorry if I made it out to seem like you guys are doing nothing, that was not the intention. :) Just to let you know, I really do understand.

oh, and before flames redmine for having unfriendly devs or whatever: those are my opinions and mine only, though I'm quite certain they reflect to some degree those of most other people working on redmine too)

Not at all, I understand that dealing with loads of people requesting every which-way of things can get frustrating at times.

Actions #153

Updated by Pedro Gutierrez over 13 years ago

Please Felix, don't take it this way.
Redmine is the best thing I've seen in years and you guys are doing a great job evolving it in a solid way. And I'm not the only one who thinks you're doing a great job.

Sorry if we insist too much in new features. I think it is merely an expression of happy users interested in improving Redmine even more but whithout the necessary technical skills to contribute in the development. Of course, this also means that your audience goes far beyond Ruby programmers; and this by itself is also an important achievement... that produces headaches from time to time ;-)

Some call this: success

BTW +1

Actions #154

Updated by Oleg Volkov over 13 years ago

Patch #337 is too complex for inclusion in redmine, and Eric did not include never, no matter how many tests I have not written to him. But why not include the patch #2653, which is clear and simple - I do not understand.

Actions #155

Updated by F T over 13 years ago

Please, do not put this issue in a planned release anymore until you are more than sure to include it.

Thanks for your work.

Actions #156

Updated by Felix Schäfer over 13 years ago

Be, Pedro: my rant wasn't directed at anyone in particular, and I got carried a little away, but thanks for the kind words anyway, I hope they'll reach the people who deserve them more.

Actions #157

Updated by Pedro Gutierrez over 13 years ago

F T wrote:

Please, do not put this issue in a planned release anymore until you are more than sure to include it.

Thanks for your work.

I second this. I've made a number of promisses on the basis that this feature was to be addressed by december version and now...

Actions #158

Updated by Loïc Juillerat over 13 years ago

Pedro Gutierrez wrote:

I second this. I've made a number of promisses on the basis that this feature was to be addressed by december version and now...

Same for me.

Actions #159

Updated by Eric Davis over 13 years ago

To anyone who made promises about a feature:

You will have to talk to Jean-Philippe about that, he was the one who originally assigned it to a release before there was any code. You will need to be very careful about making promises based on planned releases, anyone with a user account can assign the Target Version. I'd recommend what I do with all of my clients:

"No promises until the feature is closed and the code has been committed"

I'm sorry if this affected you but Redmine is 100% volunteer driven. If someone has an emergency or needs a break, they have every right to take that time for themselves.

And on the other hand; if things don't happen how you want, you can step up and help Redmine out. We are more than happy to have some help.

If you want this feature added, I gave 3 things that need to be done in my last comment and posted the larger context about where this feature fits into Redmine.

Actions #160

Updated by Stanislav German-Evtushenko over 13 years ago

Eric Davis wrote:

To anyone who made promises about a feature:

You will have to talk to Jean-Philippe about that, he was the one who originally assigned it to a release before there was any code. You will need to be very careful about making promises based on planned releases, anyone with a user account can assign the Target Version. I'd recommend what I do with all of my clients:

"No promises until the feature is closed and the code has been committed"

I'm sorry if this affected you but Redmine is 100% volunteer driven. If someone has an emergency or needs a break, they have every right to take that time for themselves.

And on the other hand; if things don't happen how you want, you can step up and help Redmine out. We are more than happy to have some help.

If you want this feature added, I gave 3 things that need to be done in my last comment and posted the larger context about where this feature fits into Redmine.

Eric, could you say anything about #2653?

Actions #161

Updated by Bruno Medeiros over 13 years ago

Eric, is there a chance to include #2653 instead of this? As Oleg said above, it's clear and simple. I have an instance of Redmine (v. 1.0.1) running with that patch, and it's working very well. It doesn't cover all #337 does, but cover almost everybody's needs.
Is it possible?

Actions #162

Updated by Eric Davis over 13 years ago

Lets take the conversation of #2653 over to that issue. I might be able to review it but I'm in a middle of launching a book about Redmine so my time is a bit short ;)

Actions #163

Updated by Th LAPLG over 13 years ago

Hello,

I think it would be a pity to implement user restrictions on issues this way : THERE IS MUCH BETTER TO DO !
With solution below we could say RedMine can be used also by support teams, customers,... of a company.
I am an old user of o tool called "CODENDI" (Support and customer collaborativ tool) that deals perfectly with visibility and permissions on issues, it is simple and very well done.
There is a permissions tab in administration of a tracker :

Permissions on fields of tracker :
for each field of the tracker you can choose its visibility in a small menu :
"Can be set by all users"
"Can be seen by all users"
"Can be set by registered users"
"Can be seen by registered users"
"Can be set by same group as user that submits"
"Can be seen by same group as user that submits"
Persmissions on tracker :
a list of the different user groups is presented and there is a menu in front of each proposing options :
"Can submit in this tracker"
"Can access this tracker"

If you think of these options you will see it covers many of improvement demands I have seen.
Implementing something like that would make RedMine a much more extended product (even if I like it very much yet ;) )

OPEN SOURCE DEVELOPMENT TEAMS DON'T NEED IT, BUT  IT WILL MUCH SATISFY MOST OTHER DEVELOPMENT TEAMS IN THE WORLD :=)

Hope it helps

Actions #164

Updated by Anton Nepomnyaschih over 13 years ago

+1 Very good feature. We are trying to make transparent process for our customers. But sometimes there are activities that should be made visible only to some people. Not whole project.

Actions #165

Updated by Christopher Proud about 13 years ago

+1 this would be very useful

Actions #166

Updated by Adrien Crivelli about 13 years ago

I forked Redmine and applied the private issue patch on the 1.0-stable branch and updated what needed (mainly unit test). I add the patch here so it is easy to apply on existing Redmine installation (but you could also clone my repository). Everything is working fine on our production server so far.

However there is still one failing unit test ("test_default_assign"). As I am new to RAILS, I would really appreciate if somebody could give me hints on how to solve it (advices or documentation). I'm having hard time figuring out how to test "a user without permission to add private issue will always create public issue". I am not sure if the error is in the test, or in the issue creation process (in particular the validation process). So if anyone could help me about that, that would be very nice.

Actions #167

Updated by Skaag Argonius about 13 years ago

This patch fails for me:

Redmine 1.0.3.devel.4410 (MySQL)
Actions #168

Updated by Skaag Argonius about 13 years ago

Skaag Argonius wrote:

This patch fails for me:

[...]

Ok I have upgraded to: Redmine 1.1.0.devel.4761 (MySQL)
Is this patch known to work with this version of Redmine?

Actions #169

Updated by O G about 13 years ago

+1 for this oldie!

Actions #170

Updated by Adrien Crivelli about 13 years ago

Skaag Argonius wrote:

Ok I have upgraded to: Redmine 1.1.0.devel.4761 (MySQL)
Is this patch known to work with this version of Redmine?

As stated in patch filename it is to be applied on Redmine 1.0.5 revision 4569. I did not test it on anything else. If you provide more information about what fails, I may be able to help. Otherwise I may suggest you to grab the whole thing from the fork:
https://github.com/PowerKiKi/redmine/tree/1.0-stable

Actions #171

Updated by Brian Lindahl about 13 years ago

This looks planned for Redmine 1.2. See #7414.

Actions #172

Updated by Peter Volkov almost 13 years ago

  • Assignee set to Jean-Philippe Lang

Finally this feature request is closed and code was just commited! Thank you Jean!!!
Please mark this issue as duplicate of #7414.

Actions #173

Updated by Jean-Philippe Lang almost 13 years ago

  • Status changed from New to Closed
  • Target version deleted (Unplanned backlogs)
  • Resolution set to Duplicate

Thanks for the feedback.

Actions #174

Updated by Go MAEDA over 5 years ago

  • Related to deleted (Feature #6014: Restricted access for clients on a closed-source project)
Actions

Also available in: Atom PDF