Back to issue list Export

Having a local bug tracker which follows the developer and all is nice, but not sufficient. It must be possible to easily provide a public, modifiable copy of the tracker for use by QA people, or users. The single user UI is entirely too inefficient for this, but could perhaps be helped by running as a script under a real webserver.

travisb 2012-07-24 01:40:43
hash: 32c1d848aac7ed6234e733f3f94aa92d698872c92a1ae33a43cfbf4ba0350d0c
Date: 2012-07-24 01:40:43
User: travisb

There would have to be some sort of moderation when moving issues back to the primary VCS copy. Maybe a recommended setup would be to have a plain filesystem/VCS export version of the repository with the script/whatever Public UI running. Then every so often a person can run a synchronization/moderation script which gives simple choices to add the public change for a bug to the repo or not.

travisb 2012-08-16 00:07:43
hash: 6d493a1ef38ee750f02e136145e3f6deafa3e56032de4b9dd3ffd37d5634f2df
Date: 2012-08-16 00:07:43
User: travisb

One possible way to do this would be to punt it off to the VCS. For many cases just looking at a diff and reverting anything which doesn't seem correct would cover many cases. This is likely what the initial tool will be like. In the future it would be possible, but significant work, to present a moderation view where anything which isn't part of the issue repository is coloured and a list between modified issues. But this would only be done if some scripting around the VCS isn't sufficient.

travisb 2012-08-16 00:11:13
hash: 6317f2bfdc30da6820e6723347d36b3fdc3c5750e36f8e82101c9687911f1038
Date: 2012-08-16 00:11:13
User: travisb

It shouldn't be too hard to convert the web UI to run as a CGI script. The VCS type would have to be set to filesystem internally to avoid needing to call external commands. That would reduce the security impact. It's not like anybody would like the public changes committed to any repository automatically anyways. Even a DVCS where not all the changes end up in the canonical repository would be strained.

travisb 2013-02-16 06:33:15
hash: d94044f7daeb909ef570c136bf007f042c101fa75403bd40d5ac4244daceb2a9
Date: 2013-02-16 06:33:15
User: travisb

The static dump has worked quite well so far. So well, in fact, that the only issue I've come across is the inability to sort and filter. A fully sufficient readonly interface could be created with some javascript magic to make the filtering and field selection work correctly.

travisb 2013-02-16 21:41:51
hash: 6c05e25e221691b2a9e785244bd6f58052cce1af91f03f5e2f991f9aadb33b8c
Date: 2013-02-16 21:41:51
User: travisb

My first tactic was to take a static dump of all the possible index states and then modify the sort and filter button to run javascript to load the proper page. It turns out the combinatorial explosion means that just the page with the links to the indices is hundred of megabytes in size.

travisb 2013-02-27 22:12:56
hash: 4eb9944b83c72648ba4b8a819b67fa50788f6b18a8439879d3f4ce65bf7a9f9d
Date: 2013-02-27 22:12:56
User: travisb

I've added some javascript which allows the user to sort and filter the issue index. This seems to be sufficient for many public UI usecases.

travisb 2013-02-27 22:42:19
hash: b9de7e12d98042b50622d7db6b8c823a52d665350abda311a12dd1b3a459ea29
Date: 2013-02-27 22:42:19
User: travisb

The only remaining serious issue for the public UI is that the sorting links don't actually dump correctly. This may have to do with their long length, over 300 characters with the default options.

travisb 2013-02-28 02:17:21
hash: 060aa5be1b6458d87cf6cb02cba55c62247d98c1f35208ca22d7c0c954ec726d
Date: 2013-02-28 02:17:21
User: travisb

I've fixed this by cutting out all the sorting and filtering options from the query string. This works, but pushes offline saving of the filter and column settings to the issue f4a61e53


Tracked by Nitpick