Actually I guess this still makes sense. Still queue-based, just less 
specific. Some things to work out of course.

I've changed my mind on this for now.

I think that's the most important thing that's left missing. Attribute 
support has otherwise matured a lot recently. We actually already have 
support for arbitrary Horde_Form fields for attributes, but only 
through the attributes hook. All that would need to be done is to 
extend the attributes table to include the Horde_Form field type and 
the interface to include a drop down list of available form fields 
(take ulaform as an example).
This doesn't belong to this ticket and is actually something we would 
like to approach with a developer bundle.

Chuck, can you comment on "full attribute support": what will be 
included, when will it be available, other tickets that relate to this 
support, etc?



This ticket seems to relate to one need we have, which is to have more 
robust attributes: enum, multi-select, radio, etc.  Extrapolating from 
this, and looking a little further down the road, we'd really like to 
see Whups more strongly integrated with other key tools in Horde:

* nag -- so that tickets can be quantized

* wicked -- so that better formatting can be applied

* hermes -- so that better effort estimates may be tracked/computed

* agora -- so more creative & collaborative communication can occur



If there were a little more documentation on how to make framework 
elements speak to each other, and if we knew where the Horde system 
was moving as a whole, and if we knew the status of this particular 
request as a whole, we could tackle these independently and provide 
patches.

See ticket 1078 for some additional requirements.

Once full attribute support is done, Version can just be an attribute 
instead of a special case.