Changes between Version 21 and Version 22 of TracTicketsCustomTimeFields

Timestamp:

Apr 19, 2010, 10:49:55 PM (14 years ago)

Author:

hoff.st@…

Comment:

added more comments and updated information on development

TracTicketsCustomTimeFields

@@ -35 +35 @@
 
 === Status of Development ===
-I've decided on going public with my current Mercurial queue at bitbucket.org now. Here it is:
+Patches against Trac trunk are published as Mercurial queue at bitbucket.org now:
 
  http://bitbucket.org/hasienda/custom-time/overview
 
-''base'': patches applied cleanly to Trac trunk r9443, cloned from rblanks Mercurial repository at bitbucket.org.[[BR]]
+''base'': patches apply cleanly to Trac trunk r9443, cloned from rblank's Mercurial repository at bitbucket.org.[[BR]]
 ''quality'': alpha - major design flaws and backward-incompatible changes possible until stable release[[BR]]
+''focus'': completion of basic functionality, bug-fixes
 ''reviews'': so far just me
 
-I consider the code in alpha stage right now. If you pull that early, test tickets may need to be discharged for the final implementation to work flawlessly. You've been warned. See [#KnownBugs Known Bugs] for more details. As soon as I see sort of a release candidate, I'll let you know.
+If you pull that early, test tickets may pollute your db with nasty values that need to be discharged for the final implementation to work flawlessly. You've been warned. See [#KnownBugs Known Bugs] for more details. As soon as I see sort of a release candidate, I'll let you know.
 
 No longer bug-fixing on my initial approach, but doing a fresh and hopefully clean new implementation as detailed above. Assume to come out with some patches soon. I've setup [http://bitbucket.org/hasienda/shelf/ my place at bitbucket.org] recently, that'll make collaboration via a Mercurial repository easier than via Sourceforge.net.
@@ -59 +60 @@
 
 ==== Known Bugs ====
-Problems on ticket change/preview
- * current date is injected whenever time field is left/made empty
- * notification unpatched, throwing an error note related to unexpected datetime.datetime input to [TracNotification Trac Notification] system
+Problems (with priority) occurring arround ticket changes
+ * (C) preview time stamp format is not pretty, like '2010-04-19 20:03:00+00:00' instead of '19.04.2010 22:03:00'
+ * (A) bad conversion of date/time value {{{None}}} to db string value {{{'None'}}} instead of {{{''}}}
+ * (B) ticket diff view for change history exposes raw values from db, should convert microseconds POSIX to pretty time stamp string
+ * (A) notification unpatched, throwing an error note related to unexpected datetime.datetime input to [TracNotification Trac Notification] system
 fixed:
+ * 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
  * change to switchable conversion of empty values with new attribute {{{default_now = True(default)|False}}} was incomplete: not done for older function to_timestamp(), so exception raised for some wiki pages (fix will be committed into next rev)
  * move to microsecond timestamp caused a mess with calculations (added '* 10E07' instead of '* 10E06' and the like)
@@ -89 +93 @@
 I can imagine various needs for defaults:
 pre-seed with
- * empty value (well, thats quite easy :-)
+ * empty value: this is '''current default'''
  * fixed date/time (much less demand, I guess, but this could help i.e. when facing an already fixed project termination)
- * current date/time
+ * current date/time (just make one of all the 'default_now = False' attributes along the processing optional)
  * date/time with predefined offset from current date/time (like "now + 14d")
  * ...