“If debugging is the process of removing bugs, then programming must be the process of putting them in.” – Edsger Dijkstra
This is the Bug Tracking System for the Flyspray project. This is not a demo! Before opening a new task, please read the guidelines!
Do not issue bugs reports against versions earlier than 0.9.9.5
Security problem? Check the security section.
FS#734 - related tasks marked as private should not display publicly
Opened by Stephen Simmons (stephenrs) - Friday, 11 November 2005, 04:02 GMT+1
Last edited by Florian Schmitz (Floele) - Wednesday, 16 November 2005, 08:27 GMT+1
|
DetailsWhen a related task is marked as private, the summary is still listed publicly on the Related tab of the task(s) that it’s related to. Since task summaries are generally meant to give you enough info about the task so that you might not even need to read the details, exposing private summaries to the public essentially defeats the purpose of marking it private. Anyone who has view access to a task that is related to a private task can see the summary of that private task. |
Saturday, 19 November 2005, 16:17 GMT+1
Reason for closing: Fixed in devel
I’ve actually been thinking about this for a while - you are exactly right. Displaying a link to a task should be run through a permission check first, including the tooltips we place over
FS#123links in comments.You might already have realized this, but the same holds true for dependent tasks as with related ones.
Let me know if i should enter this as a separate/related task.
oh, just saw your message - yeah that sounds like a nice generalized way to handle things. cool.
Are there any other places that need fixing? Otherwise I will mark this bug as fixed :)
I’ve been thinking about this one for a few days. I think that we need a general template function to display links to tasks. Options could include whether or not to display things like
Link Text:
Title tag:
This function should also check the state of the task (private/public),the user’s permissions, and decide whether to return a link at all, or merely the text “
FS#123: Marked Private”.Oops, I just realised that I didn’t actually address the question. This function should be used anywhere where we refer to other tasks. Details, comments, dependencies, related tasks, even notifications?
I would suggest that maybe related tasks marked private should be surpressed in any form from non-privileged users. So, rather than seeing “
FS#123: Marked Private”, the unprivileged user would see nothing...and they woudl see n related tasks shown in the parentheses on the Related tab, where n = numRelelatedTasks - numPrivRelatedTasks. does this sound right?@Tony
I think this can be done.
@Stephen
Why shouldn’t they be displayed? I think this would make everything more complicated.
I’m not sure what you mean about making things more complicated, but I don’t think they should be displayed for the same reason that private tasks themselves are not displayed publicly in the “All Tasks” listing - consistency, I guess. Also, listing them as “marked private” really serves no useful purpose for anyone, and could actually have a negative effect. If they are displayed, then they’re not truly private.
Hm, why should they be visible for dependencies (etc.) then?
They shouldn’t, again for the sake of a consistent definition and implementation of “private”.
True, but then it can lead to a confusing interface. Imagine this - a task has a private task as a dependency, but the person assigned the task isn’t the Project Manager, so s/he can’t see this dependency. They complete their work, and look for the ‘close task’ button. It’s not there, because the task has an open dependency! If this was me, I’d be thinking “WTF??”.
I’m open to more suggestions, but it seems to me that we need to show that there is a private task there, but show no details about it.
I agree with Tony. Showing only the task number of a private task shouldn’t reveal any confidential information.
Hmmm, you make a good point, although it seems to me that it would be a pretty rare circumstance that a PM would assign a task to someone and not want them to know what it depended on. So does this mean that related tasks will be treated differently then dependent tasks? I guess I tend to want to stick to a more strict definition of private, but you guys probably know the audience better. Would it be possible to have a global or project specific flag for “Strict Privacy”?
Also, as i think more about this: how could someone complete work on a task if it depended on another task that they were unaware of? Doesn’t this imply that their task didn’t really depend on another task? This sounds like it would be more of a Project Mamagement error. And if the situation that Tony describes actually happened, wouldn’t it still be a WTF moment unless the person assigned the task actaully knew that a private dependent task would prevent their task from being closed? This might not be very obvious to most workers - you’d still probably get a “Hey, where’s the ‘close task’ button?”, no?
I still don’t see a need to hide a task completely. It makes things more complicated: The number for “related tasks” needs to be dependent on the users permissions then and it is not possible to achieve this with a single template function for tasklinks unless we don’t care of the number is incorrect.
The reason I’d like to be able to hide private tasks completely is that I personally envision 2 primary (and delineated) workflows with my use of Flyspray: Internal (me and other developers) and External (interaction with clients). I guess I don’t want to be put in the position of having to field questions from clients like: “Hey, what are all these private tasks, what’s going on here?”. I’d prefer to have things exposed on the interface on a strictly “need to know” basis. If it’s a huge amount of extra coding complexity to have strict privacy then I’ll have to live with less than strict, but it’s not ideal - at least in my work, others may disagree.
Should I use an application- or a project-wide setting for the strict privacy then?
All things being equal in terms of coding, it would be nice to be able to have the flexibility to set this on a project-specific basis. Although application-wide would probably be fine in actual practice, if this is much easier to code.
I’m not a big fan of making extra options, and I think that the proposed option for ‘strict privacy’ will unnecessarily complicate things. To be honest, I don’t know exactly what we should do. Until I do, how about we make the template not display links to private tasks unless the user is a PM or Admin? Since it will be in a central function, it will be easy to quickly modify later if we need to.
That would work for me. You’re right, simple is good. Does this also solve the problem of what number to show in the related tasks tab though?
Is this the same as “unless the user can view private tasks”?
No, it doesn’t. But I’m sure that we’ll find a solution for that too ;)
I found a solution now. All tasks are not displayed unless the user has permission to view it. An exception are the links like
FS#1in comments, because missing text there will appear strange to readers (non-strict privacy is used) ;)The only thing which needs to be done now is extending the template function so that customising the title etc. is possible.
Stephen, it doesn’t really solve the number of tasks to display in the tabs, no. Nor does it solve private dependencies not appearing. Perhaps we could get more opinions on the mailing list.
Florian, there is no such permission - ‘view private tasks’. If you have ‘manage project’ permissions, you can view private tasks, so only PMs and Admins have it. For
FS#123links in comments and details text, perhaps we could simply not return a hyperlink at all if the task is private and it’s not a PM or Admin viewing?I rather ment “unless the user can view *this* private task”. For example if the task is assigned to him he can view it too.
That is what I have been doing. I needed to modify the templates a bit though so that there are no unnecessary <br>s etc.