Changes between Version 45 and Version 46 of TracTicketsCustomTimeFields
- Timestamp:
- Jun 22, 2016, 7:48:17 PM (8 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
TracTicketsCustomTimeFields
v45 v46 1 = Custom Ticket Time Fields = 2 3 ''DONE This proposal has been integrated for the [milestone:1.1.1] release. See #1942 for more details about the integration process.'' 4 5 This page presents information on adding a new type 'time' to the list of all currently available [wiki:TracTicketsCustomFields custom ticket fields].[[BR]] 6 You may want to start by reading the [wiki:TracDev/Proposals/TracTicketsCustomTimeFields proposal page], that has more general information on this project. 7 8 == !HowTo testing == 9 As stated above, the code has finally been pushed to Trac development branch and is `trunk` r11333, accompanied by a fresh jQuery date-picker implementation. 10 11 ''Note: Information below is outdated now. Please checkout current `trunk` and report your findings.'' 12 13 == Code review == 1 = Custom Ticket Time Fields 2 3 {{{#!box info 4 '''Notice''' This proposal has been integrated for the [milestone:1.1.1] release. See #1942 for more details about the integration process. 5 }}} 6 7 This page describes adding a new custom field type 'time' to the list of the currently available [wiki:TracTicketsCustomFields custom ticket fields]. You may want to read the [wiki:TracDev/Proposals/TracTicketsCustomTimeFields proposal page], that has more general information on this project. 8 9 == !HowTo testing 10 11 As stated above, the code has been added to Trac development branch in `trunk` r11333, accompanied by a fresh jQuery date-picker implementation. 12 13 '''Note''': Information below is outdated now. Please checkout current `trunk` and report your findings. 14 15 == Code review 16 14 17 Proposed code changes for Trac `trunk` reside in a Mercurial repository at bitbucket.org: 15 18 … … 20 23 The patches will not always apply cleanly to current Mercurial tip/SVN HEAD. But re-basing is easy with MQ, and this has potential to drive even rapid development towards custom time field support ^note 2^. 21 24 22 You're invited to pull right now, but save a backup of your d b before testing, please. I never broke the db of my development system. However, there might still lure some serious bugs, that I'm currently not aware of but could hit you, so you may need your backup to recover from a bad db. You've been warned. See [#KnownBugs Known Bugs] for more details.25 You're invited to pull right now, but save a backup of your database before testing, please. I never broke the database of my development system. However, there might still lure some serious bugs, that I'm currently not aware of but could hit you, so you may need your backup to recover from a bad database. You've been warned. See [#KnownBugs Known Bugs] for more details. 23 26 24 27 Feedback could happen through … … 30 33 * push to the Mercurial Queue after initial per-arrangement inside bitbucket.org (current Trac core developers enabled in advance) 31 34 32 I urge you to report back on any failure from code review or your testing. For test results, as always, mention your local setup (Trac version/revision, if not taken from my repo, Mercurial revision id of the patches). Any feedback will help to make the patches ready for production and later bring the code into Trac itself. That was my goal right from the start, not to produce just another [http://trac-hacks.org Trac hack]. 33 34 === Notes === 35 1. The common setup for Mercurial Queue puts the patches aside the main repository - into a Mercurial repo on it's own. So looking at [https://bitbucket.org/hasienda/trac-1942/changesets the changes] during development is as easy as looking at development in any repository. 36 2. Since there is no other sane way to push changes to a public repository without making them irreversible, this look like the ideal compromise until substantial clearing with core Trac developers has been reached. However, some code already got forwarded for adoption into Trac `trunk`, like the one published in #9209). 37 38 For help on applying the patches to Trac trunk source the traditional way, i.e. with {{{patch}}}, look at the patch documentation in the [https://bitbucket.org/hasienda/trac-1942/src/tip/series series] file. 35 I urge you to report back on any failure from code review or your testing. For test results, as always, mention your local setup (Trac version/revision, if not taken from my repo, Mercurial revision id of the patches). Any feedback will help to make the patches ready for production and later bring the code into Trac itself. That was my goal right from the start, not to produce just another [https://trac-hacks.org Trac hack]. 36 37 === Notes 38 39 1. The common setup for Mercurial Queue puts the patches aside the main repository - into a Mercurial repo on it's own. So looking at [https://bitbucket.org/hasienda/trac-1942/changesets the changes] during development is as easy as looking at development in any repository. 40 . Since there is no other sane way to push changes to a public repository without making them irreversible, this look like the ideal compromise until substantial clearing with core Trac developers has been reached. However, some code already got forwarded for adoption into Trac `trunk`, like the one published in #9209). 41 42 For help on applying the patches to Trac trunk source the traditional way, ie with {{{patch}}}, look at the patch documentation in the [https://bitbucket.org/hasienda/trac-1942/src/tip/series series] file. 39 43 40 44 But you'll see, Mercurial will save you and me some time and hassle, even more for true collaboration on bugs and feature requests. For the lazy or impatient ones not familiar with Mercurial I recommend to go along the lines of the following walk-through (Debian way). 41 45 42 === Before you start === 43 I tested this on my own, really, but can't guarantee and so can't be responsible on behalf of you for any action on your system. Please try to understand, what you type and think twice. Look at documentation I referenced as [#Externalrelatedresources external related resources] at the bottom of this page. Be careful especially while you act as root, and at the very least '''don't blame me''' for any mess YOU did. 44 45 === Quickstart === 46 I assume that you'll have all pre-requisites like Python, setup-tools, Genshi and optionally Babel for the i18n support in place. If you're unsure or have issues with following procedure, look at the current [wiki:TracInstall Trac Install Guide] before crying at me. 47 48 {{{ 46 === Before you start 47 48 I tested this on my own, really, but can't guarantee and so can't be responsible on behalf of you for any action on your system. Please try to understand, what you type and think twice. Look at documentation I referenced as [#Externalrelatedresources external related resources] at the bottom of this page. Be careful, especially while you act as root. 49 50 === Quickstart 51 52 I assume that you have all pre-requisites like Python, setup-tools, Genshi and optionally Babel for the i18n support in place. If you're unsure or have issues with following procedure, look at the current [wiki:TracInstall Trac Install Guide]. 53 54 {{{#!sh 49 55 $> apt-get install mercurial 50 56 $> mkdir ~/trac0.12-dev_custom-time … … 67 73 }}} 68 74 69 That will 75 That will: 70 76 * install Mercurial, if not installed before, 71 77 * get Trac trunk sources from my Mercurial repo, … … 74 80 * build Trac with custom time fields support and 75 81 * install it to your system, provided you have root permission or equivalent with sudo and last but not least 76 * fire up the standalone webserver tracd hosting a trac environment you've prepared before.77 78 You may have {{{/usr/bin/tracd}}} and {{{/usr/local/bin/tracd}}} than at different versions. Install to /usr/local will normally overrule the other Trac installation without replacing it. So calling just {{{tracd}}} will kick {{{/usr/local/bin/tracd}}}. However, just make sure, you always know, what is going on. (I mention all this because I messed up on my own and now refrain from having multiple versions at the same system at a time.)79 80 Second {{{hg -v qpush}}} command from above is optional, but recommended to get verbose information from Trac log file, when Trac is configured with log level DEBUG, i .e.with a section in your trac.ini like the following:81 {{{ 82 * fire up the standalone webserver tracd hosting a Trac environment you've prepared before. 83 84 You may have {{{/usr/bin/tracd}}} and {{{/usr/local/bin/tracd}}} than at different versions. Install to /usr/local will normally overrule the other Trac installation without replacing it. So calling just {{{tracd}}} will kick {{{/usr/local/bin/tracd}}}. However, just make sure, you always know, what is going on. I mention all this because I messed up on my own and now refrain from having multiple versions at the same system at a time. 85 86 Second {{{hg -v qpush}}} command from above is optional, but recommended to get verbose information from Trac log file, when Trac is configured with log level DEBUG, ie with a section in your trac.ini like the following: 87 {{{#!ini 82 88 [logging] 83 89 log_file = trac.log … … 85 91 log_type = file 86 92 }}} 93 87 94 See [wiki:TracLogging Trac Logging] for more details on the matter. 88 95 89 === Notes === 90 ==== Mercurial install/setup on Ubuntu 10.04 LTS ("Lucid Lynx") ==== 96 === Notes 97 98 ==== Mercurial install/setup on Ubuntu 10.04 LTS ("Lucid Lynx") 99 91 100 On Ubuntu, you will have to ''apt-get install mercurial mercurial-common'' in order to get mercurial working. 92 101 In addition, you will have to add the following entries to ''/etc/mercurial/hgrc'': … … 102 111 Without these two entries, the above sequence of commands will fail. 103 112 104 === Known Bugs === 113 === Known Bugs 114 105 115 Issues (with priority) on new ticket creation 106 116 * (A) date/time stamp will not be saved, experience vary between failure on ticket creation (preventing ticket creation at all) and just trashing input silently - '''good news''': fixed now by significant code rework, will publish soon together with requested rebase on official Mercurial mirror of Trac SVN repo … … 108 118 * (B) [TracNotification Trac Notification] system unpatched, need to test and investigate, if necessary at all - WiP here, code done, think I'll have it in soon, blocked only by inability to test it right now 109 119 * (B) (Announcer) notification erroneously report custom time field as changed on any other change, maybe confused by conversion in a place, that is bad for checking an changed fields 110 * (C) invalid date/time strings from d bget replaced by current day with time reset, should be displayed as empty or (better) the string in single quotes, look at related issue discussed in section '[#Migratingfromdatetimestrings Migrating from date/time strings]' too120 * (C) invalid date/time strings from database get replaced by current day with time reset, should be displayed as empty or (better) the string in single quotes, look at related issue discussed in section '[#Migratingfromdatetimestrings Migrating from date/time strings]' too 111 121 fixed: 112 122 * [th:wiki:AnnouncerPlugin AnnouncerPlugin] non-functional, that already worked before introducing datetime.datetime format for all internal time variables: actually must have stopped on introduction of microsecond time stamps … … 114 124 * {{{TypeError: unsupported type for timedelta microseconds component: unicode}}} on TracQuery: simply needed to take care for conversation of variable type 'string' to a number and handle custom time values in trac/ticket/templates/query_results.html separately from standard time fields 115 125 * preview custom time stamp changes is throwing an exception on internal formatting: resolved after realising, that we deal with different formats in _render_property_diff() 116 a. string with POSIX microsecond time stamp from d b, directed to ticket changes list126 a. string with POSIX microsecond time stamp from database, directed to ticket changes list 117 127 b. datetime.datetime values from user input for change-in-progress, directed to preview current custom time field changes 118 128 c. old date/time strings, i.e. from previous use of custom text fields for date/time, directed to ticket changes list 119 129 d. any weird value, that is actually take care for as well, as long it has a string representation 120 * ticket diff view for change history exposes raw values from d b, should convert microseconds POSIX to pretty time stamp string121 * bad conversion of date/time value {{{None}}} to d bstring value {{{'None'}}} instead of {{{''}}}, gets overwritten with current date on next change, no date/time value deletion possible so far130 * ticket diff view for change history exposes raw values from database, should convert microseconds POSIX to pretty time stamp string 131 * bad conversion of date/time value {{{None}}} to database string value {{{'None'}}} instead of {{{''}}}, gets overwritten with current date on next change, no date/time value deletion possible so far 122 132 * notification throwing an error note related to unexpected datetime.datetime input to [TracNotification Trac Notification] system: gone while correcting functions preceding in ticket change process, not even sure it was Trac Notification, since this was not active at time of test 123 133 * current date is injected whenever time field is left/made empty: after extending all other functions the parser logic was the one place, where 'default_now' logic still happened overwriting undefined date/time … … 126 136 * server internal exception turned out to be caused by different versions of trac installed in /usr and /usr/local on my test system interfering on build time 127 137 128 == ToDo == 129 now (regarding #1942, as discussed with rblank) 138 == ToDo 139 140 Regarding #1942, as discussed with rblank: 130 141 * add_warning() and 131 142 * on parser error recall /ticket or /newticket respectively, … … 134 145 * check yet-to-be-reintroduced optional mxDateTime.Parser functionality 135 146 136 later 147 Future 137 148 * add jQuery datepicker function to custom time fields or even more general to input forms for time stamps like was requested in a [http://trac.edgewall.org/ticket/1942#comment:18 comment to ticket #1942] 138 149 139 == Discussion == 140 === Development questions === 141 In db table 'ticket_custom' a new row is created for every (custom time) field. Would it be worth the effort to delete this row, if the date/time is effectively purged? For now we end up with just an empty string {{{''}}}. 142 143 === Time stamp format === 144 There was no argument against storing time stamps as string to arrange with current type definition "string" for values in ticket_custom db table. But switching to microseconds time stamp format recently adopted for Trac internal time fields ''time'' and ''changetime'' seems to be better than sticking with the former Unix time stamp, even if I prepared support for fractions of seconds by converting custom timestamps to float before. 145 146 === Migrating from date/time strings === 147 I keep thinking of the case, where one already has a pile of date and wishes to switch to new date/time type now. Hope he/she finds it convenient that old values will be converted (silently) by current code, whenever a ticket is updated. But someone might come up with something like a db upgrade script for batch conversion/migration all a once. I think I'm not enough of a SQL guru to do that. So suggestions and contributions on the subject are very welcome. 150 == Discussion 151 152 === Development questions 153 154 In database table 'ticket_custom' a new row is created for every (custom time) field. Would it be worth the effort to delete this row, if the date/time is effectively purged? For now we end up with just an empty string {{{''}}}. 155 156 === Time stamp format 157 158 There was no argument against storing time stamps as string to arrange with current type definition "string" for values in ticket_custom database table. But switching to microseconds time stamp format recently adopted for Trac internal time fields ''time'' and ''changetime'' seems to be better than sticking with the former Unix time stamp, even if I prepared support for fractions of seconds by converting custom timestamps to float before. 159 160 === Migrating from date/time strings 161 162 I keep thinking of the case, where one already has a pile of date and wishes to switch to new date/time type now. Hope he/she finds it convenient that old values will be converted (silently) by current code, whenever a ticket is updated. But someone might come up with something like a database upgrade script for batch conversion/migration all a once. I think I'm not enough of a SQL guru to do that. So suggestions and contributions on the subject are very welcome. 148 163 149 164 The following issue is a side-effect of current fall-backs to parser. I'm unsure, if this is too ambiguous to be acceptable. 150 165 151 [[Image(TracQuery_on_CustomTimeField_odd-old-date.png)]][[BR]] 152 TracQuery based on custom time field ignores non-numeric time stamps from db but still displays values, that could be parsed to datetime.datetime in ticket list 153 154 === Unit tests === 166 [[Image(TracQuery_on_CustomTimeField_odd-old-date.png)]] 167 168 TracQuery based on custom time field ignores non-numeric time stamps from database but still displays values, that could be parsed to datetime.datetime in ticket list 169 170 === Unit tests 171 155 172 I got [ticket:1942#comment:23 advice], that presence of this would be a pre-requisite for inclusion into Trac. 156 173 157 === ''No'' additional code dependency, but an option === 174 === ''No'' additional code dependency, but an option 175 158 176 Amongst the few new dependencies use of ''eGenix.com'' time string parser ''mxDateTime.Parser'' for Python is the most notable one ![2]. ~~We need~~ I needed to add such a powerful tool to provide a mature parser right from the start. If handled with care, similar but incompatible classes ''datetime.datetime'' and ''mxDateTime.!DateTime'' are not much of an issue. In fact it doesn't matter at all, as long as we stick to ~~unix time stamp~~ POSIX time format for saving ~~times in the~~ time stamps to db for other (good) reasons as well. 159 177 (cboos): adding a new external dependency is a strong handicap for being considered for inclusion in Trac core. Have you really weighted the benefits of using mxDateTime? Maybe that helps to kick start the development, but you should really consider building your own utility functions, if you need functionality besides the one provided by the `datetime` classes. See for example how we integrate `pytz`: if present, we take benefit from it, if not, we provide our own replacement with reduced functionality. … … 163 181 While there was working code for parser functions before and I was especially satisfied with the performance of the needed date/time parser I've re-arranged the implementation. Now ''mxDateTime.Parser'' is not a dependency but an option. This was suggested by cboos and others for the sake of maintaining Trac code highly self-sufficient, and I understood this a feature on its own. Still ''mxDateTime.Parser'' has superior performance, if it comes to more unusual date/time user input, so it is still a recommended for maximum user satisfaction. 164 182 165 === Considering demand for custom time field defaults === 183 === Considering demand for custom time field defaults 184 166 185 I can imagine various needs for defaults: 167 186 pre-seed with … … 174 193 Each one looks like a perfectly reasonable way to preset a suitable default for one of different demands. But only a preset, of course, still subject to change on ticket creation as well during ticket life. It looks like a discussion would help to possibly strip nonsense from sense. We'll see then, how generic or special, simple or complex a default configuration satisfying most/all real world demand would have to become. 175 194 176 === Considering demand for (custom) time field format settings === 195 === Considering demand for (custom) time field format settings 196 177 197 As I learned from the discussion within ticket #2182 support for implicitly setting date and time formats by locale selection is not enough for some users. I'd like to make this enhancement available for custom time fields first. Than we might be prepared to go on extending it to an implementation for all time fields. Maintaining changes for custom and standard time field in different patched should be desired to allow for an independed application as [ticket:2182#comment:73 proposed by me]. 178 198 179 === Handling ticket changed notification === 199 === Handling ticket changed notification 200 180 201 I plan to let the notification system handle the conversion of unix time stamp values to date/time strings on it's own. I tested with a patched version of [th:wiki:AnnouncerPlugin AnnouncerPlugin] that worked. This is a good start for the [wiki:TracDev/Proposals/Announcer proposed replacement] of current Trac Notification System by Code from [th:wiki:AnnouncerPlugin AnnouncerPlugin]. This might even make per-user preference-based date/time formatting possible in the future. 181 202 As adoption of code from [th:wiki:AnnouncerPlugin AnnouncerPlugin] is far from ready to replace current Ticket Notification, I feel the need to patch it as well. Right? 182 203 183 === Development traces === 204 === Development traces 205 184 206 Happened to have access to !SourceForge, so I choose to go and push code into a Mercurial repository there to enable collaboration based on a distributed VCS as per suggestion from IRC channel #trac at freenode.net. 185 207 rblank offered to rebase my code on top of code from his own repository, so a least he would be able to rewiev more easily. I'll try it and combine this move with a trial on Mercurial patch queue. … … 197 219 Re-based on r9478 meanwhile, nothing to update inside my patches. Nice. Time to move on. 198 220 199 == Related Trac plugins == 221 == Related Trac plugins 222 200 223 * [th:wiki:CustomFieldAdminPlugin CustomFieldAdminPlugin], modified version to ease the setup for new field type ^*^ 201 224 * [th:wiki:CalendarPopUpPlugin CalendarPopUpPlugin] is working flawlessly with custom time fields, since these are still simple text input form fields … … 204 227 ^*^ patch is available inside repo, see subdirectory ./plugin 205 228 206 == External related resources == 229 == External related resources 230 207 231 Ideas and Open Source code was shamelessly taken from the following places: 208 232 ![1] [http://seehuhn.de/pages/pdate Date and Time Representation in Python] by Jochen Voss[[BR]]
