At Thu, 28 Aug 2014 11:42:58 -0400, Todd Niec wrote: > > [1 <multipart/alternative (7bit)>] > [1.1 <text/plain; us-ascii (quoted-printable)>] > > [1.2 <text/html; us-ascii (quoted-printable)>] > Hi, > > I am new to fossil as well as this list, so I apologize if this posting is > off-topic, answered > elsewhere, or inappropriate in any way. > > I am looking at using fossil as a low-footprint, "off-line" > bug-tracking/ticketing system.
At work I am developing a ticketing system that non-programmers will use internally, with no modifications to fossil itself. If you have similar needs to our company, you will make heavy use of the JSON API and JavaScript to get the right UI widgets, and to get things customized in a way that non-developers will use the software (one issue that they complained about in particular was the existence of the "View Ticket" page). I implemented full search capabilities, many new input widgets, among other things, so it is very flexible. There are some limitations that we worked around, such as the fact that the "%" symbol has a lot of bugs when used in JSON SQL queries (thus making most wildcard matches with LIKE useless), so I use GLOB with a regular expression for case-insensitivity. Further, TH1 is very limited, so even in the case of static SQL queries, you may still need to use SQL through the JSON API, because queries within TH1 arbitrarily prohibit many tables (I did a look up on the list of logins for a multi-select form, for example). I find it annoying that users have to be an "Administrator" or "Super User" to access the JSON api for SQL queries, as I'd like to choose which tables they are able to query or not, but then again, it is a distributed version control system, so it probably doesn't make sense to have fine-grained security in the first place. Regards, Tim _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
