Redmine

hello An,

I have got the same problem as you and done this configuration:
- for my issues i want the client to see (belonging to my client project), i put them in a sub project of the main project.
- i do a client role and make member of the sub-project only the client role and login.

so in my project structure I have:
main (all issues that I don't want the client to see)
sub project: issues client per client

for the moment it"s working for me as i don't have very much client connecting to my redmine.

tell me what you think of that

See you

Thanks jerome. Yes, that should work, but actually this is more or less a hack right? So Redmine doesn't officially support this usercase?

yes it's a kind of trick, because i have modified all my project database structure to fit that need (and that lack of answer to this need by redmine)

And even today, I sometimes need to create a sub-project for 3 issues regarding one client, which is a litle bit a pity I think for such a project like redmine.

if some redmine's developpers reads me ... :)

have a good day

ps: I have not tested but maybe it could be easier to define all issue by default to private and to give access to your client to the non-private issue...

jerome l wrote:

ps: I have not tested but maybe it could be easier to define all issue by default to private and to give access to your client to the non-private issue...

This actually was the first thing we tried, and it didn't work so well, since if you set an issue as private, any other developers who are not the assignee or assigner will not be able to see it.

Ok ! So yes Redmine doesn't have this feature officially... Maybe we should put a post in the development thread with a link to that one?

An Phan wrote:

jerome l wrote:

ps: I have not tested but maybe it could be easier to define all issue by default to private and to give access to your client to the non-private issue...

This actually was the first thing we tried, and it didn't work so well, since if you set an issue as private, any other developers who are not the assignee or assigner will not be able to see it.

What you do is make it so all non-client roles can view all issues by default, including private ones. That way it basically turns the 'Private' flag into an internal/external flag, so to speak. Developers would not have the issue you described in that case.

That definitely falls into hacky territory, since it shuts down the ability to use private issues the way they were intended. When it comes to access control, things get messy fast, and it's a hard discussion to have because everyone has their own particular use cases in mind. For some people, a multi-select box that limits visibility to certain roles would do the trick, and they'd manage roles like they manage groups. For others, they'd want to select it user by user. For still more, they'd just want visibility to match the Watchers list. Other don't want to stop at the issue level, and want all this granularity for every single field, file attachment, and comment posted.

Ultimately, people would be better off throwing out their personal use cases and studying what other tools have done. Look at things like SharePoint, JIRA, and enterprise CMSs and see how they've implemented permissions management, and draw the line somewhere reasonable. It's easy for things to just become ridiculous and you're better off starting an email thread.

Often enough, companies that care strongly enough about permission control to create mind-bogglingly expansive rule sets would just be better off using something like SharePoint as an issue tracker anyway. Yeah, it's not really built for it, but the effort it'd take to twist SP into an issue tracker is a fraction of the effort it would take to twist Redmine into a micro-managed enterprise solution.

Joshua DeClercq wrote:

For some people, a multi-select box that limits visibility to certain roles would do the trick, and they'd manage roles like they manage groups. For others, they'd want to select it user by user. For still more, they'd just want visibility to match the Watchers list. Other don't want to stop at the issue level, and want all this granularity for every single field, file attachment, and comment posted.

Dear Joshua,

thanks for your answer,I totally agree with you on the difficulties to fit the needs of everyone, as I am working in a software company, I know what you mean :).

Often enough, companies that care strongly enough about permission control to create mind-bogglingly expansive rule sets would just be better off using something like SharePoint as an issue tracker anyway. Yeah, it's not really built for it, but the effort it'd take to twist SP into an issue tracker is a fraction of the effort it would take to twist Redmine into a micro-managed enterprise solution.

The topic of that feature is to allow a user to share an issue(and also informations attached to as you said) with a particular role.

the interest of that is very important to ease the relationship with the final customer which can be very involved into the development of the software as they often pay for special custom feature and want to have a reporting of their projet 's progress.

The informations are in Redmine and it will ease the work of the developpers too if customer can access to it as it will avoid many emails and phone call. I can tell you that my developpers said to me that my solution has made earn time, and so thanks to redmine for it.

by the way, if redmine's developpers think it's not in the scope of redmine and it's too hard to do, I will keep my solution for the moment, and I hope it will be made in redmine one day :).

have a good day,