Hello All, Sorry if you've seen this before. I posted this message last Sunday, but I didn't see it hit the list.
I would like to add the required changes that would allow the default installation of fossil to allow assignment of tickets to individuals. I also want to ensure that the ticket reporting mechanism has the ability to generate a report that would show the current users assigned tickets. I also want a user to be able to mark the ticket as "being worked on" >From a quick glance this would require: * addition of an "assigned_to" field in the default ticket table schema. * addition of the user() functionality (I think someone is working on this) * addition of "InProgress" or "Underway" in status_choices * possible addition of an "assignto_choices" list in the default ticket common script Here are a few other quick questions about the ticket system: I can't seem to view the "unobscured" ticket's private_contact data? As admin or a user with "e" permission flag set db_reveal doesn't seem to be working. Has anyone had success viewing this field in a ticket report? This could be an alternative to the assigned_to column. And I'd rather use existing features than add any. Is there an existing way to get the current user's contact info in the ticket report sql? There are a lot of functions described in the ticket report system: user, aux, option, cgi ... I can't seem to find them in the code. Are they there and I just can't find them or are these just planned for the future? Any ideas on how to sort (order by) priority_choices or severity_choices? If not would anyone mind if I renamed the default priority_choices and severity_choices to the following: set priority_choices { 1-Immediate 2-High 3-Medium 4-Low 5-Zero } set severity_choices { 1-Critical 2-Severe 3-Important 4-Minor 5-Cosmetic } This is a simple solution that allows a simple order by clause to produce a prioritized list of tickets. What is the preferred method of altering fossil code? Should I send a patch to this group or an individual? Should I request a login (I had one in the past but it does not seem to function any more). I notice people creating branches for their experimental work, should all work happen in a separate branch for testing before being merged to trunk? Thanks, Erik Lechak _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users