Client User Permissions - aC's biggest gap
Page: 1
Recent posts in this topic
cbtrussell
on Dec 6. 2007. 3:46 pm
Hi Ilijah,
Our team is actively using aC now and we are compiling a list of issues I'll eventually post here; so far, aC is off to a great start! That said there is one issue that stands out as critical and is preventing us from being able to invite our customers to use the tool: Client User Permissions
Currently, client users can be granted permission to add entries and/or manage (edit, delete) entries. Unfortunately we've now realized that all client users can VIEW all functional areas of a project. We can hide individual entries from clients, which is useful when we want to have a private discussion that the client can't see, but does not go far enough when we want to hide an area (tickets, checklists, time, etc) from a client completely.
What we need is a separate 'view' privilege for each functional area, set at either the client/project level, or set at the individual user/project level. For example, I would want to be able to designate whether a client user's access to a given module would be:
( ) None
( ) View Only
( ) View + Add New
( ) View + Add New + Edit Existing
Currently a client user can see ALL functional areas, and all content within those areas unless each easy is explicitly designated as 'do not show to client'. What we DESPERATELY need is the ability to hide certain areas from clients COMPLETELY. For example, we do not want our clients to see checklists, tickets or time tracking entries. Ever. So using the proposed permission controls above, we would want to set access as 'None" for all client users.
In doing so, the following would have to occur for areas clients had no access to:
- the link (tab) would be removed from the primary navigation
- the dashboard would not display recent activity from that area (no new or updated ticket entries would be displayed to client users, for example)
- related items would be filtered as appropriate, for example... if the client had no access to tickets, then the milestone detail page would NOT show tickets related to a given milestone, the calendar wouldn't show tickets, etc. This will require a thorough audit to catch everything.
- the iCal feed + RSS feeds for specific users would be filtered as appropriate
- attempts to access these areas via direct URL would be handled gracefully, perhaps a redirect to the dashboard with error message
I don't want to be greedy, but it would be GREAT if we could set project-wide access permissions for all client users on a given project, so for example set tickets to 'none' and no ticket permission option would be available to any client users on that project. This would prevent mistakes when setting up multiple client users on a project.
Please note per my previous thread here:
http://www.activecollab.com/forums/topic/2309/
that when a client does not have access to add/edit entries, attempting to do so gives a nasty 403 error, which of course should be handled much more gracefully - perhaps a redirect to the dashboard with an error message of some sort as mentioned above. The current behavior is really the only thing that stands out in aC as poorly executed.
Being able to collaborate amongst ourselves is good, but not being able to collaborate with our customers prevents us from realizing a substantial portion of the value we expect to extract from aC. I fully appreciate doing this the right way will involve a substantial amount of work, but also understand that
(a) I honestly expected this core functionality to be available in the current release, and was surprised to find it was not.
(b) Being able to control what client users can view/access is truly critical to many aC customers
There is another thread about permissions for owner company users here:
http://www.activecollab.com/forums/topic/2260/
Which is also important, but not nearly as much as being able to control what our client users can see & do.
Please consider making improvements to the user permissions feature set one of your highest priority issues.
Thank you!
Brandon
Our team is actively using aC now and we are compiling a list of issues I'll eventually post here; so far, aC is off to a great start! That said there is one issue that stands out as critical and is preventing us from being able to invite our customers to use the tool: Client User Permissions
Currently, client users can be granted permission to add entries and/or manage (edit, delete) entries. Unfortunately we've now realized that all client users can VIEW all functional areas of a project. We can hide individual entries from clients, which is useful when we want to have a private discussion that the client can't see, but does not go far enough when we want to hide an area (tickets, checklists, time, etc) from a client completely.
What we need is a separate 'view' privilege for each functional area, set at either the client/project level, or set at the individual user/project level. For example, I would want to be able to designate whether a client user's access to a given module would be:
( ) None
( ) View Only
( ) View + Add New
( ) View + Add New + Edit Existing
Currently a client user can see ALL functional areas, and all content within those areas unless each easy is explicitly designated as 'do not show to client'. What we DESPERATELY need is the ability to hide certain areas from clients COMPLETELY. For example, we do not want our clients to see checklists, tickets or time tracking entries. Ever. So using the proposed permission controls above, we would want to set access as 'None" for all client users.
In doing so, the following would have to occur for areas clients had no access to:
- the link (tab) would be removed from the primary navigation
- the dashboard would not display recent activity from that area (no new or updated ticket entries would be displayed to client users, for example)
- related items would be filtered as appropriate, for example... if the client had no access to tickets, then the milestone detail page would NOT show tickets related to a given milestone, the calendar wouldn't show tickets, etc. This will require a thorough audit to catch everything.
- the iCal feed + RSS feeds for specific users would be filtered as appropriate
- attempts to access these areas via direct URL would be handled gracefully, perhaps a redirect to the dashboard with error message
I don't want to be greedy, but it would be GREAT if we could set project-wide access permissions for all client users on a given project, so for example set tickets to 'none' and no ticket permission option would be available to any client users on that project. This would prevent mistakes when setting up multiple client users on a project.
Please note per my previous thread here:
http://www.activecollab.com/forums/topic/2309/
that when a client does not have access to add/edit entries, attempting to do so gives a nasty 403 error, which of course should be handled much more gracefully - perhaps a redirect to the dashboard with an error message of some sort as mentioned above. The current behavior is really the only thing that stands out in aC as poorly executed.
Being able to collaborate amongst ourselves is good, but not being able to collaborate with our customers prevents us from realizing a substantial portion of the value we expect to extract from aC. I fully appreciate doing this the right way will involve a substantial amount of work, but also understand that
(a) I honestly expected this core functionality to be available in the current release, and was surprised to find it was not.
(b) Being able to control what client users can view/access is truly critical to many aC customers
There is another thread about permissions for owner company users here:
http://www.activecollab.com/forums/topic/2260/
Which is also important, but not nearly as much as being able to control what our client users can see & do.
Please consider making improvements to the user permissions feature set one of your highest priority issues.
Thank you!
Brandon
Ilija Studen
on Dec 6. 2007. 7:46 pm
Hi Brandon.
We are working on many permission system improvements, but I cannot discuss the details at the moment.
Thanks for the feedback!
We are working on many permission system improvements, but I cannot discuss the details at the moment.
Thanks for the feedback!
activeCollab team member | LinkedIn
It's GREAT feedback indeed, and worth taking into account I hope since there are valid points and very constructive / detailed post !
Nice to know the permission system will evolve :)
Nice to know the permission system will evolve :)
The best way to predict the future is to invent it
------------------------------------------
Apache 2.2.8 - MySQL 5.0.45 - PHP 5.2.6 | Debian 4.0 (Etch)
------------------------------------------
Apache 2.2.8 - MySQL 5.0.45 - PHP 5.2.6 | Debian 4.0 (Etch)
Just thought I'd vote for cbtrussell's post. I plan on using activecollab for my solo law practice as a way to provide clients access to their case's progress. However, I also plan on using it internally to capture next-steps and things to do for each case, which is a level of transparency that I'm not interested in providing to the client. Sometimes it's just easier to make the sausage. Cbtrussell lays out exactly the type of permission system that's needed.
Brandon's suggestions would be wonderful to see put in place. Is there any timeframe for these modifications?
-Randy
-Randy
I'd also like to know the progress, for this is a huge issue. I also need permissions to be handled like what Brandon described. I also am in support of Brandon's "greedy" option.
I look forward to hearing more about the improvements that are being worked on.
I look forward to hearing more about the improvements that are being worked on.
Ilija Studen
on Feb 27. 2008. 6:14 am
Sorry Rob, we cannot discuss this permission system enhancements at the moment because it is not fully implemented yet. When it's done and we know how exactly things worked out we'll write about it on our blog.
activeCollab team member | LinkedIn
