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 /Schedule/set-time-scale/format/json was being hit every time a new calendar page was displayed. The isn't good for performance reasons and also makes race conditions like #210 much more likely.
With this change the preference is only updated on the server when the GUI state changes because the user clicked on one of the "Day", "Week", or "Month" buttons.
This does not fix the locking issue completely, but it should help because the cc_prefs time-scale row in the database will get locked much less often. After applying this I wasn't able to reproduce #210 any more on an install with an extensive schedule.
Makes the first tab remoeable and the tracks page be full width after removing the last tab. You can press the "Dashboard" link to open it back up again.
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.
This makes subform validation work for everything again. I also had to slightly unhack the corresponding js. It's still not very nice in that it still reloads even though ajax would have been enough but I could figure out why the mast source field was not getting the proper values (You can reproduce this by commenting the window.location.reload() in the js).
I'm replacing them all with empty images under the assumption that we will want to re-add a new logo. This is just to ensure that we can release LibreTime without infringing upon the sourcefabric trademark for now.
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.
Also fixes them elsewhere, apart from having switched to a vendorized version, I also used one that is already namespaced.
The easy way out here is to use it in the namespaced fashion, it is only used in a few places and I know the library well enough to be certain that nothing much changed apart from the namespacing.