[dev] help/options links

[Roel Gloudemans]

>> OK, here is a patchset for the Horde framework. Next to the online help en
>> options links I also took in the Problem link.
>
> Problem is already controlled by $conf['menu']['apps'].

I know, but it seemed more consistent to me to put the whole trio (options,
problems and online help) under one menu option. Since I have a Giapeto site
online I would like the same options for Problem (always, 
authenticated, never)
as for Help and Options. I want to show the problem link to 
authenticated users,
but I don't want it on my website.

>> This is what I did:
>> 1) Removed configuration for "User constraints" (only online help 
>> was in here)
>> 2) In "Menu" I created three new options, "online help", "options" and
>> "problem". Each can have the value of "never show", "show only 
>> toauthenticated
>> users", "show all users". I think this is the most consistent approach.
>
> Except for problem, as noted above, I agree.
>
>> 3) In the Prefs class a new method "showLink" was added to determine 
>> if a link
>> should be shown
>
> Maybe make this like Help::listLink(), so that it returns the URL as well?
> (takes an app as argument).

Showlink is set up in a generic way independent on link type. (Any
$conf['link']['...'] works. Each link however is set up in a different way.
Some logic would then have te be added to showLink (showlink then becomes a
'gateway' for Help::listLink() and Prefs::listLink() (see below).
Alternatively, the descision to show or not show could be moved to the
listLink() methods, but this would result in the same code on multiple places.

>> 4) The portal menu was modified to honor the Options setting
>> 5) The "Menu" class is extended with 2 new methods named "createProblem" and
>> "createOptions". I didn't create a "createHelp" method, because this 
>> would, I
>> think, create a dependency between the "Help" and "Menu" classes (don't
>> know if this is wanted or not)
>
> I'd rather have the prefs one in the prefs class, and createProblem would be
> removed per above.

This would then become Prefs::listLink()

>> What I not yet did was:
>> 1) Remove problem from the Horde registry (I think is t is no longer needed)
>
> Hmm, I guess I could see going that way, but I also like having it
> controllable
> on a per-app basis. Thoughts?

A check box for disabling problem reporting reporting per app? I see problem
reporting not as a module for horde, but part of the framework.


>> 2) Adapt all Horde apps (conf.xml and menu.inc) to the new Horde settings
>
> What would be needed in conf.xml for the apps?

Your right. The list for the application icons for the menu comes from the
registry. But the above suggestion would warrant a modification of conf.xml

>> I will do these after I've improved the current patches based on 
>> feedback from the list.
>
> One other minor request: please put all of the patches for related work like
> this into one file. It's a hassle to look through 7 different patch files and
> apply them all in sequence.

As Darth Vader said to the Emperor: "Your wish is my command"

Cheers,
Roel.