These forums are locked and archived, but all topics have been migrated to the new forum. You can search for this topic on the new forum: Search for Bug reporting directly from admin panels on the new forum.
Web Hosting and Cloud Computing Control Panels
This is an interesting idea, but there are a lot of technical issues that would probably make it difficult to implement.
Most importantly, the current web site bug tracker and "customer issues" support ticket applications have been lacking in some critical features since their implementation. Joe has tried several times to get assistance from the development team, but this has been a problem for about a year and a half now. So, it would probably be even more difficult to use some type of API as you're suggesting to post bugs and tickets directly from Virtualmin.
Because of these problems, Joe has mentioned that he plans to switch the web site to use a new system at some point in the near future. Since this means the back-end will change, that would make it a waste of time to establish any new functionality with the current system. However, once the new system is in place, this may be an option.
Personally, I don't mind going to the main web site to enter bugs and tickets. This is the way almost all other software applications work. I can't think of anything that allows bug tracking or support tickets directly from the application itself, other than maybe a simple link to redirect you to the main site.
The part about having hosting customers (virtual server administrators, etc.) report problems would be very useful, but I think those reports should go to the hosting provider (i.e. me and you), <i>not</i> to the Virtualmin developers directly. I'm sure they don't want to be dealing with support requests from all of our end users, nor should they. This can already be implemented somewhat by using the Install Scripts functionality to create a help desk or support tickets site for your hosting company. This is where these requests should be directed, and if issues turn up there that may actually be system bugs or major issues requiring further support from Virtualmin, then it would be up to you as the master system administrator to submit those reports on behalf of your customers.
Lastly, I am curious about the problem you're having where you have to request notification each time. I haven't had to do this, because I subscribe to the notification types I want. For example, to do this in the "Customer Issues" module, simply click on the "Notifications" link at the top left, which takes you to this page:
http://www.virtualmin.com/ticket-tracker/notifications
You can also click on the "Manage your notifications" link at the bottom, which manages them for the entire Virtualmin site:
http://www.virtualmin.com/notifications/manage
I hope this helps resolve some of the issues you are having.
Hey guys,
Sorry for reviving a ten day old thread, but I think it's a really interesting idea.
As Alan said, it's a tough problem to crack for a lot of reasons. Many of them technical, but more of them human interaction related. Technical problems are easy...you just have to write the code. The human problems are harder, and that's the majority of this feature.
<i>NOTE:</i> I'm just think out loud here, because this is a great idea, and I think going forward it is exactly the kind of thing we want to address. Things that are hard to solve for any individual hosting company, but might be easy if we all sit down and come up with a good, simple, and elegant design. One that either backs up to an existing issue tracking product, or is implemented in such a simple and clean manner that it doesn't eat all of our time.
So, what's the problem really look like?
First up, we have to solve the problem of "who wants this issue?" Alan explained this problem very well, so I'll just expand on that and suggest a possible solution.
When an end user, like a customer at your hosting provider, asks a question, it's probably not really something we here at Virtualmin can answer. It's probably "What are the correct DNS servers for my domain?" or "How do I update my billing address?" Even if it is "How do I create a mail alias?", and we <i>can</i> answer it and are happy to do so, the hosting provider probably wants those responses to come from their email address and with their own personal touch.
So, we need a way for the built-in issue system to automatically determine who to notify about the problem, and whether to store it in the local issue tracker or in the Virtualmin.com issue tracker.
If it's a domain account holder or a mailbox account holder, it stays local (or goes to the hosting providers public instance). If it's the system administrator, it comes here to Virtualmin.com. Seems easy, but is gonna be a source of confusion...what if there are multiple sysadmins and they want to use the tracker for their own local stuff. We use our bug tracker here to talk to each other all the time, as it's just the best way to deal with a lot of communication.
As Stephan noted, we don't need any fields for the user to fill in version/OS/contact/etc. information because we already know it all. This is a beautiful thing, and really simplifies the issue filing process for users--it becomes "Describe your problem?" and then all subsequent responses are discussion and finally a "Close this ticket". Most issue trackers are way too complicated for normal users to get any value from, and part of that is because the issue tracker has to gather so much information that the user is not well-equipped to provide. Our issue tracker here at Virtualmin.com is no exception. It's stupidly complicated...it's just an instance of the bug tracker configured slightly differently. It'll go away when we move to the new website, and all things will be handled via a single bug tracker (unless and until we get something like what we're talking about here implemented).
So, really, the hard problem is just "Who needs to know what?" Some issues from customers might need to be upgraded to a Virtualmin issue, since they may very well be bugs in the software that we need to know about. And sometimes we want to hear about it when the user is just confused--we view having a confusing interface a bug, but sometimes we don't know what is confusing unless someone tells us. We're kinda stupid that way.
I spent some time several months ago looking at the existing issue tracking products and they are all way too heavy for what we're talking about here, unfortunately. They are all way too flexible. ;-)
The good ones in Perl are huge: RT and OTRS. There is a command line one called BATTS that could probably be modified to fit our requirements, but it'd probably be faster to start from scratch. I believe there's probably a sweet spot solution that involves a mailbox with a few custom headers: X-Issue-Status: Resolved, X-Issue-OS: debian-linux, etc. Then we'd have a modified mailbox viewer that allows searching based on those tags, and a custom mail filter that would parse the messages looking for special tags--so one could open/close/discuss an issue via email and it would all work in the web UI.
We already have a great mail client in Usermin. So we'd just need to modify it to accommodate the needs of an issue tracker. Add tabs for "Closed" issues and a search box that knows about the special headers. Also would need an "Ask a support question" button instead of "Compose", and compose form would be very different from the current one.
Hmmm...I wonder why no one has built such a tool before? Writing custom interfaces to the data would be easy because there's already great MIME and email libraries out there. You could even do a rich desktop UI for it and connect via IMAP.
I'll have to do a little experimenting. This might just turn out brilliant, if I do say so myself...
Anyway, I should warn that this is a pretty big project, even though I use the words "easy" and "simple" when talking about it. It still has a lot of components, and they'd have to integrated cleanly into whatever kind of environment it's deployed into (so, MTA agnostic...though we'll have to require that delivery does go through our filter, if mail support is desired).
So, it won't be happening next week. But I feel pretty good about it, and it feels like a really interesting problem with some really cool possible solutions. I'll try to get back to it in a few weeks.
--
Check out the forum guidelines!
Personally, I like a lot of the way Fogbuz works and relates to the customer, etc. (fogcreek dot com) It should not get in the way of things, it should handle COMPLETE tracking from birth to death and beyond (to paraphase buzz lightyear), and should update all users/subscribers whenever an action is taken. Be sort of cool if you could get a cross licensing agreement with them. Seems like a good fit, and they're one of the best customer focused companies that I'm aware of. That said, I don't own their products because I'm a single person shop.
Probably should have RSS etc. for us people who like to watch ("Being There").
If you do your own, then baby steps is fine (I seem to be on a movie theme in my head...[["What About Bob?"]]).
That way, you can let it evolve into what is needed, etc.
For now, any customer should be able to post to the next level (site admin to box admin). Then, as "box admin", I can "forward" to Virtualmin support with one additional click. It should be configurable so that I can designate people that can post to Virtualmin directly, or that a post automatically emails people after a certain time period if I don't respond, etc.
It should always respond back to user with a case # and link. Since we will have both LOCAL case numbers and Virtualmin case numbers you need to handle that. There should be a case # for each level of user (previous paragraph). As an end user, it was always frustrating when I could not easily embed our own case # into a foreign products bug reporting, etc.
BTW, I know about the manage notifications page and have been using it. I've been subscribed to the "all your assigned to" ones. It still doesn't work for any new ones.
I've switched to the "all you're participating in" to see if that's better.
Also, I get double or triple reports (via email) of all these. Sometimes hard to read because of that.
Basically, I don't think this product works very well. I'm really glad their switching.
When can we get a "beta" peek at the new website, and kick the tires, so to speak.