| Summary: | ASTERISK-17189: [patch] CEL logging to ODBC Eventtype error on userdefined type | ||||
| Reporter: | Bryant Zimmerman (zktech) | Labels: | |||
| Date Opened: | 2010-12-30 09:42:18.000-0600 | Date Closed: | 2012-02-01 11:48:01.000-0600 | ||
| Priority: | Major | Regression? | No | ||
| Status: | Closed/Complete | Components: | CEL/General | ||
| Versions: | Frequency of Occurrence | ||||
| Related Issues: |
| ||||
| Environment: | Attachments: | ( 0) patch.18559.18560 | |||
| Description: | When storing user defined events to an ODBC source the eventtype should be equal to USER_EVENT currently it is being stored as the same value as in userdeftype field. Based on what the documentation states if you use an event name other than what is in the list below. It will be stored as USER_EVENT (field eventtype) with the user event name being stored in the field userdeftype. I have talked with murf and he said this is somthing he may be able to fix. ****** ADDITIONAL INFORMATION ****** ; ALL -- Generate entries on all events ; CHAN_START -- The time a channel was created ; CHAN_END -- The time a channel was terminated ; ANSWER -- The time a channel was answered (ie, phone taken off-hook) ; HANGUP -- The time at which a hangup occurred ; CONF_ENTER -- The time a channel was connected into a conference room ; CONF_EXIT -- The time a channel was removed from a conference room ; CONF_START -- The time the first person enters a conference room ; CONF_END -- The time the last person left a conference room (and ; turned out the lights?) ; APP_START -- The time a tracked application was started ; APP_END -- the time a tracked application ended ; PARK_START -- The time a call was parked ; PARK_END -- Unpark event ; BRIDGE_START -- The time a bridge is started ; BRIDGE_END -- The time a bridge is ended ; 3WAY_START -- When a 3-way conference starts (usually via attended xfer) ; 3WAY_END -- When one or all exit a 3-way conference ; BLINDTRANSFER -- When a blind transfer is initiated ; ATTENDEDTRANSFER -- When an attended transfer is initiated ; TRANSFER -- Generic transfer initiated; not used yet...? ; HOOKFLASH -- So far, when a hookflash event occurs on a DAHDI ; interface ; USER_EVENT -- Triggered from the dialplan, and has a name given by the ; user | ||||
| Comments: | By: Steve Murphy (murf) 2010-12-30 15:19:20.000-0600 The current code overlays the USER_DEFINED in the event name with the user defined name. This is a little redundant, but anyone with existing code will be hard-wired for this behavior. So, I am going to add a cel config file option to show the USER_DEFINED as a type if the option is set. If it is not, then you get the existing behavior. By: Bryant Zimmerman (zktech) 2010-12-30 15:53:52.000-0600 I believe that the default should be to have the option set to display the USER_DEFINED and then overlay it if off or not there. To me this would be more consistent going forward and stay true to the origional documentation. Rarther than living with a confusing situation and changing it with 1.10 when there are more apps depending on CEL. It realy comes down to how many users of CEL would be effected now or latter? Also is it USER_DEFINED or USER_EVENT as listed above from the config? By: Bryant Zimmerman (zktech) 2010-12-30 16:00:53.000-0600 murf I am placing a note here so anyone else will know of the other issue that we are working on as well. https://issues.asterisk.org/view.php?id=18560 ASTERISK-17190 Thanks for your help. By: Steve Murphy (murf) 2010-12-30 18:01:46.000-0600 I have attached a patch that is aimed at both this bug (18559) and 18560. Sorry, I should probably split it up, but... It's more efficient for me to do both together. As to the config var being default off/on, all I know is that the fundamental principal is that a "fix" should not louse up existing users. And it is possible that switchvox is an existing user. So, the number of installations might be actually be pretty large. Test out the above and let me know if it hits the spot, and unless the community objects, I can fold this into 1.8.x and trunk. By: Bryant Zimmerman (zktech) 2011-01-03 08:50:40.000-0600 How might this patch effect filtering and alias. If a user wants to filter against the name of one of their custom events? I just thought of this as I was looking at the filter. Also do you have any simple directions on applying a patch it has been a while. Will I need to upgrade to the latest SVN to apply it or will the SVN I have be adquate? Thanks Bryant By: Josep Casals C (joscas) 2011-01-03 10:00:39.000-0600 Regarding the usage of USER_EVENT or USER_DEFINED, please see also this issue addressing that point: https://issues.asterisk.org/view.php?id=18461 ASTERISK-17096 By: Steve Murphy (murf) 2011-01-04 13:37:44.000-0600 o apply a patch, first cd to the asterisk source directory, top level (you know, with the apps, cdr, cel, pbx &etc subdirs.) Then say patch -p0 < <patchfile> It should go fairly smoothly. This patch is against trunk; If you are using one of the 1.8.x releases, then you may get some notice of offsets. If you get outright errors, let me know your version of asterisk, and I'll make an alternate patch. By: Steve Murphy (murf) 2011-01-04 13:47:03.000-0600 As to 18560; and 18461; my bad! I didn't search for bugs; I had erroneously concluded that if no category had been invented for CEL, that no CEL bugs must have been filed yet. I do make such logical jumps here and there. Anyway, I created the categories. I hope that I haven't stepped on anyone's toes in so doing! I looked at the other patches, and it seems to me we are in sync. As to filtering and alias; I think they apply to column names, and any actions to take on custom event types are best done in the realm of your applications; the current setup shouldn't slow you down. By: Richard Mudgett (rmudgett) 2012-01-13 18:10:41.820-0600 The original patch made the change for all backends whether they could support it or not. The new patch makes each updated backend able to support the change independent of the other backends. See reviewboard link for new patch: https://reviewboard.asterisk.org/r/1669/ | ||||