Mercurial > libervia-backend
comparison doc/jp/ticket.rst @ 3041:72583524cfd3
doc (jp): jp commands are now fully documented:
rel 232
author | Goffi <goffi@goffi.org> |
---|---|
date | Tue, 01 Oct 2019 22:49:06 +0200 |
parents | |
children |
comparison
equal
deleted
inserted
replaced
3040:fee60f17ebac | 3041:72583524cfd3 |
---|---|
1 ================================= | |
2 ticket: create and manage tickets | |
3 ================================= | |
4 | |
5 Ticket is a generic tools to create items with metadata and states (where state can be | |
6 ``queued``, ``done``, etc). This can be used for many things, from TODO list to bugs | |
7 management. | |
8 | |
9 get | |
10 === | |
11 | |
12 Retrieve one or more tickets and display them. A project may use magic string in README to | |
13 indicate PubSub service and node to use, in which case use just need to be in the | |
14 directory of the project. | |
15 | |
16 examples | |
17 -------- | |
18 | |
19 Retrieve last 5 tickets (ordered by creation) from a project using magic string in README:: | |
20 | |
21 $ jp ticket get -m 5 -o creation | |
22 | |
23 Retrieve the ticket with id ``123`` on service ``pubsub.example.org``:: | |
24 | |
25 $ jp ticket get -s pubsub.example.org -i 123 | |
26 | |
27 | |
28 | |
29 import | |
30 ====== | |
31 | |
32 Import tickets from an external source. This works in the same way as | |
33 :ref:`jp-blog_import`: you need to specify an importer and a data location. If you let | |
34 both positional argument empty, you'll get list of importers, if you specify importer but | |
35 not data location, you'll get a description on how the importer works. | |
36 | |
37 If you want to see a progress bar for the import, use the ``-P, --progress`` option, this | |
38 is recommended for most imports. | |
39 | |
40 Some importers may have specific option (check description for details), you can specify | |
41 them with ``o NAME VALUE, --option NAME VALUE`` | |
42 | |
43 When you import a ticket, the ticket will be created according to the schema of the PubSub | |
44 node. By default, the metadata of the original ticket will be put to the one of the same | |
45 name in the dest PubSub item. But of course the schema of your destination PubSub node may | |
46 differ from the original metadata. In this case, you can use ``-m IMPORTED_FIELD | |
47 DEST_FIELD, --map IMPORTED_FIELD DEST_FIELD`` to specify how the mapping mus be done | |
48 (``IMPORTED_FIELD is the name of the field in the original ticket, while ``DEST_FIELD`` if | |
49 the name of the field in your node schema). | |
50 | |
51 | |
52 examples | |
53 -------- | |
54 | |
55 Get list of ticket importers:: | |
56 | |
57 $ jp ticket import | |
58 | |
59 Get description of ticket importer for Bugzilla:: | |
60 | |
61 $ jp ticket import bugzilla | |
62 | |
63 Import tickets from a Bugzilla XML export file at ``~/bugzilla_export.xml`` to the | |
64 ``pubsub.example.org`` PubSub service. We use default tickets node and want a progression | |
65 bar:: | |
66 | |
67 $ jp ticket import -P -s pubsub.example.org ~/bugzilla_export.xml | |
68 | |
69 Same import, but this time we want to map the field ``assigned_to_name`` from Bugzilla to | |
70 the field ``assigned_to`` in our schema:: | |
71 | |
72 $ jp ticket import -P -s pubsub.example.org -m assigned_to_name assigned_to ~/bugzilla_export.xml |