17447c6903
* Block Aircraft with SimBrief Changes aim to have the ability to block an aircraft's usage if it is used to generate a SimBrief OFP. Unused/Expired briefings will be deleted by cron like before but will now be checked by HourlyCron, so admins can define more precise restrictions for them (and the blockage period of their aircraft) Owner of the SimBrief OFP will be able to start a flight with acars using that particular aircraft, but pilots will get an Aircraft Not Available error (similar to Aircraft State check) To prevent SimBrief OFP packs being marked as expired/unused, during pirep prefile, pirep_id will be saved to SimBrief model along with flight_id. And when a flight is finished (pirep file), flight_id will be removed from SimBrief model as before. Only pirep_id will remain and aircraft will be available for another OFP generation. * Update PirepController In case a pirep is being saved/submitted with manual entry (but the va is using simbrief effectively) same logic should be applied during save/submit button selection. Save will act like a pirep prefile , Submit will be pirep file. * Manual Pirep Checks Manual pireps, prefiled from a generated simbrief should be checked too. Also pirep.show blade's submit button should provide the same simbrief checks. * Update PirepService.php * Change settings and move sb cron to hourly * StyleFix (SimBriefService) * Another StyleFix (SimBriefService) * Update SimBriefController Removed null check of pirep_id for aircraft list generation to prevent live flights' aircraft being listed for another ofp generation. ( Active acars flights will have both flight_id and pirep_id at simbrief table) * Update PirepService.php Co-authored-by: Nabeel S <nabeelio@users.noreply.github.com> |
||
|---|---|---|
| .github | ||
| app | ||
| bootstrap | ||
| config | ||
| modules | ||
| public | ||
| resources | ||
| storage | ||
| tests | ||
| .dockerignore | ||
| .editorconfig | ||
| .eslintignore | ||
| .eslintrc | ||
| .gitignore | ||
| .htaccess | ||
| .php_cs | ||
| .styleci.yml | ||
| artisan | ||
| CHANGELOG.md | ||
| composer.json | ||
| composer.lock | ||
| docker-compose.local.yml | ||
| docker-compose.yml | ||
| Dockerfile | ||
| intellij_style.xml | ||
| LICENSE | ||
| Makefile | ||
| package-lock.json | ||
| package.json | ||
| phpstan.neon | ||
| phpunit.xml | ||
| Procfile | ||
| README.md | ||
| swagger.yml | ||
| webpack.mix.js | ||
phpVMS 7
The next phpvms version built on the laravel framework. work in progress. The latest documentation, with installation instructions is available on the phpVMS documentation page.
Installation
A full distribution, with all of the composer dependencies, is available at this GitHub Releases link.
Requirements
- PHP 7.3+, extensions:
- cURL
- JSON
- mbstring
- openssl
- pdo
- tokenizer
- Database:
- MySQL 5.5+ (or MySQL variant, including MariaDB and Percona)
View more details on requirements
Installer
- Upload to your server
- Visit the site, and follow the link to the installer
Development Environment with Docker
A full development environment can be brought up using Docker, without having to install composer/npm locally
make docker-test
# **OR** with docker-compose directly
docker-compose -f docker-compose.yml -f docker-compose.local.yml up
Then go to http://localhost. If you're using dnsmasq, the app container is listening on phpvms.test, or you can add to your /etc/hosts file:
127.0.0.1 phpvms.test
The docker-compose.local.yml overrides the app section in docker-compose.yml. The standard docker-compose.yml can be used if you want to deploy from the image, or as a template for your own Dockerized deployments.
Building JS/CSS assets
Yarn is required, run:
make build-assets
This will build all of the assets according to the webpack file.