The autofill template in Get Help forum posts is useful, but it seems to me it might be both more helpful to you, and easier for people to post, if you added the ability for the CMS to generate a text dump of all the things you care about, and just let the user copy it and paste it into a posting, probably with a signature you can trap for on Create Topic.
Optimally, you could stuff it either directly into the cut buffer, or even link directly to the forums and create the new post with it filled in…
Any version of this, though, would seem to improve your chances of knowing what you need to know to fix things, and reducing the administrative/cognitive load on the user (by keeping them from having to hunt for it).
I’ll let @natasha comment on the template shown when you open a topic here, but we do have a report fault process built into the CMS which pulls in most of the information we need (where we’re able to get it - it can’t tell how something is installed for example).
You can access it on most versions of the CMS: https://<cms_url>/fault/view
Well (now that all the background stuff in my VM finally completed and I can get to the CMS :-)), if you skip a number of the steps in that not relevant to this particular task, and get to the “collection” stage, yes, almost. The goal here, as I see it as a debugger/reporter, is to reduce the speed bump between me and the information I want to provide in a ticket to make working it easier and more productive as far as possible, preferably to zero:
A link that just provided all the info in the troubleshoot.zip file – in whatever version is most useful to the programmers (which might not actually be JSON, but I dunno), which I can just copy and paste into the ticket here in the forum, would be my goal as a reporter – the process engendered by that URL is about 6 steps long.
Ok, yeah, I could just attach the zip file, but then you folks have 2 or 3 extra steps to do; this isn’t about using that JSON in an install, right? Just for a Smart Person to look at?
Don’t get me wrong, that workflow does look like it will be spiffy for what it’s built to do, I just am not doing that here, I don’t think.
Makes sense, thanks. Very happy to take those points and think about it.
Part of the challenge is that we want the user to recreate the problem they were having before we debugging enabled, so that we can suck more information into that final file, hence the steps to check some stuff, enable debugging, repeat the problem, disable debugging before finally getting the file.
We export it as a file because 70% of the time we can’t get direct access to the CMS, and because we have a general aversion to exposing that sort of potentially sensitive data on a link.
You’re right though, we could make it easier to for us/the community to actually read, and there might not be a need for it to be in a file. Perhaps the next step in that process shows you a nice summary of the data collected, and a button to “copy to clipboard”?
Since you’re only asking for 3 things on the template as it is now, I didn’t equate the two uses, and that one doesn’t necessarily require as much as the current process provides – I’d assumed that was more for interactive – and possible commercial – support.
But I suspect some subset of what’s in there, which doesn’t include sensitive stuff, would still be helpful in a number of situations which aren’t “interactive, possibly commercial, support”.
Everything we need to help with an issue is potentially sensitive - be that server configuration, log files, etc. Besides, if we treat everything as sensitive we can’t do something by accident which puts a user at risk - it’s much safer that way.
Its the other way around, the troubleshoot file is only really used in the community for users who prefer to run on their own infrastructure, which we absolutely support and encourage. We do not offer commercial support where we cannot access the system directly and where it is not installed using our recommended methods (more details if you’re interested), and therefore do not need this troubleshoot process.
I’ve logged this on our planning board so we can roadmap it in due course.
