[whups] Using whups moving forward

[Chuck Hagenbuch]

Quoting Mike Baptiste <mike@msbnetworks.net>:

> We're looking at using whups (and a number of other horde packages) for
> both internal and external stuff in our IT Department (Duke University's
> Engineerng School)

Great!

> I really liked seeing the 'Groups that can see this comment' option
> (though it doesn't shw any groups)  I'd love to have tickets be public
> with certain comments private to hide stuff that might compromise our
> systems, etc or just comments we wouldnt' want the public to see.  Is
> this the planned intent?

This is what it currently does; you just need to add some groups to Horde 
using the Groups administration page (/horde/admin/groups.php).

> Expanding that into permissions, are there plans to expand the
> granularity of permissions?  For example, we might want guests to be
> able to create tickets without granting them edit capability.

I've been working on this recently. Right now we don't have an 
explicit "create" permission, but if we were to add one - and I can see 
this being a good idea - we could do this pretty easily. I've been working 
on the permissions a fair amount lately; feedback on how this is working 
would be great.

> Also, it might be nice to have some type of regexp object in permissions
> so I could create a group that looks for domain duke.edu or something
> like that.  This would be a very powerful feature to help mold your
> ticket permissions across multiple projects.

I don't have plans like that, and to be honest I'm not sure how we'd tie 
that into the current groups/permissions system. Have you experimented much 
with the groups and perms administration pages?

> What are the plans for email notifications ala, ticket changes and
> notify reporter and assign to, etc  With realistic logic to avoid the 'I
> added myself as a listener' type spam from Bugzilla.

I'm not entirely sure what you mean by the last bit, though we currently 
need work on it, but if you have an email address stored in your Horde 
preferences - currently you can only do this through IMP, which needs to be 
fixed - you will get emails if you are among those reponsible for a bug or 
if you created it. You can even specify in the configuration whether to get 
all comments in change emails (in either chronological or reverse 
chronoligical order) or just the most recent one.

Again, feedback on this would be great. Patches even better. :)

> It might be nice to tie permissions to the actual 'actions' in WHups
> (Add comment, assign, set state, etc)  This would be nice to allow
> anyone to comment while restricting ticket assignment to an admin.  Same
> for state changes, etc.

Right now, only users who are logged in can assign tickets; users have to 
be logged in, or have the password they entered when they created the bug, 
to change the state or priority.

I'm open to making this more permissioned, as well.

> We're really excited about this and hope to be able to provide
> development help as we deploy this.  We eventually would like to try and
> mold a number of horde projects into a Sourceforge like environment for
> open source development at Duke.  We're just geeting our feet wet beyond
> a vanilla IMP/Turba install with whups and we'll grow from there.
> 
> Am I totally off base here?

Nope! Whups really is in progress, but I hope you'll stick with us and help 
us push it forward even more. I hope to have it running bugs.horde.org 
relatively soon, which should provide more immediate incentives to fix 
anything wrong with it.

Let us know if you have questions delving into Whups, and I hope to hear 
much more from you.

-chuck

--
Charles Hagenbuch, <chuck@horde.org>
"People ask me all the time what it will be like living without otters."
 - Google, thanks to Harpers