Dragnet 1.0.2 incorrect treatment for Assignee list

[TBiker]

In SOSCE bug tracking, the Assignee in the bug form contained a list of all users who belonged to the "Development" group of the project. If you wanted people to read/write to bugs but not be someone who could appear in the Assignee list then you had to create a group with read/write priviledges.

In Dragnet 1.0.2, the Assignee list now contains ANYONE with read access to the project regardless to which group they belong. I don't understand the benefit of this, in fact, total control over who can appear in this list is now lost. Is this a bug, an undersight, or what?

Terry

[mskrobul]

Groups in Dragnet are just a way of defining permissions. There is no other special treatment for named groups.

However, users with at least Modify access should probably be the only users listed in the Assignee field. I will log that as a bug.

[TBiker]

You have changed the meaning of the "Development" group in Dragnet from what it was in SOSCE as it pertains to the Assignee list. Why have a "Development" group at all? The bug is that only members of the Development group should be listed in the Assignee list. That is what should be corrected.

[mskrobul]

Groups are a way to organize users for setting permissions.

Groups make it easier to set user permissions. You can add users to a group and set permssions for the group instead of setting permissions for individual users.

The development group in Dragnet is simply a group that is created automatically that has Read/Modify permissions.

I will log your request for "only show users in the development group in assignee lists" as a feature request.

Thanks for your input.

[jclausius]

You have changed the meaning of the "Development" group in Dragnet from what it was in SOSCE as it pertains to the Assignee list. Why have a "Development" group at all? The bug is that only members of the Development group should be listed in the Assignee list. That is what should be corrected.

Just in case anyone wanted an explanation:

Dragnet has more built in types of items: Tasks, Bugs, and Discussions. Since a given item can be of a different type (not just bugs), multiple people need to be assigned "ownership" of that item, not just developers. To accomodate this new behavior, Dragnet pulls all users which have access to the project.

[TBiker]

I understand how the new "feature" in Dragnet of specifying an issue type (features, discussion, bugs, etc) has introduced a change to the Assignee list contents.

It seems like the Assignee list should become a security specification where you have Read/Write/Modify/Assignee. Under Assignee, you then specify a group or a list of users. I think this would give the greatest flexibility.

[jclausius]

Good idea. I'll modify the feature request for this functionality.

[Charles Monk]

On our system, this isn't working as described above. For a user to appear in the 'assignee' list, he/she must be explicitly configured to have modify permission in the project admin security page. It's not enough to be a member of a group which has been given modify permission: we need to add that particular user's name to the modify rights list.

Is this intentional behaviour? If so, why? If not, then is this a bug or am I doing something wrong? I must confess to being quite confused about the distinction between 'Unassigned' and 'Deny'. Is it necessary/helpful?

[mskrobul]

Charles -

Are the users that aren't showing up denied in any projects?

[Charles Monk]

I had another look at this and noticed that the security allocations are working correctly, but the wrong project name is being displayed in the page header. So, I've been busily fiddling with the security setup and (some of the time) editing settings for a different project. When I start from scratch and make sure I am looking at the right project, then it behaves correctly.

The problem is in the dropdown box for project selection. On my computer at least it seems to become very easily confused, and shows one project name in the dropdown selection, but in the page below it shows information corresponding to the *previously* selected project. One can detect this when working with the milestones, because milestones belonging to a different project appear, but when editing security settings there's no indication.

mskrobul, I can email you a couple of screen shots to show you what I mean.

CM.

[mskrobul]

We found this problem already and it has been fixed for the next release.

This problem seems to only occur in the Project Admin section. The project switch in the Item Tracking section works as expected.

For now, if you refresh the page after you make the switch the page will display correctly.