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
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
