> I agree. One of the strengths of the fossil ticketing system is it's > integration with the scm history, which is not what you would not want > for a customer-facing ticketing systems. I suggest using one of the > other support management systems for that and keep fossil for > internal, development use.
The most important reason for me to consider moving to fossil is the fact that it has vcs, ticketing and wiki in one app so I don't need to integrate and then maintain 3 separate projects. Your suggestion to introduce another support management system nullifies this major fossil's advantage. How about following workaround: Provide a separate fossil server and/or repo for customers with create ticket/comment/append permissions, team members will autosync their repos with that one, while they will have only comment/append (on existing tickets) permissions. Is it easier to implement/configure? >From the security point of view its even better since one doesn't have to expose the repo with the source code to the customers. As mentioned before, the only feature I miss, except for this one, is the ability to block "fossil server" from running on insecure connections (either by implementing SSL for fossil server or/and by simply blocking "fossil server" (or at least warning) if some "-use-with-ssl-only" option is enabled). Thank you, ST _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
