[Tickets #4717] Re: In config/prefs.php, document all possible types

[bugs@bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: https://dev.horde.org/horde/whups/ticket/?id=4717
-----------------------------------------------------------------------
 Ticket             | 4717
 Updated By         | Michael Rubinsky <mrubinsk at horde.org>
 Summary            | In config/prefs.php, document all possible types
 Queue              | Horde Base
 Version            | 3.1.2
 Type               | Enhancement
 State              | Feedback
 Priority           | 1. Low
 Owners             | 
-----------------------------------------------------------------------


Michael Rubinsky <mrubinsk at horde.org> (2006-12-01 11:44) wrote:

Alright, this conversation really belongs on the lists, not in a
bug/feature tracking system but I will respond to these comments here one
last time, I think you misunderstood me, I am trying to help you in
whatever it is you are trying to do by editing/changing the prefs.php.dist
file.

> No. This only the coonfig.php is setup in this way; the other 
> config/*.php have to be set up manually, and this is why the 
> administrator needs a comprehensive documentation of the pertinent 
> conventions and options.

In your previous post you specifically mentioned configuring what appears
in the horde menu.  I was pointing out to you that the icons/links that
appear in the horde menu are not configured in the prefs.php file, they
are configured via the Administration->Settings interface (which generates
the file conf.php as you pointed out).

Since there are only a few reasons for an administrator to actually edit
the prefs.php file, I took some (apparently incorrect) guesses as to what
you might be trying to accomplish by changing this file,  such as creating
locked prefs,  providing default values for some values, or even changing
what sections each pref is contained in.  From your interest in the
undocumented data types it occurred to me that you might be trying to add
your own prefs to the file, which, of course would require code to be
added somewhere in horde/application to actually use it...which led me to
the (again, incorrect) assumption that you had enough knowledge about the
structure of horde apps to provide a meaningful patch.

> It is certainly less work for everybody, if the administrators can 
> find the neccessary documentation in the ditribution and need not 
> bother all the subscribers of those lists with trivial questions.

Again, I agree with you on this point - in theory.  As is the case in most
open source projects, documentation is usually lacking.  Since this project
is worked on by people *volunteering * their time and knowledge, they tend
to work on the things that interest them, and that is usually coding.

And, FYI there are many HOWTOs, tricks, documentation, etc on our wiki
that may prove to be very helpful to an admin new to Horde.

>  If he, however, has neclected this 
> duty, it will cause headaches to countless administrators, and it 
> will cost hours to close the gap, later.

I would hesitate to say the developers, who are working for free, had
neglected any duty in this case...and it is these administrators that do
take the time to track down something in the code that is lacking, be it a
bug in functionality or lacking documentation, and provide fixes back to
the project that help make this (and other open source projects) such a
great platform.

> In this particular case, I had hoped that somebody, who knows the 
> code, could provide the missing details (just a few lines) straight 
> off the bat. Now, after I have spent some hours trying to fill in the 
> missing information, still somebody knowledgable has to check, and 
> amend, my proposal.

...and thank you for taking the time to help out and provide whatever
information you were able to deduce.  Every contribution helps.

<end of rant>