[#10927] Allow external queue providers as plugins
Summary Allow external queue providers as plugins
Queue Whups
Queue Version Git master
Type Enhancement
State Rejected
Priority 1. Low
Owners
Requester Ralf Lang (B1 Systems GmbH) <lang (at) b1-systems (dot) de>
Created 01/16/2012 (520 days ago)
Due
Updated 01/30/2013 (140 days ago)
Assigned
Resolved 01/30/2013 (140 days ago)
Attachments
Milestone
Patch No

History
01/30/2013 05:05:24 PM Jan Schneider State ⇒ Rejected
 
01/25/2012 09:20:14 AM Jan Schneider Comment #4 Reply to this comment
Is there really a need for this, i.e. to have both Whups queues *and*
external queues?
This was inspired by a discussion on the list. Somebody asked what 
happened to their existing queues.
Yes, but wondering what happens with the old queues doesn't 
necessarily mean that both queue providers are really used.
I'm not against this, but this is quite some work, that only makes 
sense if it's actually used by more than one user.
01/25/2012 08:44:16 AM Ralf Lang (B1 Systems GmbH) Comment #3 Reply to this comment
Is there really a need for this, i.e. to have both Whups queues 
*and* external queues?
This was inspired by a discussion on the list. Somebody asked what 
happened to their existing queues.
01/24/2012 03:07:45 PM Jan Schneider Comment #2
State ⇒ Feedback		 Reply to this comment
Is there really a need for this, i.e. to have both Whups queues *and* 
external queues?
01/16/2012 04:10:16 PM Ralf Lang (B1 Systems GmbH) Comment #1
State ⇒ New
Patch ⇒ No
Milestone ⇒
Queue ⇒ Whups
Summary ⇒ Allow external queue providers as plugins
Type ⇒ Enhancement
Priority ⇒ 1. Low		 Reply to this comment
Currently, we can substitute the whups queues and versions api with 
external providers like sesha. We cannot have a combination of both 
though.

Proposal:
Allow for external providers to register API functions like
'tickets/providers/queues/$app'
'tickets/providers/versions/$app'

and loop through queues and versions exposed by the API