On Mon, Mar 16, 2015 at 4:33 AM, Graeme Pietersz <[email protected]> wrote:
> On 16/03/15 13:30, Ron W wrote: > > On Sun, Mar 15, 2015 at 3:56 AM, Graeme Pietersz <[email protected] > > <mailto:[email protected]> <[email protected]>> wrote: >> 1) email > notifications, the most important for me > > Can currently be accomplished > with external (to Fossil) > service, using, for example, Fossil's RSS feed > to > > trigger email generation. > Not easy to do with a private repo without compromising privacy. > I assume you mean the risk of enabling the RSS feed. I just looked and don't see a way to disable the RSS. Nor do I see any documentation describing how it works, in particular, how it is affected by the login state. >> 4) link user names to user pages with other activity > >> (only useful of > >> you have some social networking features) > > You mean like linking to users's "walls"? > > Tickets descriptions and > comments can contain wiki mark-up. > That relies on people remembering to do it - procedure for something that > could be painless and uniform if automated. > I think it could be automated by modifying the TH1 code in the Edit Ticket page. > >> 5) edit the original report if things change > > Not sure I agree. > While making corrections might be nice, I think > comments are better for > describing an evolving situation. > In general, but if the task is changed significantly there is a good case > for changing the ticket itself. > To take a recent example I came across, you have a ticket to upgrade an > application to work with a more recent library version. > You then change your mind about which more recent version to upgrade to. A > ticket that still says "upgrade to version x.y" when you > are now upgrading to x.z is misleading. > At least in my department (New Product Engineering), our process requires us to open a new ticket, related to the original, and close the original with the reason "Obsolete" and a comment stating why. > >> 6) sub-tasks/child tickets/todo list for ticket > > In the description > and comments, other tickets can be linked,, as can > wiki pages and > commits. > > Would be nice if other fields could link as well. > > Anyway, > could create a child ticket using Javascript to populate a > new ticket > with defaults derived from the currently viewed ticket. > That does not provide the same functionality. It is a partial workaround > but relies on manual intervention to ensure the links run both ways, > and does not prevent the parent ticket being closed before all child > tickets are closed. > I'm pretty sure the Javascript could take care of links in both directions. Then, if TH1 query can read the statuses of the child tickets, the TH1 code in Edit Ticket can handle the "do not close unless child tickets are closed" logic. (This would not need to be recursive. Only need to iterate over the direct children.)
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
