Changes to allow selecting a requestor from drop down list

I just put on the wiki a set of changes to allow call center folks to
chose a requestor from a drop down list when creating a ticket, as
opposed to typing in the email address. It’s at the URL below in case
someone else can use it.

http://wiki.bestpractical.com/index.cgi?SelectRequestor

Kelly F. Hickel
Senior Software Architect
MQSoftware, Inc
952.345.8677
kfh@mqsoftware.com

I just put on the wiki a set of changes to allow call center folks to
chose a requestor from a drop down list when creating a ticket, as
opposed to typing in the email address. It’s at the URL below in case
someone else can use it.

http://wiki.bestpractical.com/index.cgi?SelectRequestor

Oh, yum. :slight_smile:

We’re a contract house; this is exactly what I needed. I want to pull
it from a client list file, but I’m sure I can figure out a way to get
there from your script.

Thanks.

Any chance that will go mainline, Jesse?

Cheers,
– jra
Jay R. Ashworth jra@baylink.com
Designer Baylink RFC 2100
Ashworth & Associates The Things I Think '87 e24
St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274

"NPR has a lot in common with Nascar... we both turn to the left."
	- Peter Sagal, on Wait Wait, Don't Tell Me!

I just put on the wiki a set of changes to allow call center folks to
chose a requestor from a drop down list when creating a ticket, as
opposed to typing in the email address. It’s at the URL below in case
someone else can use it.

http://wiki.bestpractical.com/index.cgi?SelectRequestor

Oh, yum. :slight_smile:

We’re a contract house; this is exactly what I needed. I want to pull
it from a client list file, but I’m sure I can figure out a way to get
there from your script.

Thanks.

Any chance that will go mainline, Jesse?

Not a chance:

" It uses javascript, so your browser must have that enabled. The page
" that gets built ends up having every user in your database, so this may
" not work well for you if you have thousands of users.

I’d be quite curious to see a version that uses livesearch to 1) not
break the experience for users without javascript and 2) doesn’t build a
list of every user in the system for every page with a select requestor
widget.

We do have a create ticket variant with user search built in that
we’ll mainline when we get a chance.

http://wiki.bestpractical.com/index.cgi?SelectRequestor

Oh, yum. :slight_smile:

We’re a contract house; this is exactly what I needed. I want to pull
it from a client list file, but I’m sure I can figure out a way to get
there from your script.

Any chance that will go mainline, Jesse?

Not a chance:
" It uses javascript, so your browser must have that enabled. The page
" that gets built ends up having every user in your database, so this may
" not work well for you if you have thousands of users.

I’d be quite curious to see a version that uses livesearch to 1) not
break the experience for users without javascript and 2) doesn’t build a
list of every user in the system for every page with a select requestor
widget.

By livesearch, are you referring to some implementation of AJAX?

No, I guess AJAX requires JS as well.

We do have a create ticket variant with user search built in that
we’ll mainline when we get a chance.

It’s not the search that I need (and that I think someone else said
they needed as well): it’s grouping. I want the ticket to belong to
"Branch office 20", no matter which of that branch’s people sent it in.

How hard is it to get from here to there?

Cheers,
– jra
Jay R. Ashworth jra@baylink.com
Designer Baylink RFC 2100
Ashworth & Associates The Things I Think '87 e24
St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274

"NPR has a lot in common with Nascar... we both turn to the left."
	- Peter Sagal, on Wait Wait, Don't Tell Me!

I’d be quite curious to see a version that uses livesearch to 1) not
break the experience for users without javascript and 2) doesn’t build a
list of every user in the system for every page with a select requestor
widget.

By livesearch, are you referring to some implementation of AJAX?

No, I guess AJAX requires JS as well.

But, you see, it doesn’t break for users who don’t have javascript.

I’d be quite curious to see a version that uses livesearch to 1) not
break the experience for users without javascript and 2) doesn’t build a
list of every user in the system for every page with a select requestor
widget.

By livesearch, are you referring to some implementation of AJAX?

No, I guess AJAX requires JS as well.

But, you see, it doesn’t break for users who don’t have javascript.

Oh. Ok. You did mean “some implementation of AJAX”. :slight_smile:

I was looking into that idea as well, but I’m not an AJAX master.
Hopefully, someone who is will get itchy for that before me.

Cheers,
– jra
Jay R. Ashworth jra@baylink.com
Designer Baylink RFC 2100
Ashworth & Associates The Things I Think '87 e24
St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274

"NPR has a lot in common with Nascar... we both turn to the left."
	- Peter Sagal, on Wait Wait, Don't Tell Me!

By livesearch, are you referring to some implementation of AJAX?

No, I guess AJAX requires JS as well.

We do have a create ticket variant with user search built in that
we’ll mainline when we get a chance.

It’s not the search that I need (and that I think someone else said
they needed as well): it’s grouping. I want the ticket to belong to
"Branch office 20", no matter which of that branch’s people sent it in.

How hard is it to get from here to there?

Jesse doesn’t believe in a group owning a ticket. I talked to
him about this at YAPC. I see his point from purist standpoint,
but it does make it more complicated to assign a ticket to a
group, which is then eventually handled by an individual.

If you mean that a group can’t be the Requestor of a ticket,
I haven’t thought about that much.

-Todd

We do have a create ticket variant with user search built in that
we’ll mainline when we get a chance.

It’s not the search that I need (and that I think someone else said
they needed as well): it’s grouping. I want the ticket to belong to
"Branch office 20", no matter which of that branch’s people sent it in.

That sure sounds like you want to make the “Branch office 20” group a Cc
or Requestor of the ticket. Maybe a scrip to do an LDAP lookup on
create?

We do have a create ticket variant with user search built in that
we’ll mainline when we get a chance.

It’s not the search that I need (and that I think someone else said
they needed as well): it’s grouping. I want the ticket to belong to
"Branch office 20", no matter which of that branch’s people sent it in.

That sure sounds like you want to make the “Branch office 20” group a Cc
or Requestor of the ticket. Maybe a scrip to do an LDAP lookup on
create?

Hmmm… It says you qouted me, but didn’t actually quote anything
I said. I was just making a comment on someone else’s inquiry.

-Todd