This removes most of the legacy upstream config madness by not using
weird config files spread all over the place.
This isn't the solution to other config reading fragility issues, but
it does move the whole config back to the central airtime.conf file.
The user object was triggering the creation of a user context that tried to grab something from the session. The later code never tried to use this due to the checkPerm flag.
I'm assuming the user model used to have a sane constructor w/o side effects in the times where this code had it's heyday.
This makes LibreTime check its version against github releases and lets the user know when to update. It uses the red exclamation point when there is a patch release or if LibreTime is more than one major release ahead. The orange icon is used when LibreTime is on a git install, a single major update is available, or a pre-release version is installed. The green update icon gets used to signify that a new minor release is available. Finally the green checkmark will be used when you are on a stable release.
The previous constraint of NOT NULL made it impossible to create a placeholder entry for later downloading. This uses a 0 default instead of the constraint and downloading as well as the green checkbox work again.
This fixes CORS to work properly with most 2.5 api endpoints while keeping the JSONP format available.
* [x] return JSONP or JSON with proper CORS headers from API
* [x] Field in Genereal Preferences Form to configure CORS enabled URLs
See #17 for what triggered this refactor. I beleive this should make integrating the APIs on the client side trivial without mandating the use of JSONP.
This is to get the help section to look better and point to somewhere users can find us. It also takes care of /dashboard/about and maybe more.
Some of the links I'm adding are 404 as we have yet to write them, I'd rather link something we have under our control rather than legacy transifex or others.
Cache handling has been disabled on saas-dev and 2.5.x at least for a while. This gets completely rid of it.
You should do caching on the byte-code level in PHP using the tool best fitting your needs and depending on the exact PHP version you are running this on.
Proper cache hygiene ist a routine part of maintenance and may need seperate addressing depending on the needs of your station.
This should give us more information in the case of an error and is the framework idiomatic way to handle a RESTful file upload.
I'm hoping this helps debug https://github.com/LibreTime/libretime/issues/3
This is the results of sed -i -e 's|/etc/airtime-saas/|/etc/airtime/|' `grep -irl 'airtime-saas' airtime_mvc/ python_apps/` :P
It might need more testing, the airtime-saas part never really made sense, zf1 has environments for that, ie you would create a saas env based on production for instance.
I beleive legacy upstream was using this to share configuration between customers (ie. analyser runs only once and writes to a shared S3 bucket). I assume they mount the airtime-saas folder onto individual customers instances with a global config. Like I said, I don't feel that this makes sense since all it does is make hacking at the configs in airtime-saas a bit easier. A serious SaaS operation should be using something like puppet or ansible to achieve this.
Solution: Make billing configurable through LIBRETIME_ENABLE_BILLING and deactivate it
This should catch all the changes needed to deactive billing in LibreTime.
* [x] only call billing when it is enabled
* [x] let super admins edit their info
* [x] dont link to billing if it is disabled
Robb Ebright
Lucas Bickel
Robb
Lucas Bickel