Hi,

I've exactly the same problem and discussed it here already two years before..

Result:
You can hide projects by not declaring them as "public" projects - but:
The current authorization system still allows direct access to tickets
of private projects...

So the only way to fix this is to extend the current view and authorization
system by a plugin...

One idea:

• new property for users to declare them as a "client" / "external"
• a filter for the views to only allow clients/externals the access to their issues
  • means: all clients/externals only can view single issues, an issue table and a predefined start page
  • clients/externals MUST NOT see the complete ChiliProject UI with all it's menus
  • better: only show the content area for issues / issue tables
  • build it so lightweight that it can be integrated in existing homepages very easy (as iframe without menubars...)
• without dividing the ChiliProject UI for devs and clients/external, there always will be chances to bypass filters
  and see parts or the whole CP UI - so a separate view would be much easier

I would help building such a system - because we need it for a current project.

So maybe I could spend some money for this, if there's somebody who could help here...

Currently the above points are just an idea - actually I'm not able to examine if and how it could be realized.

ciao,
Chris

I don't know if this'll work, but here's a potential suggestion:

http://www.redmine.org/plugins/redmine_changeauthor
https://github.com/thorin/redmine_changeauthor (forked and updated for Redmine 2.x - not by me)

1. Create the Issue
2. Change the Author to the relevant non-member (or member with restricted permissions, but can view own issues)
3. Use private notes as necessary. (I don't recall if CP has this - migrated back to RM a few months ago.)

Now, I haven't tested this, and don't know if the user will receive notifications that a ticket was created (and then newly attributed to them), but theoretically the first new action will send appropriate notices.

I also don't know if they will have access to private notes on their "own" issues, or if the change will cause the permissions system to cough up a lung.

But it might work.

Hey,

sorry, but this doesn't help - the problem is:
Redmine, nor CP support a fully private environment, yet.

a) because there are some issues where one can open views/links when the URL is konwn/can be guessed, by each authorized user
b) to enable private issues ALL projects MUST be created as non-public projects, which causes many issues making Redmine/CP very unconvenient for all (privileged) users in daily life (no project lists, no big summaries)

I already tried option b) and went back to make all projects public...

The problem is, that IMHO Redmine/CP isn't cleanly designed/programmed to work with a privileged and unprivileged mode (external users / customers). An unprivileged mode not only should hide private issues/projects - it further should hide all menus/gui elements for managing tickets etc. Better: The unprivileged mode should be a very leightweight version of the userinterface...

Thus I only see the chance to realize it by a plugin - here we effectively can filter / decide what to show to unprivileged users an what not.

Just a note: I'm not a Redmine/CP dev and just have a very superficial overview of the internals - so please correct me, if I'm wrong.

ciao,
Chris

Chris Dähn wrote:

You can hide projects by not declaring them as "public" projects - but:
The current authorization system still allows direct access to tickets
of private projects...

No, private projects and everything in there should be accessible only to members of the project, including the existence of the project. If it is not the case, it's a bug, could you please be more specific about what you mean?

Felix, all;

first off, thanks a bunch for your thoughts on that. So there's some input I can play with. I will, so, see whether we can do with a private project even if it doesn't really suit our needs well here. Though having a more complex or flexible set of access control surely would be nice, limiting tickets to be only visible to those involved would perfectly suffice for our use cases. I'll see whether I can find someone to look at CP / the way redmine does this and come up with a plugin for this purpose.

Cheers,
Kristian

Regarding "private projects":

Setting all projects to "private" is a very very error prone process and leads to he problem, that you loose the projects overview /lists /dropdown menu.

So navigating and creating projects gets very inconvenient and causes the danger, that an external user still can see (accidentely as public created) projects and the whole project management system (all menus etc.).

Further making the projects private and one special project public raises the problem, that issues can't be made public or private, too. Means: The whole public projects MUST NOT contain any developer information or issues... in daily life this is mostly not feasable.

Here a more fine grained access control would help: Where one can set single issues or a special tag / or tracker as visible for only special users.

It's not wanted and not needed that customers / external users can browse and see the whole project - they only should have access to special issues, not more. This is what many users (Redmine & CP users) demand and what is still not existing...
e.g.: ISPs and other service providers offer issue URLs via eMail - but no browsing for issues in a web interface - so customers only can access their issues with the URLs sent by the support team - and that's what most companies (having ticket/project management systems) need for their daily life...

I hope this explaination helped to understand it better...

ciao,
Chris

Besides:
The issue regarding private issues & projects is discussed here #189 in detail, too.