standard feeback form, show ver

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

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

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

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".