[Vtigercrm-developers] Reports-Charts

Thu Aug 28 17:27:43 GMT 2014

Mel,

Can you repeat the steps on demo.vtiger.com and report the same?

*Connect with us on: *Twitter <http://twitter.com/vtigercrm> *I* Facebook
<http://www.facebook.com/pages/vtiger/226866697333578?sk=wall> *I* Blog
<https://blogs.vtiger.com/>* I* Wiki
<http://wiki.vtiger.com/index.php/Main_Page> *I *Forums
<https://discussions.vtiger.com>*I* Website <https://www.vtiger.com/>

On Thu, Aug 28, 2014 at 7:45 PM, Mel <m.brummell at btinternet.com> wrote:

> Hi,
>
> I have just updated to 6.1ea.
>
> Just checking to see if it's a problem with me doing the updates (as did
> each change manually from svn changeset 14222) or whether its just work in
> progress. When I go to Reports - Add Report - Charts I am presented with
> Report Details arrow, Filters and Select Chart but clicking on these does
> nothing. I have an empty screen.
>
> Regards
>
>
> Mel
>
>
> -----Original Message-----
> From: vtigercrm-developers-bounces at lists.vtigercrm.com
> [mailto:vtigercrm-developers-bounces at lists.vtigercrm.com] On Behalf Of
> vtigercrm-developers-request at lists.vtigercrm.com
> Sent: 28 August 2014 14:17
> To: vtigercrm-developers at lists.vtigercrm.com
> Subject: vtigercrm-developers Digest, Vol 103, Issue 320
>
> Send vtigercrm-developers mailing list submissions to
>         vtigercrm-developers at lists.vtigercrm.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
>
> http://lists.vtigercrm.com/cgi-bin/mailman/listinfo/vtigercrm-developers
>
> or, via email, send a message with subject or body 'help' to
>         vtigercrm-developers-request at lists.vtigercrm.com
>
> You can reach the person managing the list at
>         vtigercrm-developers-owner at lists.vtigercrm.com
>
> When replying, please edit your Subject line so it is more specific than
> "Re: Contents of vtigercrm-developers digest..."
>
>
> Today's Topics:
>
>    1. Re: Asterisk Good News (vtiger at camden.net)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 28 Aug 2014 09:16:39 -0400
> From: "vtiger at camden.net" <vtiger at camden.net>
> To: "Prasad" <prasad at vtiger.com>,
>         "vtigercrm-developers at lists.vtigercrm.com"
>         <vtigercrm-developers at lists.vtigercrm.com>
> Subject: Re: [Vtigercrm-developers] Asterisk Good News
> Message-ID: <36b5e32778e44acda2bacb054ef48c13 at camden.net>
> Content-Type: text/plain; charset="us-ascii"
>
> I dont think there is "issue" with the java proxy approach, what I think is
> issue is this AGI-AMI hybrid thing you have going on, AGI is notoriously
> more difficult to program in to begin with, you literally have to write a
> proper handler for every event that might occur, plus AGI and AMI are not
> inherently meant to work together
>
>  this is pretty easy with IVRs, we know we are sending caller there, and we
> can except a few limited outcomes, plus you have to use AGI to capture
> input, but with just a regular phone call there are to many things that can
> happen and we are not expecting input to capture
>
>  last night we fixed up our test servers but removed the agi fire for
> inbound context, so we are only running the [vtiger_outbound] this means no
> inbound notification and no logging and voice recording of calls of those
> calls, we are going to test if this thing stays stable for just click to
> call in light of that you also found issue where inbound can be sent to
> endless loop
>
>  in our limited testing (just one night) we noticed AMI streaming data in
> your webapp.sh on a inbound call without the agi fire, with some error
> messages we think are related to it was expecting the AGI to fire, it did
> not seem to effect anything and so far has not locked up and continues to
> work
>
>  we know your using the AMI to originate outbound, and it seems your using
> AMI for at least part of the inbound, so the question remains why AGI at
> all, you guys say its to limited overhead and cut down on data you need to
> phrase, yet your phrasing it anyway?? if you want to cut down the data you
> get from the AMI stream, have the AMI user have originate and read call
> only
> rights, you will only get data the pertains to actual phone calls and cut
> out 95% of the data AMI would normally stream that you dont care about
> anyway
>
>  now with AGI gone, your problems will be gone, you wont be able to as
> easily do your own CDR logging, and you wont be able to force all calls to
> be recorded (a function we dont think you should be doing anyway) however
> the CDR in vtiger is a good idea but there is better option
>
>  use the existing SQL CDR data Asterisk will provide, you say you want to
> use a API, so write one, we think that is better idea that opening SQL to
> world if vtiger and Asterisk are not on same computer anyway
>
>
>  write a php file that you would have asterisk admin put on asterisk server
> where Apache can serve up, in that php file, you need to pass it the
> extension and phone number(s) you are going to pull data for, have the php
> run the sql statements and return the data you want (date, time, callerID,
> source, destination, duration), we would use XML put there are lots of
> choices
>
>  if you have free PBX check out the user panel, specifically the call
> monitor, what you want to do is reconstruct that but only the extension and
> phone numbers for that instance, you may want to drop the extension search
> part so if I click on a contact then go to PBX manger I see all calls to
> and
> from that contact and which colleges of mine took or placed those calls
>
>  also if asterisk was told to record a call you will notice in the user
> panel under call monitor there is a column "monitor" if there is a
> recording
> there be 2 icons, one to download the sound file and one to listen to it,
> you could do the same, however I would advise to have access to recording
> off by default with the option for the vtiger admin to allow access on a
> per
> user basis
>
>  the above would allow vtiger to tie all calls in asterisk to vtiger
> records, something AGI can never do, you have no control over forcing uses
> to click to call out of vtiger, If I know a phone number, Im not going to
> go
> searching for it to click on it, as result the call will not show in
> vtiger,
> will vtiger log call on inbound if user was not logged into vtiger?
> we have not tested, but if the vtiger PBX CDR records are incomplete they
> are no good
>
>
>
> ----------------------------------------
>  From: "Prasad" <prasad at vtiger.com>
> Sent: Thursday, August 28, 2014 12:21 AM
> To: "vtiger at camden.net" <vtiger at camden.net>,
> "vtigercrm-developers at lists.vtigercrm.com"
> <vtigercrm-developers at lists.vtigercrm.com>
> Cc: "Akshath T.A" <akshath.t at vtiger.com>
> Subject: Re: [Vtigercrm-developers] Asterisk Good News
>   The proxy approach taken would help us stay loose coupled with Asterisk
> and provide neutral interface to Vtiger. This benefit may not be obvious
> and
> sound like a overhead  but give it a thought.
>
>  We generally lean towards working with APIs than DB with other application
> - yes there would be performance benefits but would it comes against the
> cost of maintenance and configurations. It would be the choice to consider
> when you pursuing CRM and Asterisk  to be on the same server.
>
>  As said earlier, there are many approaches possible to get the integration
> - we have taken one of them that can retain loose coupling. We are
> interested to learn other approaches experts from our community would
> evolve
> with.
>
>  Regards,
>  Prasad
>
>
>    Connect with us on: Twitter I Facebook I Blog I Wiki I Forums I Website
>    On Thu, Aug 28, 2014 at 2:01 AM, vtiger at camden.net <vtiger at camden.net>
> wrote:   I know it does not pull from asterisk DB at all
>
>  I was saying if you did it would not be necessary to pull in intervals at
> all, you pull only when data is needed, the fetch cdr by clicking on pbx
> manger was example of needed the data that would cause a pull,
>
>  if you did that it would be not be needed for vtiger to maintain its own
> call logging and CDR functions, it would also give bonus that calls make
> outside of scope of vtiger would show in PBX Manager in vtiger
>
>  also pulling from asterisk vtiger would not need to force call recording
> on
> every call, which is a waste of system resources, especially if asterisk is
> already recording calls, not just a waste of HD space but call recording
> uses CPU always introduces latency into a call so you dont want both can
> have negative impacts on call quality
>
>  by taking call recording out of vtiger you also put the decision to call
> record or not back in hands of asterisk admins and end users that want or
> dont want call recording, call centers are the only business In my
> experience that want every call recorded no matter what, they typically do
> it out of a call queue and have an announcement to satisfy legalities "your
> call may be recorded for quality and training" most everyone else typically
> just wants the feature code to turn it on and off on the fly
>
>
>
>
>
>
>
>
> ----------------------------------------
>  From: "Akshath T.A" <akshath.t at vtiger.com>
> Sent: Wednesday, August 27, 2014 3:45 PM
> To: vtiger at camden.net
> Cc: vtigercrm-developers at lists.vtigercrm.com
> Subject: Re: [Vtigercrm-developers] Asterisk Good News
>
>     ?Vtiger will not poll asterisk DB every time when user clicks on
> PBXManager to fetch CDR. Once the call is disconnected connector would send
> the CDR event and vtiger would store these information in
> "vtiger_pbxmanager" table. So whenever PBXManager is opened Vtiger fetches
> information from this table and displays it for the user.
>
>
>  regards,
>  AKshath
>
>        On Wed, Aug 27, 2014 at 9:42 PM, vtiger at camden.net
> <vtiger at camden.net> wrote:    yes the overhead for AMI listen can be issue
>
>  normally dealt with by giving the AMI user Origination and Read Call only
> rights, that cuts down on 99% of what you need to parse
>
>  in larger deployments where even the overhead of incoming calls to other
> extensions is burdensome, AMI proxy where each user has a proxy user that
> only listens to AMI data relevant to there own channel(s)
>
>
>  I would think you would only pull SQL data when user in vtiger clicks on
> PBXmanager (the user version where they can see the call logs, not the one
> for admin to change settings), and display the data rather than pulling it
> all the time and creating your own tables, if remote access to SQL is the
> concern its easy to write a php XML API, thats how our windows based call
> notification works for vtiger so we did not have to open SQL to outside
> world, when call comes in we take incomming phone number send it to our
> API,
> the API does all the SQL queries, then returns XML of the results, we did
> this with php, all that would be required is for you guys to say hey put
> this php file on your asterisk server and modify the database name, user
> and
> secret to match
>
>
>
>
>
>
> ----------------------------------------
>  From: "Akshath T.A" <akshath.t at vtiger.com>
> Sent: Wednesday, August 27, 2014 11:09 AM
> To: vtiger at camden.net
> Cc: vtigercrm-developers at lists.vtigercrm.com
> Subject: Re: [Vtigercrm-developers] Asterisk Good News
>
>
>   VtigerAsteriskApp does not modify any configuration of Asterisk directly.
> We have recommended changes to be made in Asterisk configuration to get the
> AGI request back to the App. Please make sure to track the changes in case
> you need to revert back.  AGI vs AMI  AGI events are listened for incoming
> calls as AMI event parsing had to deal with bit-of overhead  (as we did in
> 5.4.0 Asterisk Integration). To origniate outgoing call AMI action is used
> (borrowed from our earlier implementation).  Working with AGI events is
> lot-easier than processing AMI ourselves. The hard-work is taken care by
> the
> asteriskjava library.
>
>  Polling Asterisk DB from CRM server was not a model considered as both the
> applications can be setup on different machines.  Also php script used for
> regular polling in short-intervals (specially during active call handling)
> demands server resources and impatcts CRM performance - we had encountered
> this in our earlier implementation.
>
>  The approach of implementation we have taken may not be the only way to
> get
> the integration. We are hopeful to see more such coming from community and
> take away the learning from the same.
>
>
>  regards,
>  AKshath
>
>
>
>
>       On Wed, Aug 27, 2014 at 7:39 PM, vtiger at camden.net
> <vtiger at camden.net> wrote:     yes I am aware of what it was saying... but
> 101 was most certainly a valid extension, at the same time this was going
> on
> we could send our own origination command to AMI for 101 to call out and it
> worked just fine, that error is not produced by asterisk at all, its not a
> valid asterisk error return, you are mis-interrupting some other error and
> reporting it back as a asterisk error
>
>  I think it was some error inside your java, at the time this was happening
> we only saw data stream on webapp.sh on the click to call attempts, we
> where
> also looking at data streams on your agi.sh saw nothing, the cli with agi
> and verbose 10 notifications enabled saw nothing, and we also looking at
> the
> AMI stream, nothing there as well, so we dont even think your connector was
> even talking to asterisk at all
>
>  we fixed the issue last night, stopped the webapp.sh and agi.sh files and
> prevented them from start @ boot, rebooted, cleared settings in vtiger PBX
> manager or rather put in a bunch of junk, saved, rebooted, put settings
> back
> into PBX manager, rebooted then turned the .sh files back on, not sure what
> steps fixed but simple stop and start of .sh files and/or system reboots
> did
> not fix
>
>
>  we still have issue on on test server where it seems vtiger  altered
> something in asterisk where all the extensions we had in vtiger no longer
> will ring though a call queue, we have no data on the event we where not
> actively monitoring data streams, and your asterisk connector has never
> written 1 log to its own log directory, everything was working Friday, and
> Monday we checked on it again and found that vtiger was stuck in endless
> loop of inbound notification and those extensions would no longer sent a
> sip
> invite though call queue, even after they where removed from vtiger and a
> reboot, and the asterisk connector was completely shut down, keep in mind
> these are test servers dedicated to getting vtiger to work, they are lamp +
> asterisk + freepbx + vtiger only we have not moved into phase of testing
> with other packages so the problems we are having can only be vtiger, this
> is what concerns us about closed source java+agi, beyond we can not see
> code
> to try to help you we now have situation where it seems your connector and
> AGI have altered asterisk, we dont know whats it doing.
>
>  the whole reason we advocate for just use the AMI is its simple and works
> and your not really doing anything that requires the interactivity that AGI
> allows, AMI can be used to originate call as well as be monitored for
> inbound, this is how tapi drivers work that plug into on site CRMs like
> ACT,
> SAGE CRM, Lexis Nexus, ect, its also how sugar / sweet crm are handling it
>
>  I think the tiring the call records to data in vtiger is a great idea, but
> why are you generating your own CDR log's via AGI, and this is where I
> think
> you guys are hung up on using AGI, but asterisk does have it own MySQL
> tables and CDR reccords, why not during the isntall of vtiger ask for the
> asterisk database name and credentials and query them for the info, and
> vtiger should not be forcing all calls to record, asterisk gives us ways to
> record and not record calls, if you want to link to recordings fine but
> again you should be looking to see if a call was recorded, beyond a
> performance issue and potential duplication of whats already being done in
> the Asterisk, this ventures into a legal issue, a lot of places all parties
> must be notified and consent to call recording, with vtiger it forces the
> recording
>
>  the general rule of thumb here is if you need user input like your making
> a
> IVR and logging what was entered then you need AGI, if your just
> originating
> calls and monitoring for inbound use AMI, in either case SQL should be used
> to get call record data
>
>  AGI has it problems that you are unnecessarily dealing with, they are
> common for AGI, what if my agi script finishes before the call ends, what
> if
> the call ends before my agi script finishes and a whole host of other
> issues that you simply dont need to deal with for what your trying to do
>
>
>
>
>
>
>
>
>
>
>
>
> ----------------------------------------
>  From: "Akshath T.A" <akshath.t at vtiger.com>
> Sent: Wednesday, August 27, 2014 3:19 AM
> To: vtiger at camden.net
> Subject: Re: [Vtigercrm-developers] Asterisk Good News
>   Hi,
>
>  From the logs, it clearly states that the extension - 101 was not found by
> your Asterisk server when AMI originate request sent from Vtiger Connector.
>
>  In order to nail down the issue, can we have a online meeting today or
> tomorrow so that it would help us know what really is causing the problem.
>
>
>  I will be available from 9:00 AM to 8:00 PM IST at my office. Please tell
> us your convenient time within this so that I can send you meeting link.
>
>  Thank you.
>
>
>  regards,
>  Akshath
>    Vtiger
>
> _______________________________________________
> http://www.vtiger.com/
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <
> http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20140
> 828/8dcaf2c1/attachment.html>
>
> ------------------------------
>
> _______________________________________________
> vtigercrm-developers mailing list
> vtigercrm-developers at lists.vtigercrm.com
> http://lists.vtigercrm.com/cgi-bin/mailman/listinfo/vtigercrm-developers
>
>
> End of vtigercrm-developers Digest, Vol 103, Issue 320
> ******************************************************
>
> _______________________________________________
> http://www.vtiger.com/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20140828/b93989b8/attachment-0001.html>