Why does /etc/amportal.conf not have a reference for a cdr database or at least an option to references another file for the cdr reports ( ie /etc/asterisk/cdr_mysql.conf)
I have been dealing with this for years now and it is driving me crazy. ( eg http://www.freepbx.org/forum/freepbx/users/latest-upgrade-unlinked-reports-db) Every time a /admin/cdr/lib/defines.php is overwritten through a module upgrade (today it was framework 184.108.40.206 (current: 220.127.116.11) asteriskinfo 18.104.22.168 (current: 22.214.171.124)) I have to hard code it back in again, even if I did it the proper way and put a reference to the /etc/amportal.conf file for the config information, /admin/cdr/lib/defines.php would be overwritten and I would still be editing the same file again anyway.
I do not use asteriskcdrdb. I do not want to use asteriskcdrdb.
I would imagine that there are MANY small systems running freepbx where the cdr db, freepbx and asterisk are all on the same machine. So why not have an option that simply uses the same database?
It just makes sense to make it appeal to the largest segment. Please forgive me if there are more enterprise users which separate machines for everything.
Sorry to be a pest.
it’s usually considered proper to spend 5 minutes reviewing the CHANGES file in the next release before going on a rampage about some thing that you want. And then IF it is not there, and a reasonable search does not come up with an existing feature request, there’s something called a tracker which has a ticket type called a feature request which is how new features are requested, remembered and eventually prioritized.
Or, you can do like the other person who had a related request did and submit a patch along with the feature request to increase it’s probability of getting in the next release.
Not really a rampage when I end the post with “sorry for being a pest”
You are correct, that changelog would have apprised me of the situation before it happened, but it would still happen. However it was not really a “situation” I think a siutation would be a hard drive failure or something of the sort
I would rather not use the tracker because I have a habbit of running older versions (not currently) and then someone says "hey that’s so last century and has been fixed ages ago. Where have you been? or “What are you crazy? It needs to be this way for XYZ reason.” Thus the place for that discussion is in the forum.
I am sorry i did not see a related request. I did search and I found my previous post form a year ago so I thought I would link that in.
Thank you for your hard work
you are welcome to use the forum all you want, it’s there to discuss and express what ever you feel. However, if you want to have any effect on what goes on vs. blowing off steam, you can step up and be a bit more diligent about using the tools and processes that would have that effect.
I can assure you that some of the most active and helpful members on this project have versions older than yours running in production. However, they understand that they will have to upgrade to get the features they want at some point, and thus keep abreast of what is going on with the most current versions as well as provide inputs and contributions.