Mercurial > p > roundup > code
comparison doc/upgrading.txt @ 2138:f76d1642014a
doc cleanup, editing and creation of a What's New
| author | Richard Jones <richard@users.sourceforge.net> |
|---|---|
| date | Fri, 26 Mar 2004 06:02:20 +0000 |
| parents | ee3cf6a44f29 |
| children | 9b447ac40be3 |
comparison
equal
deleted
inserted
replaced
| 2137:c49495585c44 | 2138:f76d1642014a |
|---|---|
| 9 .. contents:: | 9 .. contents:: |
| 10 | 10 |
| 11 | 11 |
| 12 Migrating from 0.6 to 0.7 | 12 Migrating from 0.6 to 0.7 |
| 13 ========================= | 13 ========================= |
| 14 | |
| 15 0.7.0 Saving and sharing of user queries | |
| 16 ---------------------------------------- | |
| 17 | |
| 18 Due to popular demand, the user query saving mechanisms have been | |
| 19 overhauled. This means that queries remember the user that created them | |
| 20 and they may be marked as being private for a particular user. | |
| 21 | |
| 22 You *are not required* to make these changes. You only need to make them | |
| 23 if you wish to use the new query editing features. It's highly | |
| 24 recommended, as the effort is minimal. | |
| 25 | |
| 26 1. You will need to edit your tracker's ``dbinit.py`` to change the way | |
| 27 queries are stored. Change the lines:: | |
| 28 | |
| 29 query = Class(db, "query", | |
| 30 klass=String(), name=String(), | |
| 31 url=String()) | |
| 32 query.setkey("name") | |
| 33 | |
| 34 to:: | |
| 35 | |
| 36 query = Class(db, "query", | |
| 37 klass=String(), name=String(), | |
| 38 url=String(), private_for=Link('user')) | |
| 39 | |
| 40 That is, add the "private_for" property, and remove the line that says | |
| 41 ``query.setkey("name")``. The latter is the most important edit here. | |
| 42 | |
| 43 2. You will also need to copy the ``query.edit.html`` template page from the | |
| 44 ``templates/classic/html/`` directory of the source to your tracker's | |
| 45 ``html`` directory. | |
| 46 | |
| 47 3. Once you've done that, edit the tracker's ``page.html`` template to | |
| 48 change:: | |
| 49 | |
| 50 <td rowspan="2" valign="top" class="sidebar"> | |
| 51 <p class="classblock" tal:condition="request/user/queries"> | |
| 52 <b>Your Queries</b><br> | |
| 53 <tal:block tal:repeat="qs request/user/queries"> | |
| 54 | |
| 55 to:: | |
| 56 | |
| 57 <td rowspan="2" valign="top" class="sidebar"> | |
| 58 <p class="classblock"> | |
| 59 <b>Your Queries</b> (<a href="query?@template=edit">edit</a>)<br> | |
| 60 <tal:block tal:repeat="qs request/user/queries"> | |
| 61 | |
| 62 That is, you're removing the ``tal:condition`` and adding a link to the | |
| 63 new edit page. | |
| 64 | |
| 65 4. You might also wish to remove the redundant query editing section from the | |
| 66 ``user.item.html`` page. | |
| 67 | |
| 68 | |
| 69 0.7.0 Added Dispatcher role | |
| 70 --------------------------- | |
| 71 | |
| 72 A new config option has been added that specifies the email address of | |
| 73 a "dispatcher" role. This email address acts as a central sentinel for | |
| 74 issues coming into the system. You can configure it so that all e-mail | |
| 75 error messages get bounced to them, them and the user in question, or | |
| 76 just the user (default). | |
| 77 | |
| 78 To toggle these switches, add the "DISPATCHER_EMAIL" and | |
| 79 "ERROR_MESSAGES_TO" configuration values to your tracker's ``config.py``. | |
| 80 See the `customisation documentation`_ for how to use them. | |
| 81 | |
| 82 | |
| 83 0.7.0 Added CSV export action | |
| 84 ----------------------------- | |
| 85 | |
| 86 A new action has been added which exports the current index page or search | |
| 87 result as a comma-separated-value (CSV) file. | |
| 88 | |
| 89 To use it, add this to your "index" templates: | |
| 90 | |
| 91 <a tal:attributes="href python:request.indexargs_url('issue', | |
| 92 {'@action':'csv_export'})">Download as CSV</a> | |
| 93 | |
| 94 Making sure that the ``'issue'`` part matches the class name of the page | |
| 95 you're editing. | |
| 96 | |
| 97 | |
| 98 0.7.0 Typed columns in MySQL backend | |
| 99 ------------------------------------ | |
| 100 | |
| 101 The MySQL (and Postgresql for that matter) backend now creates tables with | |
| 102 appropriate column datatypes (not just varchar). | |
| 103 | |
| 104 Your database will be automatically migrated to use the new schemas, but | |
| 105 it will take time. It's probably a good idea to make sure you do this as | |
| 106 part of the upgrade when users are not expected to be using the system. | |
| 107 | |
| 108 | |
| 109 0.7.0 Permission setup | |
| 110 ---------------------- | |
| 111 | |
| 112 0.7 automatically sets up the Edit and View Permissions for all classes, | |
| 113 thus you don't need to do so. Feel free to remove the code:: | |
| 114 | |
| 115 # Add new Permissions for this schema | |
| 116 for cl in 'issue', 'file', 'msg', 'user', 'query', 'keyword': | |
| 117 db.security.addPermission(name="Edit", klass=cl, | |
| 118 description="User is allowed to edit "+cl) | |
| 119 db.security.addPermission(name="View", klass=cl, | |
| 120 description="User is allowed to access "+cl) | |
| 121 | |
| 122 from your ``dbinit.py``. | |
| 123 | |
| 124 | 14 |
| 125 0.7.0 Permission assignments | 15 0.7.0 Permission assignments |
| 126 ---------------------------- | 16 ---------------------------- |
| 127 | 17 |
| 128 Due to a change in the rendering of web widgets, permissions are now | 18 Due to a change in the rendering of web widgets, permissions are now |
| 145 for cl in 'priority', 'status': | 35 for cl in 'priority', 'status': |
| 146 p = db.security.getPermission('View', cl) | 36 p = db.security.getPermission('View', cl) |
| 147 db.security.addPermissionToRole('User', p) | 37 db.security.addPermissionToRole('User', p) |
| 148 | 38 |
| 149 | 39 |
| 150 0.7.0 New "actor" property | |
| 151 -------------------------- | |
| 152 | |
| 153 Roundup's database has a new per-item property "actor" which reflects the | |
| 154 user performing the last "actvitiy". See the classic template for ways to | |
| 155 integrate this new property into your interface. | |
| 156 | |
| 157 The property will be automatically added to your existing database. | |
| 158 | |
| 159 | |
| 160 0.7.0 Extending the cgi interface | |
| 161 --------------------------------- | |
| 162 | |
| 163 Before 0.7.0 adding or extending web actions was done by overriding or adding | |
| 164 methods on the Client class. Though this approach still works to provide | |
| 165 backwards compatibility, it is recommended you upgrade to the new approach, as | |
| 166 described in the `Defining new web actions`__ section of the customization | |
| 167 documentation. You might also want to take a look at the `Using an external | |
| 168 password validation source`__ example. | |
| 169 | |
| 170 __ customizing.html#defining-new-web-actions | |
| 171 __ customizing.html#using-an-external-password-validation-source | |
| 172 | |
| 173 | |
| 174 0.7.0 Getting the current user id | 40 0.7.0 Getting the current user id |
| 175 --------------------------------- | 41 --------------------------------- |
| 176 | 42 |
| 177 Removed Database.curuserid attribute. Any code referencing this attribute | 43 Removed Database.curuserid attribute. Any code referencing this attribute |
| 178 should be replaced with a call to Database.getuid(). | 44 should be replaced with a call to Database.getuid(). |
| 179 | |
| 180 | |
| 181 0.7.0 Email character set | |
| 182 ------------------------- | |
| 183 | |
| 184 The default character set for sending email is UTF-8 (ie. Unicode). If you | |
| 185 have users whose email clients can't handle UTF-8 (eg. Eudora) then you | |
| 186 will need to edit the new config.py variable ``EMAIL_CHARSET``. | |
| 187 | 45 |
| 188 | 46 |
| 189 0.7.0 ZRoundup changes | 47 0.7.0 ZRoundup changes |
| 190 ---------------------- | 48 ---------------------- |
| 191 | 49 |