Superfecta Pull Request

[lgaetz (Lorne Gaetz)]

We have a pull request for Superfecta from Mark Hassman here:

https://git.freepbx.org/projects/FREEPBX/repos/superfecta/pull-requests/72/overview
https://git.freepbx.org/plugins/servlet/jira-integration/issues/FREEPBX-23262

Currently, the Superfecta Send-To sources are only polled if Superfecta actually finds a Caller ID name matching the CID number. If no name is found, the Send-To sources are not polled making it less useful for notifications etc. It’s one of the reasons why I created the Abandon Lookup source for Superfecta, so that a name would be found for all cases.

Mark’s PR changes this behavior such that Send-To sources are always polled regardless of whether a CID name is found or not. @jfinstrom has pointed out that this changes long standing default behavior, and as such there should be a toggle to allow an Admin to choose which behavior they prefer. While this is correct, I have a hard time thinking of a use case where anyone would prefer the old way of doing things, I feel like this is more of a bug fix than a feature add.

Anyone with thoughts on this?

[comtech]

Not sure of the level of effort required for a toggle, but I cant think of a reason why I would use the old way vs the new.

[jfinstrom (James Finstrom)]

I did make a comment on the PR. I wish bitbucket was better about telling me there was discussion there.

To summarize my thoughts here from years of doing these fixes.

In a perfect world you just fix things and call it a day. In open source every line of code you touch brings up accusations of eating babies etc. The longer a bug lives, the more likely it is to become a way of life for people. They get attached, bond, raise families with that bug. You come along and tell them it is a defect and you have basically made their whole life a lie.

Seriously though if it has been broken for multiple releases we have to assume:

1. Nobody uses it and it should simply be removed.
2. Everyone who uses it expects it to work as is.

In case 1 you deprecate then remove and hope the universe doesn’t explode. In case 2 you keep your sticky fingers off of it and call it a feature. This brings us to development where we just want to fix things. We aren’t bold enough to do 1 or 2 because it is a good idea if it just worked correctly.

You might ask why something would be written if it didn’t actually serve a purpose. My answer is look at my github

In the case of making it work we want to take the same care as #1. Changing established functionality is the same as code deprecation. You assume someone, somewhere has made a life and family with that code and you make sure you are not destroying those things by fixing the code.

[jfinstrom (James Finstrom)]

The effort:

set['value'] = false;
$set['defaultval'] =& $set['value'];
$set['readonly'] = 0;
$set['hidden'] = 0;
$set['level'] = 0;
$set['module'] = 'superfecta';
$set['category'] = 'CID Superfecta';
$set['emptyok'] = 1;
$set['name'] = 'Send empty cid';
$set['description'] = 'Send empty cid data  (legacy functionality)';
$set['type'] = CONF_TYPE_BOOL;
$this->FreePBX->Config->define_conf_setting('SUPERFECTAEMPTYCID',$set,true);

if($this->FreePBX->Config->get("SUPERFECTAEMPTYCID")){
  // do old thing
}