Download & Extend
Issues

standard feeback form, show ver

Posted by bertboerland on June 23, 2003 at 3:31pm
Project:Drupal core
Version:x.y.z
Component:system.module
Category:task
Priority:minor
Assigned:Unassigned
Status:closed (won't fix)

Issue Summary

it would be handy if users could sumbit error reports via a standard interface and that they will be prompted for standard issues regarding their configuration.

for example, when filing a bug, i have to submit:
* [must] version drupal
* [must] webserver (apache, iss)
* [must] php version
* [must] database (mysql, sequal,..)
* [must] OS (linux, bsd, windows)
* [opt] version webserver
* [opt] version OS
etc

(note the user might have reasons not to fill in the optionals for security reasons)

now it would be great if there was module of even a script in the drupal core that i could run to collect this data in a standard way. so all the enduser has to do is run ./show-ver.sh or surf towards http://foo.example.com/show-ver.php

i could paste this in a free form when filing a bug or to a mailinglist

and yes, it is like a sh ver for those who know cisco ios

(note, when having problems with php or webserver this wont work )

Login or register to post comments

Comments

#1

Posted by Mark Cheverton on June 23, 2003 at 3:52pm

Or even better, make a standard web service that returns this data then
just get the user to input the url of their site. If it can't find the
service it can just fall back to asking.

-Mark

#2

Posted by chaska@blogger.com on June 25, 2003 at 4:52pm

Attempting to capture what was said on the dev mailing list:

Moshe Weitzman wrote:

> 1.  Should such a service be authenticated?  (account/password, other?)


no. most users go to such pages when they are introuble. adding authentication might make the page inaccessible.

> 2.  Should it only be callable from Drupal.org when reporting bugs?


no. we should have a regular web page without any authentication. a web page with just phpinfo() would be a big improvement over what we have now.

> 3.  Some bits of information are hard to get, such as database version and OS version, without writing lots of conditional code
> 4.  What is the best way to determine the Drupal version?  Should we add a version number to the variable table?  How would it get updated?
>

we should have major and minor version numbers in the variable table. not sure how other projects handle this.

Bert Boerland writes:

<blockquote>
>-----Original Message-----
>> From: Slavica Jovan
>> I have a module that will provide this kind of service via
>> XML-RPC.  It
>> works but it is not finished.  There are some loose ends to tie up:


i would like to have a local version (calling if from a command line with php?) and an online version that could be called from the site itself and from other sites (maybe with some kind of access control list)


>> 1.  Should such a service be authenticated? 
>> (account/password, other?)


we (you!  are making something really wonderfull here and we should check stuff that has already been invented elsewhere (bugzilla?). please dont take security to lightly here, we are sending senitive stuff. so yes:
* certificates (both client and server?) optional
* uidp/passwd with aaa
* option to see only major/minor versions
* option to disable module all together (standard)
* display waht will be sent befre sending and let user submit that (ask passwd again?)


>> 2.  Should it only be callable from Drupal.org when reporting bugs?


seems like a Good Thing. i would like to have server certificates in this case for drupal.org. is there any person working @ verisign at this list?  a cmd version needs to be in as well for mail and a local repository database.


>> 3.  Some bits of information are hard to get, such as
>> database version
>> and OS version, without writing lots of conditional code.


yes, i see you point. i would say you could make a 80/20 here; do a uname -a and in case you dont get anthing back let the user fill in a preformted text box or a combination of drop down boxes [windows|mac] | [95,98,2000].


>> 4.  What is the best way to determine the Drupal version? 
>> Should we add
>> a version number to the variable table?  How would it get updated?


i would say yes, every module should write its version towards this table

#3

Posted by chaska@blogger.com on June 25, 2003 at 5:09pm
    My thinking was this:
  1. A user of a Drupal-powered website encounters an error that appears to be Drupal-related.
  2. The user clicks on a link or choose a bookmark or type a URI that takes them to a Problem Report page at drupal.org.
  3. The user enters the URI of the website where the problem was found into a form input field on the Problem Report page and then clicks on the Submit button.
  4. The Problem Report page action send an XML RPC to the Get System Information RPC at the site.
  5. If RPC is successful, the Problem Report asks the user for a few additional details and comments, and then stores the problem report along with the System Information retrieved by the RPC.
  6. If the RPC fails, the user is asked for the System Information (e.g. web server, PHP version, etc.).
  • The RPC would not report sensitive data like passwords.
  • The RPC would not return any data if the client was not drupal.org, unless the site admin had specifically chosen to enable the RPC for other domains, e.g. for remote management of multiple Drupal installations.
  • The problem report form is hosted at drupal.org, so that any problems the user site is having will not interfere with reporting the problem.
  • The Problem Report page could optionally ask for a valid account/password pair for the URI (site) in question, and the RPC service would not return data unless they were supplied. I do not know if this would be very useful.
  • As above, except the Problem Report page would require an administrator role account/password pair (requires Al's dedicated role number scheme) to return data. I do not know if this would be very useful.
  • For both authorization schemes above, they might be more useful if the System Information RPC service was enabled for clients other than drupal.org. If the site admin does not want to report system information to the developers at drupal.org, then it is unlikely we will be able to help them solve their problem.
  • Bert suggested client and server certificates for security. I am opposed to this idea because having worked with X.509 certificates, I know how incredibly complicated and difficult it is to get such a scheme to work. If we did this at all, we should use existing SSL-capable libraries.
  • I plan to figure out a way for each component of Drupal to make its version number available to an RPC service. This might mean storing the value in the database, or it might be some other way.

Comments? Suggestions?

--
Slavica

#4

Posted by killes@www.drop.org on March 9, 2004 at 1:27am

Lots of talk, no code, nobody stepped forward for over half a year.
The project.module is quite usable, I mark this as "won't fix".

nobody click here