Summary | Whups as Helpdesk |
Queue | Whups |
Type | Enhancement |
State | Accepted |
Priority | 1. Low |
Owners | |
Requester | mbydalek (at) mobilemini (dot) com |
Created | 11/04/2004 (7496 days ago) |
Due | |
Updated | 06/13/2008 (6179 days ago) |
Assigned | 11/04/2004 (7496 days ago) |
Resolved | |
Milestone | |
Patch | No |
State ⇒ Accepted
New Attachment: whups.helpdesk.CORRECT.tar.gz
exact same thing I did, but it looks like my patches were backwards!
I seem to have transposed the orig and modified versions, so here is
the correct patch.
I already had done an update against this morning, so there may be
something incorrect, but for the most part it looks like nothing has
changed since I last did this and these should all work.
Enjoy.
New Attachment: summary.php.patch
mybugs.php code. However, I also like using the portal/block layout
so I incorporated his code into the whups/lib/Block/summary.php code
with a couple of minor adjustments to match the existing code
structure there in summary.php. FWIW, the attached patch was against
rev 1.20 of summary.php
Kevin
In many places,The bug tracking system is very similar to a customer
service tracking system.
First,customer would like to know what is the situation of my ticket is.
Second,history is good and always welcome for customer .
Third,Who handle my problem ?
However ,Most of customer's question within personel information
should not be public and search able by other customers.
In such situation,the search scope for guest should be restricted.
If someone wanna WHUPS act as a service tracking system.My opion will
be :To see their own ticket,the guest *MUST* provides ticket number
and mail address that shown in the received notification message.
State ⇒ Assigned
New Attachment: whups.helpdesk.tar.gz
Priority ⇒ 1. Low
Type ⇒ Enhancement
Summary ⇒ Whups as Helpdesk
Queue ⇒ Whups
State ⇒ New
* Turba is integrated to keep track of ticket user information. What
I did was store the Turba ID as the ticket's user_id_requester. Each
time it was referenced, I just did a getContact (actually a Whups
function) to get their information to display.
* When a ticket is created from a guest point of view, I have them
just type in their userid (which happens to also be their e-mail
'userid@domain.com'). This change could be expanded to be a
configuration option to allow an Admin. to choose how guest tickets
are stored.
* The block layout (along with mybugs) has an "Unassigned Tickets"
listing so you can see all the tickets that haven't been picked up yet
only from the queues which you are responsible for. I also modified
it to display extra information about the ticket specifically relating
to the user.
* Added a "Take Ticket" link to make it easier to actually grab a
ticket from the queue.
* Added Whups_Ticket::ticketNumberFormat() to make the tickets a
little easier to read as I created a custom numbering system (BranchID
- year - ticketID).
* The update tab was changed to allow a ticket to go back into the
queue if the person wasn't able to handle it, accidentally grabbed it,
etc.
* The update tab actually makes you an owner if you choose "Assigned"
- but it's hardcoded which at the moment I don't like, but it works.
* A purely custom addition was that of using the turba field
['branchid'] throughout random parts of the code. This is because we
have a lot of branches so this helps us sort out tickets. Of course
this should be removed for general usage.
* Modified Whups::formatUser() to take the ID given and see if has an
identity and if not, then look it up using Turba to pull their display
name and/or e-mail address.
I'm sure all the changes aren't listed here, but I'll post them if I
think of them.