On 16/10/12 12:26, Peter Koželj wrote:
On Tue, Oct 16, 2012 at 12:33 PM, Apache Bloodhound <
[email protected]> wrote:
#234: Quick Ticket: link to /newticket, description and priority
--------------------------+---------------------
Reporter: jdreimann | Owner: nobody
Type: enhancement | Status: new
Priority: major | Milestone:
Component: ui design | Version:
Resolution: | Keywords: starter
--------------------------+---------------------
Changes (by jdreimann):
* keywords: => starter
Old description:
,, ... via ''Bloodhound'' quick create ticket dialog,,
New description:
1. Currently the text {{{Create Ticket}}} in the Quick Ticket dialogue
links to the full [https://issues.apache.org/bloodhound/newticket
/newticket] page. Users can't be expected to know this. I believe we
should add some text to the {{{class="popover-title"}}} that links to the
dialogue instead - see the attached screenshot of a change I made locally.
2. The most common thing I find myself doing after using Quick Ticket is
to edit the resulting ticket to add a description. I believe we should
should provide a small description field in the Quick Ticket dialogue (3
rows?).
+1
3. Thinking about what we could expect the average user to know, we should
probably replace the **Version** dropdown with one for **Priority**. Few
users will actively scheduled tickets, while many will have some idea of
priority, even if it's just their own priority.
**The order of fields should then be:**
1. Summary
1. Description
1. Type
1. Component
1. Priority
As an aside, I would question whether component should be a default field,
happy to discuss this in the comments.
I think version needs to be there. For any ticket that is a bug, it is
important to know which version!
And for any project that does feature planning, version is important for
all ticket types.
I would be happy with that. Associating a bug to a version, where they
are defined, should be available.
Components should be good too and we appear to be missing product from
the list.
Ideally this should be user configurable but we could also auto-hide any
fields for which there are no values defined (id a project does not use
components, don't show them).
Perhaps, in the long run, we should make these things configurable based
on permissions for a given project. That could make it local policy to
say whether an anonymous user (for instance) is allowed to set specific
aspects of tickets. This would probably have to extend into the
newticket interface too.
Hiding fields that are not available certainly makes sense.
Cheers,
Gary
