[whups] Code update (numerous features)
Robert E. Coyle
robertecoyle@hotmail.com
Wed, 21 Nov 2001 00:15:25 -0000
From: "Alex Leverington" <admin@networkessence.net>
> First, I'd like to not I'm not a professional programmer, so if you think I
> might know something, I probably don't :)
Ah, ok.
> I didn't know about the version stuff, I haven't learned enough about CVS yet
> (and I've publicly announced that already).
Ok. $Horde$ is (obviously) horde specific, but it's effectivly the same as $Id$
on any other cvs repository. This gets replaced by CVS, so in a new file you
only add $Horde$.
> I understand your concern on the
> copyright. What should it be changed to? I planned on redoing most everything
> in there...that's why I still left your name on there.
Add yourself by all means, but the two files committed to cvs don't have my
original copyright notice anywhere.
The official horde guidelines for this is in docs/CODING_STANDARDS (section 8).
> But...where have you
> been till now? (That wasn't in an accusing manner...I've been working on this
> and haven't gotten any feedback from you...)
I've had other commitments up till now, but I'll try to take a more active role
in Whups. I will be committing the work I've done soon.
> [snip extra tables]
>
> Confusion and changing ideas.
>
> Horde Auth and Perms, AND local user stuff will ALL be available and used.
> This will all be based on user set preferences, but support for all auth/user
> backend methods will be included (that's what I'm planning).
But the auth stuff can and should be completly hidden behind Horde::Auth.
There is already a Auth backend for an sql database. Chuck suggested allowing
two separate auth configurations (and I guess this could be extended to any
number of auth sources if that would be useful), one for public and one for
non-public. The Perms:: methods would then give all relevant info for what
should be displayed to and allowed from the current user. This is necessary
to completely integrate with the Horde framework - it will restrict the
possible setups if whups uses it's own private auth system.
> [snip Whups.php -> WhupsPublic.php]
>
> The file changes were only for infrastructure and a good idea of what is to
> come. The WhupsPublic.php will massively change...also I copied
> WhupsPublic.php instead of copying details.php to detailsPublic.php. Whups.php
> will be the backend for authenticated users and WhupsPublic.php will be the
> backend for Public (unauthenticated) users. Are you starting to see what I was
> working towards?
Well, I don't think this is the right approach. Most of the code in Whups.php is
essential for a working system and won't change no matter who you're logged in
as, for example the useForms function. In fact, the only part of Whups.php that
could possibly change is the section headers.
To make this as easy to maintain as possible, I would suggest code more like this:
if (Perms::hasPerm('system', Auth::getAuth(), 'view-admin-section'))
$sections['admin'] = $adminsection;
(note, I haven't looked closely at how the auth and perms work yet, so this is
only an example.) The same goes for the details.php page. This contains all of
the 'whatnow' logic which won't change, just whether you're allowed to do it.
In fact, it could even be done transparently through the Form->isValid() method
which could do the permission check and return false if you're access is denied.
Rob.
--
Klein bottle for sale ... inquire within.