Hiya,
Just to chime in on this...
Somebody should fix the bugtracker..
Totally agree with that! Therefore I took the effort and wrote a detailed review (see below), but so far, NOBODY, except Skeezix, took the courtesy/effort to even reply, not to mention, act on it!
Slightly dissapointed, but yet full of hope, yours sincerely: porg
Only really just noticed your 1st post but for various personal reasons I am not doing a great deal if anything at the moment anyway.
ED had given me admin permissions for the BugTracker, in order to check
its settings, and I think, as they are now, most of the troubles reported
in
FS#245 are fixed.
Nevertheless, I ask you to please go through this my evaluation, to
answer
remaining questions concerning the BugTracker.
And, if I am certain, that I am fully aware of the BugTracker, I offer
to you to
update its documentation/help at http://pandorawiki.org/Reporting_bugs accordingly.
Great that someone is looking at it.
!! Global versus project-based user groups
This is the status quo at http://bugs.openpandora.org :
- User groups are configured for "All projects" (=globally).
- The particular projects seem to have no user groups set up, and simply
use the global user groups.
I think this is a good principle, as OpenPandora is an open source
approach.
Distinct user groups per project seem to only make sense for
security/secret
projects. The only other reason, I could think of, is as a workaround to achieve fine-grained notifications.
But the setup as of now seems pretty reasonable as it is.
Yep, global all the way.
!! User groups & registration
Active user groups:
- Admin: Can do everything.
- Developer: Can do almost anything. (Only non-granted permissions:
Project Manager, View event log)
- Basic: As the name already tells. I looked at this group's
permissions, and
it seems that my inquiry FS#245 is almost solved by how this group's
settings
are.
Default global group for new users: Basic.
These user groups have no members, seem to be un-used:
- Pending
- Reporters
What was/is their purpose? Any intentions to use them still/again?
I guess the thought behind this was:
- Give freshly registered users enough trust (can create and delete
their
own content, but not edit/delete others' content), so the worst which
could
happen is if they report redundantly, write inpolitely, or spam.
- For the case that this setup does not work so fine, you will change
auto-
assignment of new users to "Pending" (which has no rights at all, even
less
than the anonymous user who can at least view), and approve new users manually.
Right?
Don't over engineer it, they are default groups, I guess they can be deleted, you really only need users, team and admins (or Basic, Developer and Admin in our case).
!! Permissions
!!! Permissions granted to Basic
Members can login View history View tasks
Open new tasks Modify own tasks # Part of fixing FS#245. Close own tasks # Part of fixing FS#245.
View comments Add comments Edit own comments # Part of fixing FS#245. Create attachments
Assign tasks to self if not already assigned Assign others' tasks to self Add self to assignees
!!! Permissions only granted to Developer and Admin
Modify tasks that are not user's own Close tasks that are not user's own Edit comments Delete comments Delete attachments
Edit assignments Show as assignees Can Vote for tasks
!! Basic user - Open questions concerning FS#245
!!!! Delete own attachments
I think basic users should have the ability to "Delete own attachments".
I do
not see this particular permission within FlySpray. I only see the
permission
"Delete attachments", but we can't grant this to basic users.
So as it seems, attachments once uploaded cannot be removed anymore.
Right?
If it is like this, I would like to add this info to http://pandorawiki.org/Reporting_bugs
I am honestly not so sure that deleting attachments is all that common place, most trackers I use let you upload new 'versions' but not easily pull out an old one. I guess it's a transparency and audit thing.
!!!! Assignment
Basic currently has these permissions:
- Assign tasks to self if not already assigned
- Assign others' tasks to self
- Add self to assignees
Basic currently lacks these permissions:
- Edit assignments
- Show as assignees
These are my arising questions:
- My observation: The basic user can either assign a task to an Admin,
a Developer or to him/her-self, but not to other Basic users. One of the developers is called "openpandora", who I guess shall be assigned if the Basic user is uncertain, or if the Developers decide to assign a shared responsibility. Are my assumptions correct? If so, I would like this to also be documented at: http://pandorawiki.org/Reporting_bugs
- If the basic user assigns a task to him/her-self, can he/she later
un-assign
her/him-self?
I don't see why not, each project can have a default assignment and it's not uncommon to have a 'Pending' user that gets the default assignments on small projects pending review. We currently let a record without mandatory assignments, anything wrong with that? Comments?
- What does "Show as assignees" mean? That the user shows as a possible
choice for "Assigned To" within the task submission form? Or that a user
is
shown as assignee in task listings or detailed task views? The English
noun
"assignee" is ambiguous, thus a short remark in German between porg and EvilDragon which may helps to get to a clear understanding: Wir haben in Deutsch die Möglichkeit zu sagen "Zugeteilter" (=hat die Verantwortung übernommen, "assigned person") oder "Zuteilbarer" (=steht zur Verfügung um die Verantwortung zu übernehmen "assignable person").
" Show as assignees" is the permission that lets a user show up in the in the assignments list for calls (Assigned To). Your understanding is correct.
Regards,
John