This is the guide for admins to learn about “ticket” feature provided by OSDN. Mainly, it details on tips that project admins, ticket admins, and ticket technicians will want to know or consider handy to learn in advance when administering ticket features.
To learn about how to submit a ticket and how to use the ticket system for daily communication, please read How to use Ticket.
If you encounter any problems or have any requests, please use the ticket to report.
If there's no “ticket” tab in the project menu which is at the top to the project page, that means the ticket feature is disabled.
From the “admin” (this is a tab available for project admins only) menu, select “Select Features” to display the page where you can edit the tools you wish to set up.
In the “function” list, there's an item called “ticket”, so after putting a check mark there, click on the update button.
Once the “ticket” feature is enabled, by selecting “Member Permissions” from the “admin” menu, you will be able to edit the permissions granted to each project member, regarding the ticket system.
There are two types of permissions regarding the ticket system (although you could say there are three types if you include ones without any permission granted). It is also possible to grant one person with both permissions (you could also set one person to be a “ticket technician” as well as being a “ticket admin”).
With the “ticket admin” permission, you can basically use all the admin functions regarding your project's ticket system. For example, you will be able to edit the settings for the ticket system, add or delete milestones and ticket types/components, and delete tickets, which will all be mentioned later.
For “Ticket Technician” permission, choose someone who is likely to be in charge of each ticket. With this permission, the person will be able to edit milestones, properties such as types, changing technician, and completing a ticket.
To configure settings for the whole ticket system, select “admin” from the ticket menu. The items that are configured on the ticket system settings page will be explained in the following sections.
Here, you can either allow or disallow non logged-in users to “use the ticket feature to post tickets” or “post comments” on tickets in an anonymous manner.
When the check mark is disabled, non logged-in users won't be able to post tickets/comments.
Allowing non logged-in users to post could bring positive effects as to capturing more bug reports and requests. But keep it in mind that you are not going to be able to identify the person who made the post (and although equipped with a filter, perfect filtration is not guaranteed), so there remains the risk of spam.
Choose either that fits the situation best.
Every time a new ticket is created, or there's a comment post or modification, the person who submitted the ticket and the ticket technician will receive an email that notifies the change that's been made.
You could also configure to add other project members to receive the same mail. Choose one of the five versions for the settings.
Even a person who happens to fit two or more of the above conditions, there will be only one email sent. (The person won't be getting multiple mails.) However, if the person is included in the mailing list, that person will receive two emails. (One sent to the personal destination, and the other sent for being in the mailing list.)
When you are configuring a mailing list as the email destinations, there are several procedures to be completed in advance.
First of all, create a mailing list beforehand, then leave it in a usable status. If the mailing list is in “stop to use” status, it will not appear in the pull-down options.
The mails will be sent from firstname.lastname@example.org. You will need to configure email settings to receive this mail address from the mailing list.
To be specific, go to the admin page of each mailing list to configure the settings for the sender filter and recipient filter.
You can set a property called “milestone” for ticket.
This property is useful when you “want to sort tickets according to the degree of progress” or “want to set the start date or due date for ticket processing”. For example, “when you know there's a ticket to create before version 2.0 is published”, or “when you are determined to focus on bug fixes from 15th to 30th the next month and trying to gather the tickets that need to be changed”, milestone will do the job.
Go to “Milestone List” to create/check the milestones.
Only project members with “ticket admin” rights are allowed to create/edit/delete milestones. Other users can browse to seek information on milestone.
On milestone's information page, you can check things like status of progress automatically calculated based on the ticket's condition bound to the milestone, technician and types of ticket, priority, components, the status on open ticket/closed ticket discriminated in different levels based on priority.
Only project members with “ticket admin” rights are allowed to operate milestone management.
In default, there are no milestones registered. So let's register one by creating a new milestone.
For “Summary”, enter a short word/sentence that will be displayed as the name of the milestone. This text will appear in the milestone list and in the options where you choose ticket properties.
Here, you will enter the start date/due date.
You could also choose not to set the dates. In that case, the date when you create the milestone will become the starting date, and the due date will be left empty (not set).
As scheduled, on both start and due dates, the milestone is automatically processed to start and end. All project members will receive notice mails for starting/ending of the milestone.
For details, elaborate to explain what kind of milestone it is intended to be. Here, you can use Wiki syntax.
If you wish to edit the “summary” or “details”, or to “change the starting date”, or “end the milestone because it's already finished”, go to the Milestone List to find the milestone you want to edit, then click “edit”. When you get to the designated milestone page, click on the “Edit this Milestone” button to start editing.
For milestones without a deadline, you can make it end at once. (Even before the starting date.)
When you are processing it manually, all the remaining open ticket in the milestone at the moment can be moved to another milestone (or you could leave the properties of those tickets to be not set.)
When there are open tickets left on the closing milestone, by putting a check mark to “Change To Finish”, you will be able to choose the moving destination for those open tickets.
You may encounter a situation where you need to to reopen a finished milestone.
When a ticket admin browses the milestone list, there's a box at the upper right to let you choose to “Show all finished milestones”. By putting a check mark there, you will be able to see the whole list of milestones including the finished ones.
Display the “details” of the designated milestone, then click on the “Edit this Milestone” button.
When you get to the “Edit Milestone” page, scroll down to find “Reopen this milestone”. Then put a check mark there and click on the “submit” button.
Make sure the due date is set with today's date or a date after today (or you could leave it empty without setting a date.) (When the due date is set with a date before “today”, the milestone will be processed to automatically end.)
You can delete milestones that aren't needed anymore. But keep it in mind, that once a milestone is deleted, there's no way of bringing it back to reopen.
You can delete a milestone from the “detail” page, just like how it's done with editing a milestone.
When you click on the “Delete this Milestone” button, you will jump to the confirmation page to delete. If you still want to delete it, click on the “Yes, please delete” button.
If you happen to have open tickets on the milestone that is to be deleted, you can move them to another milestone (or leave it with empty property.)
Just like how it's done with editing a milestone, select the destination and then click on the “Yes, please delete” button.
You can attribute “Ticket Type” to a ticket, which lets you sort the tickets according to the types.
Only project members with “ticket admin” rights can manage and edit the ticket types.
There are four types already registered as default, which are "bug”, “support request”, “patch”, and “feature request”.
To manage the ticket types, from the “ticket” pull down menu, select “Types List”.
To add a new “type”, go to “Add New Type” which is at the bottom of the “Type List” page.
Type name is the name for ticket type . This name will be used to display tickets. For description, elaborate to explain this new ticket type. (You can write in Wiki Syntax.)
When the check mark is taken off of “Public”, the tickets that were sorted into that type will be viewed by project members only. (When a non-member is browsing, those tickets won't even appear on the Type List.)
The “Type” which was made not public will appear on the list with a red background.
You can make simple instructions appear on the screen when someone tries to submit this type of tickets.
For example, for a bug, you may want to say “if you happen to have the log, then attach that as well” or “don't forget to tell us what browser you're using”, and you may also want to remind them to provide a certain type of information. Use this feature to make those instructions appear.
If you don't need to use it, don't enter anything.
If you want to edit a ticket type, click on “edit” from the Types List.
By the way, with the four default types “bug”, “support Request”, “Patch”, “Feature Request”, you can not edit the Type Name and Description.
Regarding components, there a few things that can be set up from ticket system manager, so you may also want to refer to “Ticket Manager”.
Just like how it's done with editing, you can delete a ticket type in the same manner from the Type List's “delete” link.
When there are open tickets that fit the type, there will be options listed to chose where those tickets should be moved, so select the destination.
Keep it in mind that once a type is deleted, there's no way of bringing it back.
If you are still determined to delete it, then click on “Yes, please delete”.
“Component” is a property added to a ticket to classify what exactly the ticket corresponds to about the project.
Only project members with “Ticket Admin” rights can administer and edit ticket components.
Let's say your project has released two packages called “foo” and “bar”, and if each was given a different version, then wouldn't you want to classify them, for example, saying “this ticket regards foo version 1.0” and “this ticket regards bar version 0.2”?
In this kind of situation, it's best to use the "component" property.
Although this property was designed to be used in such a way, you can be as creative and inventive as can be to make the full use out of it.
As of default settings, there are no components registered.
To add a new component, from the pull-down Ticket menu, click on “Component List”.
Enter a name for the component's name. What you enter here will be used to display tickets.
For description, elaborate on the component to explain what it is about.
You can assign a technician in charge of the component.
During registration/editing of a ticket, if there was a component being set as the property yet having no one assigned to be in charge, then the component technician will automatically become the person in charge of the ticket. (If another person was being explicitly assigned as a person in charge, then that person becomes the one in charge.)
With the use of the “File Release” feature (if there's a “download” tab in the project menu, the file release is enabled), you can edit the settings to automatically add/change/delete the ticket components to synchronize the File Releases.
If a project is receiving bug reports, the project may want to be informed with things like “which version release of which package” the bug report is talking about. Then you will need to use the ticket “component” property, so that it will automatically update some of the items.
In the following sections, we will elaborate on how package/release, like the ones below, are added to file release.
Unless you have configured to automatically load, components won't be created automatically.
In that case, you will have to add all components manually one by one.
Package Name on File release will be registered as ticket component
For the first example above, “foo”, “bar”, “baz” will be automatically registered as components.
Having that as the condition, If both package “foo” release “1.3” and package “hoge” release “0.1” get registered, there will be additional component “hoge”.
Release name on File release will be registered as ticket component.
For the first example above, “0.1”, “0.9”, “1.0”, “1.1”, “1.2”, “2.0”. “3.0” will be registered automatically.
Having that as the condition, if the below two get registered,
then there will be additional component “1.3”.
Both Package name and Release name on File release will be imported as ticket components.
In this case, “foo 1.0”, “foo1.1”, “foo 1.2”, “bar 0.9”, “bar 1.0”, “bar 2.0”, “bar 3.0”, “baz 0.1” will be registered automatically.
Having that as the condition, if the below two get registered,
there will be additional components “foo 1.3” and “hoge 0.1”.
Even if you enable the automatic registration, you could still register the other components manually.
And even if you disable the automatic registration, the components that had been registered automatically will stay enabled. (They will not be automatically deleted.)
To take the hassle out of component managing, be advised to enable “Sync with File release” and select “Both Package and Release name on File release import to ticket component” for the settings.
Project members with either “Ticket Manager or Ticket Technician” right can edit some of the items on the ticket description page.
They can edit ticket properties such as components, milestones, priority, description and text regarding the registered tickets.
They can also process the changing of a person in charge or closing a ticket.
Once a comment is added to a ticket, there is no way of editing. However, there may be cases where the comments are judged to be inappropriate for what ever reasons (for example, personal information was included in the text).
The person who made the comment on the ticket or the ticket admin can delete.
On the right side of each comment, there's a link saying “delete the comment”. Click on that to get to the pop up window to delete. Once you click on“Yes, please delete”, the deletion will be executed.
However, what gets deleted is only the text on the comment, and there will be a message saying “there was a comment post, but has been deleted”. (also the name of the person who made the comment and the date it was posted will remain.)
Generally speaking, people customarily do not delete the comments on the tickets to leave a record.
But there could be a situation where you want to expunge the comment to an extent not even a trace of it remains due to what ever reason (for example, the comment is apparently a spam).
In that case, click on “delete completely”. The post time and information on the person who made the comment will all be deleted to disappear from the ticket description page completely.
Ticket admin is the only on who can execute the complete deletion.
Also, once they're deleted, there's no way of bringing them back.
For what ever reason, you may encounter a situation where you would have to delete an attached file.
Members with Ticket Admin/Technician rights can delete the file from the ticket description.
For example, there may be cases where you feel like “wanting to give appropriate priority to all the tickets that meet a certain condition” or “wanting to set XXX milestone to all the tickets that meet a certain condition”. In those situations, you would want to collectively edit the tickets that meet a certain condition.
If that is your case, let's go to the ticket list to start the process of “editing tickets collectively”.
It will be done as shown below.
Now, the properties of all the tickets that were selected are changed collectively. (Notice mail will be sent to inform the changes made just like how it's done when regular changes are made.)