Etics Support Infrastructure

Task Description

When Etics Users find a problem using Etics System they have to create a ticket on ggus portal ( explaining the issue, asking help to the Etics Support Infrastructure

Etics Support Infrastructure is structured into two main parts:

First Level Support which is responsible for solving problems when this is possible and to collect informations usefull for the secondary level support

Secondary Level Support (Etics Experts) which is responsible to investigate on tickets when the issue is too much difficult for the First Level support because solving the problem requires a very deep knowledge of the Etics System.

Next chapters are written to explain support procedures for the Etics support team.

GGUS official guide for supporters

1 Registration

All information about registration can be found on the registration page. The link to this page is located in the top navigation bar (see Figure 1).

  • Figure 1 Link to the registration page:

1.1 Registering as support staff

To register as support staff, click the link “Apply” and fill in the registration form. After registering successfully you will receive a confirmation mail from GGUS.

  • Figure 2 Getting support access:

3 Access to Grid HelpDesk web interface

Up to now, there are two different ways for getting access to the Grid HelpDesk web interface. One way is to use the link in the GGUS portal. GGUS portal is located at or . In the GGUS portal there is a link named “Support staff” (see Figure 3). After clicking this link a new window opens demanding your authentication if you are not using a valid grid certificate.

  • Figure 3 Link “Support staff” in GGUS portal:

After authenticating yourself you are guided to another page where you can find links to Grid HelpDesk web interface on the left hand side (see Figure 4).

  • Figure 4 Links to Grid HelpDesk web interface in GGUS portal:

Another way is to use the direct link provided in the notification mail support staff receives when a ticket is assigned to him or his support unit.

4 Support staff page

Besides the links for entering GGUS helpdesk system support staff page offers a collection of useful links for supporters and administrators (see Figure 5). These links are not described in detail in this document. New features are shown with red triangles until next release.

  • Figure 5 Support staff page offering useful links for supporters:

4.1 Updating supporter’s user data

If you want to update your user data i.e. password, DN string of your browser certificate etc. you can do this using the link “Check/update your GGUS account” (see Figure 6).

  • Figure 6 Link for updating user data:

4.1.1 Updating certificate DN

If you can’t access GGUS web interface due to changed DN string in your browser certificate you can log into the system using login/password. Then click on “Check/update your GGUS account”. The system shows you all your user data. It detects the new DN string of your browser automatically (see Figure 7). You only need to save the changes by clicking on button “Update now”.

  • Figure 7 Updating DN string after installing a new certificate:

5 Layout of web interface

The two major parts of the web interface are the search engine and the result list. The result list is showing a colour schema reflecting the priority of tickets. The algorithm used for setting the priority colours is explained in chapter 8 Reminder emails. The first time you use this, the search area of Grid HelpDesk web interface is shown (see Figure 8). As default, all open tickets of last week are shown in the result list.

  • Figure 8 Search section of new Grid HelpDesk web interface:

They were ordered by date of creation in descending manor (see Figure 9). For further details on using the search engine see chapter 6 Searching for tickets.

  • Figure 9 Result list of new search engine:

5.1 Ticket information

The system shows the information section after clicking on a ticket ID. It provides an overview of all relevant ticket parameters and could be divided into 5 areas: submitter data, problem data, ticket data, description and solution (see Figure 10).

  • Figure 10 Ticket information after clicking on a ticket ID:

5.2 Duplicate ticket

Supporters have the opportunity to duplicate an existing ticket up to 5 times (see Figure 11). It is located right below ticket information.

  • Figure 11 Duplicate tickets:

This feature is useful if a ticket concerns not only one support unit but has to be handled by several support units. When duplicating a ticket the user gets a notification for every duplicate automatically.

5.3 Ticket history

The ticket history is located below ticket information. It shows all relevant changes of the ticket in chronological manner. Changes of these fields lead to a new entry in ticket history:

  • Assign ticket to support unit

  • Assign ticket to one person

  • Change status

  • Change VO

  • Change priority

  • Involve others

  • Type of problem

  • Internal Diary

  • Solution

  • Related issue

  • VO specific

For making the history more readable solution entries and entries in the public diary are marked with green colour, entries of the internal diary with orange colour (see Figure 12).

  • Figure 12 Ticket history:

5.4 Ticket modification

The ticket modification area offers several fields for modifying a ticket. The fields are described in detail below.

  • Figure 13 Modify section part - 1:

  • Assign ticket to support unit: Provides a dropdown-list of possible support units involved in Global Grid User Support.

  • Assign ticket to one person: Allows assigning tickets to a dedicated person within the current support unit. If a mail address is typed in the system generates an email to inform the recipient about the ticket assignment. The length is limited to 254 characters.

  • Change status: Provides a dropdown-list of possible status values.

  • Change VO: Provides a dropdown-list of possible VO values.

  • Type of problem: Provides a dropdown-list of possible problem types.

  • Change priority: Provides a dropdown-list of possible priority values.

  • Affected Site: The site affected by the problem could be specified here. Clicking on the question mark icon guides you to the GOC DB for getting more information about sites.

  • Involve others: Allows contacting any people who may help to solve a problem. Several mail addresses can be typed in, separated by commas. The length is limited to 254 characters.

  • VO specific?: Flag that indicates whether a problem is VO specific or not. Default is “no”.

  • Add to WIKI?: This flag indicates that a solution is suggested to be put into the GOC WIKI pages as an example solution. Default is “no”.

  • Internal Diary: This field can be used for internal remarks. It is never shown to the user. It is limited to 4000 characters.

  • Public Diary: An entry in this field always triggers an update mail to the user. It is limited to 4000 characters.

  • Click here to insert.... Expands the window and makes solution field visible (see Figure 14).

  • Figure 14 Modify section – part 2:

  • - Solution: This field can be up to 4000 characters. It is used for explaining the solution.

  • -Hide solution Collapses window and hides solution field.

  • Figure 15 Modify section – part 3:

  • - Reminders flag: This flag can be set to “Please send reminder on” if status is changed to “on hold” or “waiting for reply”. In this case a date can be selected on which a reminder mail was sent. This feature should help supporters not to forget tickets which were not worked on for a longer time.

  • - Related issue: This field can be used to reference other systems not interfaced with GGUS e.g. CERN savannah bug ID or a URL leading to any site. It is limited to 125 characters.
  • - Click here to expand .... Expands the window and makes the ticket relation section visible.

  • Figure 16 Modify section – part 4:

  • Hide ticket relation section: Collapses window and hides ticket relation fields.

  • Mark this ticket as Master: Usage of this feature is described in detail in chapter 5.5 Master-Slave relations.

  • Mark this ticket as Slave: Usage of this feature is described in detail in chapter 5.5 Master-Slave relations.

  • Mark this ticket as child: Usage of this feature is described in detail in chapter 5.6 Parent-child relation.

  • Cross reference: Allows referencing as much other GGUS tickets as you want. For each ticket you reference here a symmetric link is added to the referenced ticket automatically.

  • - Want to upload attachment?: For further information attachments can be added. Only one attachment can be added at a time. The total number of attachments is unlimited.

5.5 Master-Slave relations

Several tickets describing the same problem can be put into a master-slave relation. One of them can be marked as master, the other ones as slave. Only the master ticket has to be dealt with. The slave tickets are set to “on hold”. They can’t be updated directly as long as they are in a master-slave relation. The user gets an automated notification if a ticket is marked as slave. All updates of the master were pushed to the slaves. When solving the master the slaves are solved to. The master-slave relation is reset after the master is solved. A master-slave relation can be reset manually either by removing the master ID of a slave ticket or by unmarking the checkbox of a master. If a master is unmarked as master all slaves were reset to “standard” tickets automatically.

  • Figure 17 Mark ticket as slave:

5.5.1 Selecting slave tickets
Marking a ticket as slave is only possible if there is already a master ticket. If a ticket is marked as slave a popup window opens showing available master tickets. For selecting a master just click on the ID (see Figure 17). The master ID is set automatically. Once you have chosen a wrong master ID click on “Reset Master ID” and select another one. 5.5.2 Showing a master’s slave tickets To show all related slave tickets click on link “show slaves for this ticket”. A popup window opens showing the IDs of all slave tickets (see Figure 18).

  • Figure 18 Showing slave tickets for master:

5.5.3 Searching for master/slave tickets
If you want to search for master or slave tickets you can do this using field “Special attributes” of the search engine (see Figure 19). The status value for searching is set to an appropriate value accordingly.

  • Figure 19 Searching for master/slave tickets:

5.6 Parent-child relations

Parent-child relations are working vice versa to the master-slave relations. The parent ticket could not be solved until all its child tickets are solved. The parent ticket is set to status “on hold” while the child tickets are waiting for their solution.

  • Figure 20 Ticket information section of a parent ticket:

For each solved child ticket a note is added to the parent ticket’s history including the solution of the child ticket. After the solution of the last open child ticket the status of the parent ticket changes to “in progress” automatically. Additionally the system sends a notification mail to the responsible support unit telling that all child tickets are solved now. So the parent ticket can be “solved” too.

5.6.1 Selecting child tickets

  • Figure 21 Selecting a ticket as child ticket:

A ticket can be selected as child ticket by checking the box “Mark this ticket as child of ticket” and adding the ticket ID of the parent ticket (see Figure 21). A comment is added to the ticket history automatically stating “This ticket is a child ticket of GGUS ticket # 18492”. The parent ticket is flagged as “parent” automatically. A comment is added to the ticket history automatically stating “This ticket is a parent ticket. It has to wait the solving of all its child tickets. GGUS ticket #18493 is a child to this ticket.“ (see Figure 22).

  • Figure 22 Comments in history of parent tickets:

5.6.2 Selecting parent tickets

Selecting a parent ticket explicitly is not possible. The parent tickets are flagged automatically by the system while the parent ID is specified for a child ticket (see Figure 21).

5.6.3 Searching for parent/child tickets

The search for parent or child tickets is similar to the search for master or slave tickets. It can be done using field “Special attributes” of the search engine (see Figure 19).

5.7 Mail to anybody

Mail to anybody allows sending an email to any person wanted. The content of the mail is added to the ticket history. The subject line and the sender address are pre-filled and should not be changed.

  • Figure 23 Mail to anybody:

6 Searching for tickets

Various possibilities of searching tickets in GGUS are described in this chapter. Please avoid searching for “all” tickets or “solved” tickets without any timeframe if not necessary for some reasons as these searches cause heavy load on the machine.

6.1 Searching via Ticket ID

Searching via ticket ID is the easiest and fastest way to look at a ticket. When searching via Ticket ID all other search parameters are ignored. Besides searching for all open tickets this is the recommended kind of search, because it avoids needless workload on the system.

  • Figure 24 Ticket search engine:

When searching via ticket ID the ticket details are shown in the same window. For getting back to the main page use the “Back” button of your browser.

6.2 Searching via parameters

The search parameters can be combined in any way wanted. Description fields “Keyword”, “Involved supporter” and “Assigned to person” trigger a LIKE search to the database. Concatenating keywords with “AND” or “OR” is currently not possible. The result of a search by parameters is shown in the result list. For viewing ticket details just click on the ID. A new window opens showing ticket details. For getting back to the search result just close the window with the ticket details.

7 Working on tickets

This section is a description of how the GGUS ticketing system behaves. There are other documents which describe the system in more detail and include more of the implementation details.

7.1 User ticketing work flow

There are two lines of support in GGUS:

  • 1. First line of support gets immediate notification of tickets;
  • 2. Second line of support is only notified of tickets by the first line of support.
There are two parts to the first line support:
  • 1. One part of first line support puts the VO support unit at the front of the user ticketing process. The system provides the end user with an e-mail interface to the VO support unit. The user sends an e-mail and gets replies about the email until the problem is solved. This arrangement makes it easy for VOs to provide a web front end for their support. They can provide documentation and other information relevant to the users of the VO and provide access to the support for the user with a simple button which generates an e-mail.
  • 2. The other part is an organisation called TPM – ticket processing management. TPM is an organisation populated by people provided from the federations on a rotating basis. This organisation is responsible for the monitoring of all active tickets. The responsibility for the provision of people for TPM rotates weekly among the federations.
The GGUS Support is organized with two main lines of support. The first line is formed from two teams, one of grid generalists (TPM), and the other of VO generalists (VO support). The grid team has members who have very good general grid knowledge. The VO team has members who have specific VO knowledge. In this way, a problem submitted to GGUS can be quickly identified as either a grid problem or a VO specific problem and addressed to the appropriate second line specialized support units. The second line support is formed by many support units. Each support unit is formed from members who are specialists in various areas of grid middleware, or ROC supporters for operations problems, or VO specific supporters. The membership of the support units is maintained on mailing lists. A single e-mail address is available through which users can request GGUS for help. E-mails sent to this address are automatically converted into tickets and treated by the system. GGUS at FZK provides a hot line for supporters to help them with the procedures involved in solving tickets. The user can submit a ticket for support by sending e-mail to a mailing address. The name of the mailing address indicates the VO to which the user belongs. For example, the user can submit a ticket to: where VO is one from the following list: VO = {alice, atlas, auger, biomed, cdf, cms, compchem, dteam, egeode, egrid, esr, gaussian, geant4, hone, ilc, lhcb, magic, ops, planck, zeus}.

The user then receives email from with:

  • request for further information;
  • notification of change of status including solved. Up to now the user only gets notification when solving his ticket.
If the user responds to any of these e-mails, then the reply is added to the ticket history. The subject of the email includes Meta data to ensure the association of the response with the ticket. The response includes the ticket history not the complete history but the current status of the ticket and a link to the ticket within GGUS. To use the link requires that the user have a digital certificate in his/ her browser to see the ticket. If the user does not know which VO list to use, then the user can use the generic mail address for GGUS which is called: The work flow is summarised in the following figures: Figure 25 and Figure 26.

7.2 Advice for TPMs

The following advice is intended for people working on TPM.

  • 1. Change support unit to “TPM” if you are working on a ticket;
  • 2. Just typing a comment into solution field does NOT cause an email to the user automatically. Only changing status to “solved” causes an automatic mail. If you want to contact the user you can do this using the “Public Diary”;
  • 3. Change status to “waiting for reply” while waiting for the user's reply (or the reply of any other person);
  • 4. Be careful when using the field “Assign ticket to one person”. Please avoid using mailing list names, or the mail list address of a remote helpdesk system. With a mailing list, the mail may not reach the recipient because many mailing lists are closed lists and will not accept the message. Sending mail to a remote helpdesk system can confuse the remote system and lead to trouble.
  • 5. If you receive a ticket which has obviously been created by a spam e-mail getting through the spam filter, then you mark it with a special type of problem called “Spam”. Change the type of problem to “Spam” and close the ticket setting status to “solved”. Spam tickets are deleted from the system after one week automatically.

7.3 Forwarding a ticket to another unit

Tickets are normally assigned to a support unit. This means that the ticket is sent to a mailing list composed of many supporters. One of these supporters assigns the ticket to himself and takes responsibility for it; the supporter changes the status to “in progress” (see Figure 27).

  • Figure 27 Assigning ticket to one person to take responsibility:

If an “urgent” or “top priority” ticket remains in status “assigned” but not “in progress” for more than 2 hours (no supporter has assigned the ticket to him/herself), TPM assigns the ticket to one person in the support unit. This person is then in charge of the ticket. He either solves it or reassigns the ticket to somebody else. The status of the ticket stays set to “in progress” if the ticket is under the responsibility of one supporter and until the ticket has been solved. If an “urgent” or “top priority” ticket stays on hold for more than 2 days, then TPM is responsible for following the ticket and ensuring that a solution is found.

7.4 Solving a ticket

In this chapter the usage of the different status values and input fields is described.

7.4.1 Which status value shall I choose?

The system offers two groups of meta states, open states and terminal states.

Open states

  • new: this is the default status for submitted tickets. It is set by the system and can’t be selected in the drop-down list menu.

  • assigned: after a ticket is assigned to a support unit, this unit is informed via e-mail about the ticket assignment. As long as status value is “assigned” escalation mails are sent every two hours to remind the support unit of this ticket.

  • in progress: support staff who work on the ticket should change status to “in progress”. This is necessary to announce that somebody is taking care of this ticket and is working on it. Additionally escalation mails are sent on a lower frequency than on status “assigned”.

  • waiting for reply: when asking the user (or anyone else) for further information, status should be changed to “waiting for reply”. The supporter can decide whether he wants to be notified about this ticket by the system. He can choose any date in the future he wants to be notified and select the radio button “Please send reminder on”.

  • on hold: some tickets are not solvable while needing a software patch or something similar for example. The reasons should be explained in field “Public Diary”. Additionally a hint in field “Related issue” may be useful. The supporter can decide whether he wants to be notified about this ticket by the system. He can choose any date in the future he wants to be notified and select the radio button “Please send reminder on”.

  • reopened: normally this status value is set by the user, if he is not happy with the provided solution. It can also be used by supporters if a better solution is found for a ticket already solved. In this case status should be set to “reopened”, new solution put in and status changed to “solved” again. Leaving status as “solved” and just putting in the new solution does not cause an automatic solution mail to the user.

Terminal states

  • solved: if a solution is found and put into the appropriate fields status has to be set to “solved”. Only on status change to “solved” the user receives a solution mail automatically.

  • unsolved: This status is for tickets that can not be solved due to any reason. It should also be used for tickets related to a known savannah bug (see chapter 7.4.3 How shall I handle tickets related to a known savannah bug?).

  • verified: can only be set by the ticket submitter. Supporters can only search for tickets in status “verified”. This status indicates that a user is happy with the provided solution. The user is invited to verify the solution, but if he does not verify it the ticket rests in status “solved”.

7.4.2 Which fields shall I fill in?

Single steps of the solution process can be documented in field “Public Diary”. Information and comments which should not be visible to the user can be put into the “Internal diary”. When a solution is found, the modifier types the solution into the solution field and changes status to "solved". The “Solution” field provides 4000 characters. If 4000 characters are not sufficient, please add an attachment. After changing status to “solved” and saving all changes, the solution is sent to the submitter via mail automatically. Tasks for solving a ticket:

  • change status to “in progress”,
  • fill in the solution fields and the internal diary if necessary,
  • change the status to “solved” and you are done.

7.4.3 How shall I handle tickets related to a known savannah bug?

Tickets that are related to a known bug in the CERN savannah system can be closed with the final status “unsolved”. They require 3 actions:

  • add a comment in the solution field,
  • add the link to the savannah bug to the “Related issue” field and
  • change the status to “unsolved”.
The user could track the progress in the CERN savannah system.

7.5 Unsolving a ticket

When a ticket remains too much time in Waiting For Reply status without receiving any answer the status goes unsolved. In detail if the status remains in Waiting For Reply for a month then the person who tracked the ticket has to contact again with ggus the user asking if the ticket could be closed, if in a week no answer arrives then the ticket must be closed and the status goes unsolved.

7.6 Reporting FAQs

After the ticket has been closed succesfully the person in shift must analyze it again to understand if some general issue description can be extracted from that use case and if this is true, the related FAQ has to be added on the etics support portal troubleshooting page.

8 Reminder emails

Reminder mails are based on the priority colours. The algorithm of setting priority colours is described in the following chapters.

8.1 What are the priority colours?

Priority colours are:

  • Green: default for all new tickets,
  • Yellow,
  • Amber,
  • Red,
  • Light blue: for all tickets on hold,
  • Blue: for all solved, unsolved and verified tickets.
Priority colours depend on the expected solution time of a ticket.

8.1.1 Expected solution times

The expected solution times are driven by the priority values of the tickets. The higher the priority the shorter is the duration within which the ticket is expected to be solved (see Table 1).

  • Table 1 Expected solution times:

8.1.2 Algorithm of priority colours

The algorithm of calculating the priority colours is: (current timestamp – date of ticket creation)/expected solution time = colour value The mapping of the colour values with the priority colours is shown in Table 2.

  • Table 2 Mapping of colour values with priority colour:

9 Week Statistics

Here we report the average calculated by each week statistic, the average is done taking count first for each week of the tickets solved, redirected or waiting and then the average between weeks is done.

Actually calculated between the last 26 weeks (number of tickets, average time in hour):

  • arrived in media (2.53)
  • solved in media (1.043, 4.021 h)
  • redirected in media (1.173, 3.85 h)
  • waiting for reply in media (0.652, 3.52 h)

Topic attachments
I Attachment History Action Size Date Who Comment
JPEGjpg AssigningTicket.jpg r1 manage 20.0 K 2009-07-02 - 14:00 MicheleCarpene Figure 27 Assigning ticket to one person to take responsibility
Microsoft Word filedoc GGUS.doc r1 manage 713.5 K 2009-06-30 - 10:26 MicheleCarpene GGUS Deliverable doc
JPEGjpg LinkUpdating.jpg r2 r1 manage 11.3 K 2009-06-30 - 13:58 MicheleCarpene Figure 6 Link for updating user data
JPEGjpg StaffPage.jpg r1 manage 62.8 K 2009-06-30 - 12:24 MicheleCarpene Figure 5 Support staff page offering useful links for supporters
JPEGjpg anybodymail.jpg r1 manage 25.7 K 2009-07-02 - 13:50 MicheleCarpene Figure 23 Mail to anybody
JPEGjpg childticket.jpg r1 manage 27.7 K 2009-07-02 - 13:46 MicheleCarpene Figure 21 Selecting a ticket as child ticket
JPEGjpg colourmapping.jpg r1 manage 6.8 K 2009-07-02 - 14:15 MicheleCarpene Table 2 Mapping of colour values with priority colour
JPEGjpg commentshistory.jpg r1 manage 18.1 K 2009-07-02 - 13:47 MicheleCarpene Figure 22 Comments in history of parent tickets
JPEGjpg duplicate.jpg r1 manage 12.5 K 2009-06-30 - 14:06 MicheleCarpene Figure 11 Duplicate tickets
JPEGjpg ggusImage.jpg r1 manage 20.8 K 2009-06-30 - 11:59 MicheleCarpene ggus image registration
JPEGjpg ggusImage2.jpg r1 manage 20.8 K 2009-06-30 - 12:10 MicheleCarpene Figure 3 Link “Support staff” in GGUS portal.
JPEGjpg history.jpg r1 manage 47.6 K 2009-06-30 - 14:09 MicheleCarpene Figure 12 Ticket history
JPEGjpg information.jpg r1 manage 26.8 K 2009-06-30 - 14:05 MicheleCarpene igure 10 Ticket information after clicking on a ticket ID
JPEGjpg list.jpg r1 manage 50.1 K 2009-06-30 - 14:03 MicheleCarpene Figure 9 Result list of new search engine
JPEGjpg master-slave.jpg r1 manage 47.5 K 2009-07-02 - 11:50 MicheleCarpene Figure 17 Mark ticket as slave
JPEGjpg modification.jpg r1 manage 38.9 K 2009-06-30 - 14:12 MicheleCarpene Figure 13 Modify section part - 1
JPEGjpg modify.jpg r1 manage 23.7 K 2009-07-02 - 11:45 MicheleCarpene Figure 15 Modify section – part 3
JPEGjpg modify4.jpg r1 manage 28.8 K 2009-07-02 - 11:47 MicheleCarpene Figure 16 Modify section – part 4
JPEGjpg registrationlayer.jpg r1 manage 85.0 K 2009-06-30 - 12:06 MicheleCarpene Figure 2 Getting support access
JPEGjpg search.jpg r1 manage 32.9 K 2009-06-30 - 14:02 MicheleCarpene Figure 8 Search section of new Grid HelpDesk web interface
JPEGjpg searchingmaster.jpg r1 manage 40.3 K 2009-07-02 - 12:25 MicheleCarpene Figure 19 Searching for master/slave tickets
JPEGjpg showing-slave.jpg r1 manage 57.8 K 2009-07-02 - 12:22 MicheleCarpene Figure 18 Showing slave tickets for master
JPEGjpg solution.jpg r1 manage 13.4 K 2009-07-02 - 11:39 MicheleCarpene Figure 14 Modify section – part 2
JPEGjpg solutiontimes.jpg r1 manage 6.6 K 2009-07-02 - 14:14 MicheleCarpene Table 1 Expected solution times
JPEGjpg supportstaff.jpg r1 manage 15.3 K 2009-06-30 - 12:14 MicheleCarpene Figure 4 Links to Grid HelpDesk web interface in GGUS portal.
JPEGjpg ticketengine.jpg r1 manage 34.3 K 2009-07-02 - 13:52 MicheleCarpene Figure 24 Ticket search engine
JPEGjpg ticketinformation.jpg r1 manage 13.3 K 2009-07-02 - 12:26 MicheleCarpene Figure 20 Ticket information section of a parent ticket
JPEGjpg updating.jpg r1 manage 41.4 K 2009-06-30 - 13:59 MicheleCarpene Figure 7 Updating DN string after installing a new certificate
JPEGjpg workflow.jpg r1 manage 66.7 K 2009-07-02 - 13:56 MicheleCarpene igure 25 Work flow for a ticket entered to
JPEGjpg workflow2.jpg r1 manage 66.6 K 2009-07-02 - 13:57 MicheleCarpene Figure 26 Work flow for a ticket entered to
Edit | Attach | Watch | Print version | History: r14 < r13 < r12 < r11 < r10 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r14 - 2009-12-14 - unknown
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    ETICS All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback