##// END OF EJS Templates
upstream » kallithea
RSS

Clone from https://kallithea-scm.org/repos/kallithea

docs/usage: rework and rename section 'Visual settings in admin pannel'...
Thomas De Schampheleire -
r4963:daa83b2d default
parent child Browse files
Show More
Show file before | Show file after | Hide comments
@@ -1,171 +1,156 b''
1 1 .. _general:
2 2
3 3 =======================
4 4 General Kallithea usage
5 5 =======================
6 6
7 7
8 8 Repository deleting
9 9 -------------------
10 10
11 11 Currently when an admin or owner deletes a repository, Kallithea does
12 12 not physically delete said repository from the filesystem, but instead
13 13 renames it in a special way so that it is not possible to push, clone
14 14 or access the repository.
15 15
16 16 There is a special command for cleaning up such archived repos::
17 17
18 18 paster cleanup-repos --older-than=30d my.ini
19 19
20 20 This command scans for archived repositories that are older than
21 21 30 days, displays them, and asks if you want to delete them (unless given
22 22 the ``--dont-ask`` flag). If you host a large amount of repositories with
23 23 forks that are constantly being deleted, it is recommended that you run this
24 24 command via crontab.
25 25
26 26 It is worth noting that even if someone is given administrative access to
27 27 Kallithea and deletes a repository, you can easily restore such an action by
28 28 renaming the repository directory, removing the ``rm__<date>`` prefix.
29 29
30 30 Follow current branch in file view
31 31 ----------------------------------
32 32
33 33 In file view when this checkbox is checked the << and >> arrows will jump
34 34 to changesets within the same branch currently being viewed. So for example
35 35 if someone is viewing files in the ``beta`` branch and marks the `follow current branch`
36 36 checkbox the << and >> buttons will only show revisions for the `'beta`` branch.
37 37
38 38
39 39 Compare view from changelog
40 40 ---------------------------
41 41
42 42 Checkboxes in the compare view allow users to view a combined compare
43 43 view. You can only show the range between the first and last checkbox
44 44 (no cherry pick). Clicking more than one checkbox will activate a
45 45 link at the top saying ``Show selected changesets <from-rev> ->
46 46 <to-rev>``. Clicking this will activate the compare view. In this view
47 47 it is also possible to switch to combined compare.
48 48
49 49 Compare view is also available from the journal on pushes having more than
50 50 one changeset.
51 51
52 52
53 53 Non changeable repository urls
54 54 ------------------------------
55 55
56 56 Due to the complicated nature of repository grouping, URLs of repositories
57 57 can often change.
58 58
59 59 example::
60 60
61 61 #before
62 62 http://server.com/repo_name
63 63 # after insertion to test_group group the url will be
64 64 http://server.com/test_group/repo_name
65 65
66 66 This can be an issue for build systems and any other hardcoded scripts, moving
67 67 a repository to a group leads to a need for changing external systems. To
68 68 overcome this Kallithea introduces a non-changable replacement URL. It's
69 69 simply a repository ID prefixed with ``_``. The above URLs are also accessible as::
70 70
71 71 http://server.com/_<ID>
72 72
73 73 Since IDs are always the same, moving the repository will not affect
74 74 such a URL. the ``_<ID>`` syntax can be used anywhere in the system so
75 75 URLs with ``repo_name`` for changelogs and files can be exchanged
76 76 with the ``_<ID>`` syntax.
77 77
78 78
79 79 Mailing
80 80 -------
81 81
82 82 When the administrator configures the mailing settings in .ini files
83 83 Kallithea will send mails on user registration, or when Kallithea
84 84 errors occur.
85 85
86 86 Mails are also sent for code comments. If someone comments on a changeset
87 87 mail is sent to all participants, the person who commited the changeset
88 88 (if present in Kallithea), and to all people mentioned with the @mention system.
89 89
90 90
91 91 Trending source files
92 92 ---------------------
93 93
94 94 Trending source files are calculated based on a pre-defined dict of known
95 95 types and extensions. If you miss some extension or would like to scan some
96 96 custom files, it is possible to add new types in the ``LANGUAGES_EXTENSIONS_MAP`` dict
97 97 located in ``kallithea/lib/celerylib/tasks.py``.
98 98
99 99
100 100 Cloning remote repositories
101 101 ---------------------------
102 102
103 103 Kallithea has the ability to clone remote repos from given remote locations.
104 104 Currently it supports the following options:
105 105
106 106 - hg -> hg clone
107 107 - svn -> hg clone
108 108 - git -> git clone
109 109
110 110
111 111 .. note:: svn -> hg cloning requires tge ``hgsubversion`` library to be installed.
112 112
113 113 If you need to clone repositories that are protected via basic auth, you
114 114 might pass the url with stored credentials inside, e.g.,
115 115 ``http://user:passw@remote.server/repo``, Kallithea will try to login and clone
116 116 using the given credentials. Please take note that they will be stored as
117 117 plaintext inside the database. Kallithea will remove auth info when showing the
118 118 clone url in summary page.
119 119
120 120
121 121
122 Visual settings in admin pannel
123 -------------------------------
124
122 Specific features configurable in the Admin settings
123 ----------------------------------------------------
125 124
126 Visualisation settings in Kallithea settings view are extra customizations
127 of server behavior. There are 3 main sections in the settings.
125 In general, the Admin settings should be self-explanatory and will not be
126 described in more detail in this documentation. However, there are a few
127 features that merit further explanation.
128 128
129 General
130 ~~~~~~~
129 Repository extra fields
130 ~~~~~~~~~~~~~~~~~~~~~~~
131 131
132 The `Use repository extra fields` option allows to set a custom fields
133 for each repository in the system. Each new field consists of 3
134 attributes: ``field key``, ``field label``, ``field
135 description``. Example usage of such fields would be to define company
136 specific information into repositories, e.g., defining a
137 ``repo_manager`` key that would give info about a manager of each
138 repository. There's no limit for adding custom fields. Newly created
139 fields are accessible via API.
140
141 The `Show Kallithea version` option toggles displaying the exact
142 Kallithea version in the footer
143
132 In the `Visual` tab, there is an option `Use repository extra
133 fields`, which allows to set custom fields for each repository in the system.
134 Each new field consists of 3 attributes: ``field key``, ``field label``,
135 ``field description``.
144 136
145 Dashboard items
146 ~~~~~~~~~~~~~~~
147
148 Number of items in main page dashboard before pagination is displayed.
149
150
151 Icons
152 ~~~~~
153
154 Show public repo icon / Show private repo icon on repositories - defines if
155 public/private icons should be shown in the UI.
156
137 Example usage of such fields would be to define company-specific information
138 into repositories, e.g., defining a ``repo_manager`` key that would give info
139 about a manager of each repository. There's no limit for adding custom fields.
140 Newly created fields are accessible via the API.
157 141
158 142 Meta-Tagging
159 143 ~~~~~~~~~~~~
160 144
161 With this option enabled, special metatags that are recognisible by Kallithea
162 will be turned into colored tags. Currently available tags are::
145 In the `Visual` tab, option `Stylify recognised meta tags` will cause Kallithea
146 to turn certain meta-tags, detected in repository and repository group
147 descriptions, into colored tags. Currently recognised tags are::
163 148
164 149 [featured]
165 150 [stale]
166 151 [dead]
167 152 [lang => lang]
168 153 [license => License]
169 154 [requires => Repo]
170 155 [recommends => Repo]
171 156 [see => URI]
General Comments 0
You need to be logged in to leave comments. Login now