[sork] fixes to vacation to address items in TODO

[Eric Rostetter]

Quoting John Woodell <woodie at netpress.com>:

> > > - The user does not need to provide their password or aliases.
> > >   The password comes from horde, and the aliases come from ldap.
> >
> > The first is a security issue ... the second is a bad assumption...
>
> I could also scrape them from the /etc/aliases file.

We'd probably need a hook or class function to do this, so we could handle
ldap, sql, files (/etc/aliases, etc), and so on.

> > >   Note: in the distro, the the aliases feature was broken,
> > >         whatever you entered was simply ignored.
> >
> > This was fixed a long time ago in CVS but a new release was never made
> > including it.
>
> but does it allow multiple aliases?

Not sure, I'd have to check...  If not, it is a known bug.  If so, then
the bug was fixed. ;)

> > > - The subject and message are now two fields.
> >
> > That is probably a reasonable change, if done correctly
> > (to handle the user not specifying a subject, etc).
>
> The documentaton for the unix vacation program does not indicate
> that no subject will work.

It is going to depend on your vacation program, etc.  A way to deal with
it, which is all I was asking, is to provide a "default" if none is specified,
etc.

> > > - The 'live' vacation message and subject are always
> > >   displayed when the notice is active.
> >
> > This assumes you can access them.  Not always the case.
>
> Not true, If looking locally (as I have done) fails,
> you can then grab the .vacation.msg via ftp.

And if you can't get them via ftp?

> > >   Note: in the distro, the text of your message is always replaced
> > >         by the default text... which feels like a bug.
> >
> > This isn't correct.  It may be this way for some drivers,
> > and some setups, but it is not always this way.
>
> In the version I started with, the default text was in the template,
> and there was no mechanism to set it to something else.

Either you started with an old version, or you are not correct.

> > > - The radio buttons go away when the .forward file exists
> > >   so there is no way to cancel when notice is unset, and the
> > >   text properly reads 'update' which is what actually happens
> > >   when the notice is set.
> >
> > Sounds like a good feature.
>
> This is using the 'vacation_active' function, which also needs
> to be able to fail over to ftp for sendmail setups.

It needs to be able to handle any backend, not just ftp.  Whether it should
"fail over" is a matter for debate.  We could instead do this with a
composite driver perhaps, though I'm not sure how clean or ugly that might
get.  We'd have to look into that.

> Well, I have no idea how to design a horde module or driver.

Subscribe to the dev at lists.horde.org and start asking. ;)

> I don't know anything about PHP, in fact I started writing
> PHP one week ago (I'm a perl guy), so I would need a horde mentor.

Someone is probably available.

> If you have time to explain how I should do what you suggest,
> I can do all the gruntwork and testing.  ;-)

I don't have much time, but maybe someone else @horde.org does.  If not,
you're welcome to what little time I do have.

> On the technical side, my vacationtime perl script uses the 'at' command
> to start and stop the notice, which is not especially portable.

We can use non-portable things if needed, or we can extend them if needed.
There's a new horde scheduler class that might work for this, etc.

> My vacationtime program will need for put a properties file in the homedir
> (not the .forward file), then login at the user to call 'vacationtime set'.
> The '.forward' file no longer tell the complete story. The status needs
> to come from loggin in as the user, and calling 'vacationtime status'.

Should be possible.

> The only way I have to do this behind-the-scenes login is to use the
> perl expect module in a cgi page that PHP calls using an http agent.

We can run expect if needed (see the passwd module expect driver).

> It feels like a horde module that requires a perl command-line tool,
> and a perl cgi to do remote login is not what horde is about.

We use expect (not always perl, my expect is a binary) already in sork, and
can expand vacation to use it if needed.  There is no need to use perl per se.

Your perl scripts of course can stay in perl, no problem there.  We reference
external binaries/scripts all the time.  But the code that goes into Horde
itself should be php, not perl.

> Thanks for your suggestions. I hope to hear from you again.

Done.

--
Eric Rostetter
The Department of Physics
The University of Texas at Austin

Why get even? Get odd!