On Wed, Oct 2, 2013 at 3:51 PM, Jacek Cała <jacek.c...@gmail.com> wrote:
> ...For those interested I report changes to the ticket table (below) and > view and edit pages (attached source). A remaining issue is that as > there're no hard db constraints on blockers there seems to be no way to > verify that the blocker to be added is actually a valid ticket uuid. > Basically, user can add any text as a blocker. > Any "real" blocking support has to be integrated with the system as a whole, from the human processes to the software (but primarily the human processes). What does a "block" actually "block"? Does it block a release (fossil doesn't know what a release is), does it cause work to be reprioritized (also something fossil knows nothing about), or does it have some other effect? My point being only that i don't think there's anything Fossil can reasonably know/do in regards to a blocker except for what you've already done: > CREATE TABLE ticket( > ... > comment TEXT, > blockers TEXT > ); > IMO that doesn't really belong in the default ticket schema system because... (and i know this is going to sound somewhat lame!)... it's never been a pressing issue before (in 6 years of use). It may have been brought up a time or two (i don't recall, but i also don't immediately recall whether or not i've already eaten today :/). If it's added, i'm pretty sure it will be ignored by 99% of users, in which case leaving it as an optional client-side customization seem more practical to me. But of course that's just my personal opinion and not some sort of official statement :). -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
