Fossil Forum
Post: Difference between bug forum and tickets
There is a big difference between Tickets and the Bug Forum. There is ticket documentation but this is different to the nice new Bug Forum as used for SQLite. The Bug Forum seems to be a few bug features on top of the documented ordinary forum and looks like a pretty smooth way of handling the hard problem of ticket management.
I am reviving a project that used the bugtracking feature a bit. While I don't care about migrating ticket history, I'm committed to using Fossil (because LumoSQL follows SQLite) and so the Bug Forum is probably what I need for future bug flow.
Where can I learn about the new Bugs Forum feature? Perhaps it's just a config feature I haven't noticed.
Thanks
--
Dan Shearer
[email protected]
The Bug Forum seems to be a few bug features on top of the documented ordinary forum and looks like a pretty smooth way of handling the hard problem of ticket management.
The "forum-statuses" setting was added right after sqlite.org/bugs (a standalone, forum-only repository) went online, as a way to quickly sort through those posts. Yes, we could have used Fossil's ticket system, but it seems fair to say that none of us are very fond of it and the forum (which we all adore!) gives us about 95% of what this particular family of projects really needs from a ticket tracker.
Where can I learn about the new Bugs Forum feature? Perhaps it's just a config feature I haven't noticed.
Edit reply: Difference between bug forum and tickets
Thanks, that helps.
So we just define a second forum (how does one do that?) and in that second forum, and set the statuses. Simple! It would be helpful if the status example had a full set of handy statuses rather than "..." so we can copy/paste a setup known to work to start with, even if a user will later edit it to suit.
D
So we just define a second forum (how does one do that?)
Each is its own standalone, independent repository.
and in that second forum, and set the statuses
Correct.
It would be helpful if the status example had a full set of handy statuses rather than "..." so we can copy/paste a setup known to work to start with, even if a user will later edit it to suit.
There's not really a one-size-fits all list, and we do not want this setting turned on by default (so there's no default value), but here's the setting from sqlite.org/bugs:
[
{label:"Open",value:"open"},
{label:"Resolved",value:"resolved"},
{label:"Not Planned",value:"not-planned"}
]
Some care must be taken in the "value" parts - if those IDs change, forum posts which refer to the old IDs will behave as if they had the default status value, meaning the first one in the list.
Thanks, that helps.
So we just define a second forum (how does one do that?) and in that second forum, set the statuses. Simple! It would be helpful if the status example had a full set of handy statuses rather than "..." so we can copy/paste a setup known to work to start with, even if a user will later edit it to suit.
D
Edit: if your browser (like mine) is not jumping to that #status anchor
Which mine didn't, either - I think because the h2 tag has a 'name' attribute. Should be 'id', no? Ditto next two h2's.
but it seems fair to say that none of us are very fond of it and the forum
I actually do like the ticket system but I just don't have much use for it; especially that it's integrated. Maybe if I used it more I might find that I don't really like it.
... 'name' attribute. Should be 'id', no? Ditto next two h2's.
Fixed, thank you. There's a long history of confusion between name and id on my part :/.