Huh? Where're the web_vars going?

[kimhoogenberg]

Hi all,

In vicidialnow, we used web_vars quite a lot. Now we're upgraded to a fresh install (vicidial 2.2.1) and migrated database.

We depended highly in our CRM-integrated solution on the web_vars for users / inboud-group mapping. It seems as if I can manage the web_vars for inbound groups and campaigns at the user's page, but the script won't let me use it.

The documentation speaks of web_vars use in scripts on the user page, but it doesn't come up with this possibility on the script edit page help anymore.

Versions:
GoAutodial CE 2.0
Vicidial 2.2.1-237 / build: 100510-2015

Some more background:
We pass our only script for every ingroup (customer so to say) / every user (configured on the user's page, behind the checked ingroup) a customer id and a username. Like the string "2/index.php?username=john.doe". This part was then used by a little piece of javascript to build the URL which is used for a full blown div loading the CRM for the customer and call handling (dispositioning, transfer, hangup, also fax, sms, et cetera) functionality into a fullscreen (that is, the browser's screen) iframe.

So, that's why I need the web_vars, but I'm stuck in using them now.

Anyone?

[williamconley]

web_vars? can you point me to a url demonstrating what you mean by web_vars? perhaps where one is defined or entered?

[kimhoogenberg]

Select a user to edit. Scroll down to the list where you can select ingroups for that particular agent to get calls for. Behind those ingroups, I'm used to define web_vars.

[williamconley]

You mean where "Custom 1" through "Custom 5" are now?

[kimhoogenberg]

Not in my 2.2.1 version. Those custom ones are located just below the ingroup selection table (where web_vars is/was). :s

[williamconley]

And I don't suppose it is possible that those are the new names for the web vars?

[mflorell]

Are you putting them in a script or in a web form somewhere?

Can you show us an example of how exactly you are using them?

[kimhoogenberg]

First of all, it was working before in vicidial 2.0 or so. I see that inbound calls are received, in the same table row as where the web_vars are defined, at the edit user screen, just above the 5 custom fields.

In our production version, we pass uniqueid and web_vars to some url from the script (script fraws an iframe, that iframe builds a fulle screen div with another iframe, loading a crm system in the context of the inbound customer, using as a part of the url those web_vars (combination of customer id and username to access the crm. Those are because of that authentication process and because of the crm/customer context defined at each user page, per specific inbound group for that user.

Hope this clears things up? No bells ringing?

[mflorell]

Can you show us an example of how exactly you are using them?

[kimhoogenberg]

What's the difference? Something like iframe.html?uniqueid=--A--uniqueid--B--&url=--A--web_vars--B--

[mflorell]

I can't test for your exact conditions unless you supply the exact parameters that you have set up.

[kimhoogenberg]

Allright. That would mean you would need extra databases, SMS-provider, custom CRM-system with depending files. Or... Just say something about:

- web_vars can be defined at a user's page, right? The info-button pops up help about this web_vars field, which tells me that it can be used in scripts;
- the scripts edit page has also a help page and it shows a lot of (mostly familiair) variables that I could use, but not the web_vars.

What part of what I'm trying to tell is not clear?

Do you still know of the web_vars parameter that once was there or doesn't the name just don't ring a bell?

[kimhoogenberg]

Also, in addition to my posts, the script translates --A--WEB_VARS--B-- to --A--WEB_VARS--B--, suggesting me, it is just ignored nowadays, while the help page at the user edit screen tells me to fill out web_vars and use it in scripts like --A--WEB_VARS--B--, which still works for other parameters, like --A--UNIQUEID--B--, but not for --A--WEB_VARS--B--.

[williamconley]

Custom User Fields - These five fields can be used for various purposes, and they can be populated in the web form addresses and scripts as user_custom_one and so on.

[kimhoogenberg]

Again, above those custom fields, I have a list of ingroups which I can select to be active for a user, also with a ranking and a web_vars field per ingroup.

If that isn't an option you've got, which I doubt, lets try it the other way around.

I need a dynamical combination of custom usergroup (inbound) id and username to put in a script. Those custom fields at a user page just fix it half for us. We could fill out the user's name there, but the ingroup can be anything at that point.

Does the ingroup also have those fields? Then I'm good and have an even better option then before.

Thanks anyone for thinking with me, since it doesn't seem to be very common what I'm facing.

[williamconley]

! I honestly do not remember seeing web vars there before. I don't think we've ever had a client use them.

And you're saying that you used to be able to just place web_vars in between the --A-- and --B-- in a prior version and vicidial would replace it with the value from the web_vars ... but that no longer works?

but other custom info ... DOES work in your url (have you tried the custom 1 through custom 5?)

[kimhoogenberg]

Yeah, those custom fields do work. The problem is that the web_vars were custom for that user, PER ingroup. So, let's say:
1) TNT is an inbound client for notification of employee illness;
2) TNT puts an internal phone number though to a DID in our system;
3) This DID leads to an INGROUP;
4) A script is ran;
5) At that time, the script needs to pass a client id and the username in an URL.

We managed this using web_vars. Custom field for a user alone doesn't work (for this situation, works in general), because we also need the client's (ingroup related) id, which is an ID, maintained by the custom CRM used.

So, an url needs to be built like: <iframe src="index.php?username=--A--user-specific-info--B--&id=--A--ingroup-specific-info--B--"/>

Does the ingroup take custom fields now too? Then I've got a good solution combining those two I think.

[williamconley]

Sounds like a bug, but as matt said: you need to post EXACT (remove your FQDN) data for a working and non-working version (and post the vicidial version with build for each so we know when it worked and when it didn't in the source code).

post the web var content and the URL entered and which web form method for the campaign/ingroup (which field of the campaign or ingroup, and the entire URL entered into it).

Don't paraphrase it or explain it with the example ... POST the example, explain AFTER if you feel a need, but the data should speak for itself, right?0

Can you show us an example of how exactly you are using them?

[kimhoogenberg]

Does the ingroup take custom fields now too? Then I've got a good solution combining those two I think.

[mflorell]

Looks like there is a bug with per-user web_vars and scripts. Honestly, we've never had a client use them with scripts, only with web forms. I should have it fixed in SVN by the end of the day.

[kimhoogenberg]

Great! Would be nice to have that working again!

Can you tell me if there're db or script changes when we want to migrate from current version to svn? (Current build in first post) Can we just replace the admin php files or is there more to it?

[mflorell]

It's now fixed in SVN/trunk and SVN/branches/agc_2.2.0, so you should just be able to grab the www/agc directory of the 2.2.0 branch and use that.

Of course you will get a lot more features if you upgrade to SVN/trunk, but there is a lot more involved i that than just copying some files.

[williamconley]

Vicidial Wiki has a link to "SVN: How To". Inside the SVN download (which ONLY downloads new source files, make no changes to your system) there is an UPGRADE.txt document which explains the process in detail.

You likely have this document in your existing install which would explain how to upgrade to get where you are now. It's stored in /usr/src/astguiclient/VERSION/UPGRADE.txt

[kimhoogenberg]

Works again just fine! Thanks.