Caller ID Superfecta

I'm just thinking out loud there.
But instead of removing the cid source from the FreePBX database by an SQL request, couldn't we call directly the FreePBX delete cid source function (in the cid lookup page/module) that should have already the proper behavior to reallocate to a proper path.

That also would work. Is one way better than the other?
With direct sql, we have exact control over actions. If FreePBX table usage changes, then we have troubles.

With calling directly the FreePBX delete cid source function, we get the built in proper behavior. If FreePBX changes its usage of or name of this function, then we have troubles.

Thinking out loud also - which way is best?

I would really like to see this addressed for the next release. Its really bad form to leave the PBX unusable (not passing calls) after we uninstall.

In order to address some of the tickets that have been worked on in the last week or so, we are looking at needing to release 2.2.4 (core module changes). Being a terrible php coder, it could take me months to get this right.

Anyone willing to step up and correct it as per the notes in this case?

patrick_elx wrote:

I'm just thinking out loud there. But instead of removing the cid source from the FreePBX database by an SQL request, couldn't we call directly the FreePBX delete cid source function (in the cid lookup page/module) that should have already the proper behavior to reallocate to a proper path.

Yes - I think this could be the best way to do it - but well have to watch for changes to the FreePBX delete source function in future versions.

Patrick, are you able to write the code to call that function?

Coders Wanted. This is a bad bug - who will step up and work it?

Should the 'Caller ID Superfecta' cidlookup_incoming records be deleted or updated when Caller ID Superfecta uninstalled?

If deleted, use:

//delete incoming lookups
$sql = "delete c1 from cidlookup_incoming c1, cidlookup c2 where c1.cidlookup_id = c2.cidlookup_id and  c2.description = 'Caller ID Superfecta'";
$res = $db->query($sql);
//delete the line from the cidlookup table
$sql = "DELETE FROM cidlookup WHERE description = 'Caller ID Superfecta'";
$res = $db->query($sql);

If update:

//delete incoming lookups
$sql = "update cidlookup_incoming c1, cidlookup c2 set c1.cidlookup_id = 0 where c1.cidlookup_id = c2.cidlookup_id and  c2.description = 'Caller ID Superfecta'";
$res = $db->query($sql);
//delete the line from the cidlookup table
$sql = "DELETE FROM cidlookup WHERE description = 'Caller ID Superfecta'";
$res = $db->query($sql);

Note the importance of deleting/updating cidlookup_incoming before cidlookup.

--John

John - I'm reviewing your notes and question - I'll provide some feedback asap. Thank you for looking at this ticket.

Assuming cidlookup_incoming records should be deleted (waiting on your confirmation), the following will clean up any mess left behind by a previously bad uninstall:

//delete stray cidlookup_incoming records left by bad uninstall
$sql = "delete c1 from cidlookup_incoming c1 left outer join cidlookup c2 on c1.cidlookup_id = c2.cidlookup_id where c2.cidlookup_id is null";
$res = $db->query($sql);

Should be fixed with rev. 280.

QS: Pass Install / Uninstall works, and no longer leaves inbound routes inaccessible.

Tested on FreePBX 2.6 /2.7 / 2.8

Ticket awaiting feedback from other testers.

QS: Passed against FreePBX 2.6 / 2.7 /2.8

Currently, on uninstall, Superfecta will try to clean-up left-overs from a previously bad uninstall using "delete c1 from cidlookup_incoming c1 left outer join cidlookup c2 on c1.cidlookup_id = c2.cidlookup_id where c2.cidlookup_id is null", removing any orphaned cidlookup bindings.

My thought is that perhaps this should also be placed in the Superfecta installer -- just to make sure it is installing into a clean environment.

This is an interesting idea. I'm wondering if the current situation has any negatives associated with it? Is there any known issue when NOT doing this has caused problems or unexpected results? What sort of problems do you perceive might occur under perfect (bad) conditions?

The problem I could see if the clean-up code was not added to the 2.2.4 installer is:

1) Superfecta v2.2.3 (or less) is installed.
2) Superfecta v2.2.3 (or less) is configured for use on some incoming routes.
3) Superfecta v2.2.3 (or less) is uninstalled, leaving orphaned cidlookup routes.
4) Superfecta v2.2.4 is installed.
5) Ugly bits (orphaned cidlookup routes) are left behind by 2.2.3 that wont be cleaned up until 2.2.4 is uninstalled.

Hmm. Yes, that sounds undesireable allright.

Is there any down side to running the clean up upon install in all cases? From my understanding, this cleanup doesnt impact any of the modules configured settings other than the lookup source.

Do you propose running the cleanup upon install in all cases? Or just upon "fresh" installs?

John - do you have any thoughts on this?

I don't see any real downside. If the cidlookup database changes enough to the point where the statement fails, it's going to break superfecta anyway -- better that it crashes on install.

I'll add it. It will run on clean and upgrade install.

O.K., added it to install.php. see r326

These changes are available for test in 2.2.4 BETA1

If Fresh, and upgrade install exihibit no weirdness, we should be able to close this ticket.

Very exciting - this has been a serious bug for us - Thanks for stepping up John. You are making a big difference to the project.

QS: Pass. Performs as expected with no detected undesirable results. Accepted for build 2.2.4