Changes between Version 35 and Version 36 of TracTicketsCustomTimeFields

Timestamp:

May 2, 2010, 2:35:40 PM (14 years ago)

Author:

hasienda <hoff.st@…>

Comment:

updated development info, added reference to another related Trac ticket and incorporated it's goal within this project

TracTicketsCustomTimeFields

@@ -46 +46 @@
 ''focus'': bug-fixes, working ticket change notification for both [TracNotification Trac Notification] system and [th:wiki:AnnouncerPlugin AnnouncerPlugin][[BR]]
 ''reviews'': so far just me, I need your help now[[BR]]
-''prospect'': hopefully merge with Trac trunk for official release with any of version 0.12.x or even 0.13
+''prospect'': since 0.12 is on the way (congrats!) and considering all the new features coming in here, it's more likely to go for 0.13 right away
 
 This is work in progress. Proposed code changes for Trac trunk reside in a Mercurial repository at bitbucket.org ^note 1^. The Mercurial Queue (MQ) aside that repo is the patch stack itself with some meta-data ^note 2^:
@@ -125 +125 @@
 ==== Known Bugs ====
 Issues (with priority) occurring around ticket changes
- * (B) [TracNotification Trac Notification] system unpatched, need to test and investigate, if necessary at all
+ * (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
+ * (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
  * (C) invalid date/time strings from db 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
 fixed:
@@ -184 +185 @@
 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.
 
+==== Considering demand for (custom) time field format settings ====
+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].
+
 ==== Handling ticket changed notification ====
 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.
@@ -205 +209 @@
 
 == Related Trac plugins ==
- * [th:wiki:CustomFieldAdminPlugin CustomFieldAdminPlugin], modified version to ease the setup for new field type, private patch done
+ * [th:wiki:CustomFieldAdminPlugin CustomFieldAdminPlugin], modified version to ease the setup for new field type ^*^
  * [th:wiki:DateFieldPlugin DateFieldPlugin] working flawlessly with custom time fields, since these are still simple text input form fields
- * [th:wiki:AnnouncerPlugin AnnouncerPlugin], modified version produces reports with pretty date/time strings, private patch done
+ * [th:wiki:AnnouncerPlugin AnnouncerPlugin], modified version produces reports with pretty date/time strings according to locale setting of trac(d) proccess ^*^
+^*^ patch is available inside repo, see subdirectory ./plugin
 
 == Related tickets ==
@@ -214 +219 @@
  #1943 asking for time based calculations in queries, essentially based on #1943[[BR]]
  #1962 asking for due dates on tickets & email notification on overdue dates, several tricks and workarounds needed for using date strings the way you'd expect true time values to match, sort, etc.[[BR]]
+ #2182 asking for better, directly (user- and system-)configurable date and time formats in contrast to current selection via locale[[BR]]
  #2288 asked for date/time based ticket query functions, that exist by now[[BR]]
  #6466 asked for higher time stamp precision introduced with microseconds for ''time'' and ''changetime'' in r9210[[BR]]