• Status Closed
  • Percent Complete
  • Task Type Feature Request
  • Category Backend/Core
  • Assigned To No-one
  • Operating System All
  • Severity Low
  • Priority Very Low
  • Reported Version 0.9.8
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Flyspray
Opened by Anonymous Submitter - 18.11.2005
Last edited by macnewbold - 22.11.2005

FS#743 - Look and Feel: Column view determined by user and/or group permissions

The task list's column view settings should be determined by user and/or group permissions. For example, if permissions were customized, the "Severity" column would only be viewable by 'Developers' whereas the "Priority" column would only be viewable by 'Producers'.

Closed by  Anonymous Submitter
10.12.2005 23:53
Reason for closing:  Will Not Implement
Additional comments about closing:  

We give up on you as well, Morgan.

This sounds backwards to me: currently, submitters can choose the severity, but managers choose the priority.

I can’t think of a reason why one of those two columns should be hidden from people who can view the task. Can you explain why you think this should be added?

Anonymous Submitter commented on 18.11.2005 20:52

First of all, you need to understand the definition of “Severity” and “Priority”.

“Severity” refers to the degree of effect on the software. This is only useful to developers. In addition, “Severity” is typically only assigned by developers. This instance of Flyspray is incorrectly configured. “Priority” refers to the degree of importance or value placed on the task, such as the desires of a customer or a schedule requirement. Project managers (also producers) deal with priorities. In organized development environments, the project manager(s) determines and prioritizes the distribution of tasks. Non-developers should not be able to submit “Severity” levels, and non-managers should not be able to submit “Priority” levels. That’s the correct method of operation. Reporters should not be concerned with Severities or Priorities.

A defect report regarding a prominent misspelling of the client’s name, for instance, would be properly classified as a low-severity and high-priority task. A defect report regarding an obscure error resulting from psychotic user behavior could be properly classified as a high-severity and low-priority task.

But this narrow focus you’ve on “Severity” and “Priority” is not the issue.  FS#743  concerns providing administrators and project managers a permissions capability for displaying certain columns to certain users, not just Severity and Priority columns to certain users. Currently, Flyspray allows only large-scale permissions for column views. For example, an administrator can access the Admin Toolbox and alter the Look and Feel settings for the installation’s default column view, or a project manager can alter the Look and Feel of a project’s column view; however, the column view cannot be configured per user.

Calm down, I understand perfectly what Severity and Priority are, and what they mean. And I use a very similar example when comparing their two extremes. I’m not narrowly focused on Severity and Priority, they just happened to be the two you mentioned in your description.

While we’re on the subject, I don’t see how this issue can be classified as High severity, but that’s beside the point.

I understand perfectly that you would like to be able (as an administrator/manager) to control what fields are viewable and settable by which groups of users. What I am not understanding is why you think it should work that way. To me, it just sounds complex, confusing, and I can’t think of a single good reason when I would ever use it (beyond the duplication of Flyspray’s current behavior). I’m just trying to understand why this should be done in the first place.

Anonymous Submitter commented on 19.11.2005 18:16

Since you completely misunderstood  FS#744 , describe to me how you think  FS#743  would work.

Anonymous Submitter commented on 19.11.2005 21:58

Morgan: The onus is not on Mac to explain how your requested feature should work. The developers’ task is to try and understand what the users desire, and then consider whether or not to implement said features. It seems to me that Mac is trying to understand the usefulness of a feature that will take many man-hours to implement, but only be used by less than one percent of Flyspray admins.

Now, *you* please explain it to Mac. I suggest you be polite about it, or he is likely to lose whatever interest he has left in this task.

In case my previous comments were unclear, I don’t see a reason why particular fields should be hidden from someone who has permission to view the task. So I don’t have any idea how you think this should work, because I don’t think it should happen at all. Unless you would like to clarify _why_ this is important, and a bit on _how_ you think it should work, I’m going to recommend closing this task, or at least deferring it until there is both a clear need for it and a person who wants to implement it.

Anonymous Submitter commented on 10.12.2005 23:42

I’ve given up on this team. Only one contributor has prior professional experience in quality assurance.

I’ll just wait for 0.9.9 and have my team implement the features that are needed in a *real* QA environment since this team is clearly incapable.


Available keyboard shortcuts


Task Details

Task Editing