Steps: 1. setup a private group 2. put a bug into it 3. make a public bug 4. hypothetically enable the feature from bug 24496 5. block the public bug with the private bug (as someone who can see the bug) 6. try to resolve the blocked public bug as someone who can't see the private bug 7. try to remove the block as someone who can't see the private bug 8. try to set the private bug as blocking the public bug as someone who can't see the private bug. Concerns: A. should a private bug be able to prevent a public bug from being resolved? B. should people who can't see a bug be able to add a dependency to it? C. should people who can't see a bug be able to remove it from something else's dependency list. The answers people seem to have at first lead to some cute contradictions. Like I might be able to prevent bug 24496 from being resolved because it seems reasonable not to allow people to remove dependencies, and it seems reasonable to prevent bugs from being resolved if they are blocked. If you don't go for that pair (~A,~C) but instead opt for say ~A,C then what happens when someone removes this bug from the dependencies so they can resolve the block bug and then can't read this bug to the list. So that means ~A,B,C, but do we really want random people to be able to block a private bug?

Um, is this really such a tough one? I'd say the answer for all A-C is negative. I don't think the issue has particularly drastic effects though :-) Usually it's not the private bugs which stick around the system long enough to cause problems. Then again, the action of marking something resolved isn't crucial either; if somebody can't mark a bug as fixed and suspects he should, he'll probably contact an administrator anyway. Besides, you have basically the same issue if you're a person without editbugs; you can't edit bugs you're not the assignee of. Now, if you own a bug that's blocked by bugs assigned to other people, you can only mark it resolved by first removing the dependencies. Continuing on your lines, should _that_ be possible? Should changing dependencies be limited so that you can only do it between bugs you have edit permissions on? I don't think so, and this would make meta bugs highly unusable.

>A. should a private bug be able to prevent a public bug from being resolved? Yes. Just because it's private doesn't mean the rule doesn't apply. If it's blocking the public bug, there's probably a reason for it, and someone who can see the bug would have to make that judgement. >B. should people who can't see a bug be able to add a dependency to it? No. >C. should people who can't see a bug be able to remove it from something else's >dependency list. No.

Oops - actually, in comment 1, I meant that the answer to A should be true like Justdave said. The rest of my comment was illogical because of this, but it probably didn't cause any confusion. Dave: >>B. should people who can't see a bug be able to add a dependency to it? >No. >>C. should people who can't see a bug be able to remove it from something >>else's dependency list. >No. I agree, but I pulled a cvs tip yesterday night and both of these were possible. At first I thought B wasn't, but now I tried this again, and I can both add and remove dependencies of bugs that I don't have access to. I'll reopen this so the issue gets handled. If I misunderstood something, accept my apologies and close this again.

Thought we already had a bug for that, but the closest thing I can find is bug 141593, which isn't quite the same thing. Guess this will do. :-) Breaking dependency because this can be done independently of the other bug, it's not a prerequisite.

*** This bug has been marked as a duplicate of 141593 ***