[asterisk-dev] [Code Review] testing CDR(accountcode) being carried over into local channels

[Terry Wilson]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1765/#review6026
-----------------------------------------------------------

Ship it!


Clever! I like it. Quadratic scaling much better than factorial. ;-)

- Terry


On April 17, 2012, 4:55 p.m., wdoekes wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1765/
> -----------------------------------------------------------
> 
> (Updated April 17, 2012, 4:55 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> There's a change in the CDRs between 1.6.2 and 1.8 with regards to the CDR(accountcode).
> 
> I created an example:
> 
> exten => 1,1,Set(CDR(accountcode)=initial)
> exten => 1,n,Dial(Local/2 at default)
> exten => 2,1,Dial(Local/3 at default)
> exten => 3,1,Set(CDR(accountcode)=third)
> 
> Master.csv of 1.6.2:
> 
> "third","","3","default","","Local/3 at default-ABCD;2","","Hangup","","2012-02-22 00:00:00","2012-02-22 00:00:00","2012-02-22 00:00:00",0,0,"ANSWERED","DOCUMENTATION","1329946580.5",""
> "initial","","2","default","","Local/2 at default-ABCD;2","Local/3 at default-ABCD;1","Dial","Local/3 at default","2012-02-22 00:00:00","2012-02-22 00:00:00","2012-02-22 00:00:00",0,0,"ANSWERED","DOCUMENTATION","1329946580.3",""
> "initial","","1","default","","Local/1 at default-ABCD;2","Local/2 at default-ABCD;1","Dial","Local/2 at default","2012-02-22 00:00:00","2012-02-22 00:00:00","2012-02-22 00:00:00",0,0,"ANSWERED","DOCUMENTATION","1329946580.1",""
> "","","1","default","","Local/1 at default-ABCD;1","","Echo","","2012-02-22 00:00:00","2012-02-22 00:00:00","2012-02-22 00:00:00",0,0,"ANSWERED","DOCUMENTATION","1329946580.0",""
> 
> .. seems logically ordered.
> 
> Master.csv of 1.8:
> 
> "","","2","default","","Local/2 at default-ABCD;2","Local/3 at default-ABCD;1","Dial","Local/3 at default","2012-02-22 00:00:00","2012-02-22 00:00:00","2012-02-22 00:00:00",0,0,"ANSWERED","DOCUMENTATION","1329946580.3",""
> "third","","3","default","","Local/3 at default-ABCD;2","","Hangup","","2012-02-22 00:00:00","2012-02-22 00:00:00","2012-02-22 00:00:00",0,0,"ANSWERED","DOCUMENTATION","1329946580.5",""
> "initial","","1","default","","Local/1 at default-ABCD;2","Local/2 at default-ABCD;1","Dial","Local/2 at default","2012-02-22 00:00:00","2012-02-22 00:00:00","2012-02-22 00:00:00",0,0,"ANSWERED","DOCUMENTATION","1329946580.1",""
> "","","1","default","","Local/1 at default-ABCD;1","","Echo","","2012-02-22 00:00:00","2012-02-22 00:00:00","2012-02-22 00:00:00",0,0,"ANSWERED","DOCUMENTATION","1329946580.0",""
> 
> .. has disorder where the first record should be second, and I'm missing the CDR(accountcode) in said record.
> 
> I don't know if CSV ordering is important (although the CDR tests' add_expectation() seems to imply they are fixed), but not having the CDR(accountcode) propagated to the Local channels is an undesirable change.
> 
> 
> This addresses bug ASTERISK-19384.
>     https://issues.asterisk.org/jira/browse/ASTERISK-19384
> 
> 
> Diffs
> -----
> 
>   /asterisk/trunk/lib/python/asterisk/cdr.py 3187 
>   /asterisk/trunk/tests/cdr/cdr_accountcode/configs/ast1/cdr.conf PRE-CREATION 
>   /asterisk/trunk/tests/cdr/cdr_accountcode/configs/ast1/extensions.conf PRE-CREATION 
>   /asterisk/trunk/tests/cdr/cdr_accountcode/run-test PRE-CREATION 
>   /asterisk/trunk/tests/cdr/cdr_accountcode/test-config.yaml PRE-CREATION 
>   /asterisk/trunk/tests/cdr/tests.yaml 3187 
> 
> Diff: https://reviewboard.asterisk.org/r/1765/diff
> 
> 
> Testing
> -------
> 
> See above.
> 
> Can someone confirm that the CSV of 1.6.2 is the "correct" one?
> 
> 
> Thanks,
> 
> wdoekes
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20120419/3fcaa248/attachment-0001.htm>