DisposableHero

I kindly suggest you to read the docs, main difference between a widget and a module is explained there. Basically, above example is pure js. So it does not need to be a module, does not need to be a widget either. So in theory, it can be used as html/js in a blade OR can be converted to a (ultra) simple widget. Good luck

I liked option 3. Given the fact that v7 offers multi airline out of the box and its flexibility for setup and usage, it may be a nice choice for future. Schedules, fleet, operations etc all can be multi airline and if needed relaxed or easily can be restrictive upon airline needs. (costly, needs vmsAcars license) Option 2 looks like the easiest solution, if the operator has enough database knowledge and have backups for worst cases. (free but risky, can be easy if you have enough knowledge) Option 1 is the easiest

Filter property may be useful; https://www.w3schools.com/cssref/css3_pr_filter.asp

No need to be puzzled, either that pilot did a free flight and selected SVAG (8) as the airline or edited his pirep before sending it and changed the airline. It can not happen on its own, it is simply not possible.

Do you allow free flights ? If this is the case then a pilot can choose and use SVAG (as the airline) and 956 as his/her flight number. Which will give you the exact image above, but you will not be able to find that flight in your database. So, better check your database; a. Flights table for any flights assigned to that "group" airline and fix them (assign them to proper subsidiaries) b. Pireps table for any reports sent with that "group" airline's id As I am using a multiple airline setup for a long time, never had an issue with "airline id <> airline" matching and that part of the core is maybe untouched for years, so all can assume that it will not be touched/changed with upcoming update too. Hereby I am kindly informing you that your "issue" can not be solved by just updating your phpvms as it is not a problem related with core and/or addons. Safe flights

I solved that problem by adding a light colored glow outside the dark colored text and by using transparent background. With that, same logo is being used on both light and dark themes without any visual differences and loss of branding. Light theme: That light anti alliased glow is not noticable at all. Dark theme: That glow makes the text (or logo) visible and separable from the black background and looks fine. Just for your info

Got your point Colors are nice, grey and yellow tones look good Yeah, there was a discussion or talks about adding "time" as a core expense unit, selectable per flight but what happened to that idea I really forgot. As I am using my own module for income and expense, I stopped using core features. But if I can find that old topic (or maybe the GitHub issue) we can start talking about it again. It may come in handy, we can define expenses per flight by time then. Thanks for bringing that old/forgotten topic back, after Laravel9 maybe we can focus on and have it implemented in core (while looking at the custom expense bug). Best wishes

Why do you need a text change for it ? It is the "block time cost" of an aircraft (comes from subfleet of course) and it is the correct phrase to use there. In theory, it is the cost of using that aircraft for xx minutes, defined hourly as like in real life but calculated per minute. So in short, it is correctly designed, being calculated and used. Please do not mix up things with other things and try to find a way around to have what you wish to see, by requesting changes to working features That custom expense not working is still an open bug, probably will be fixed soon (after Laravel9 switch). If you need to stick with current dev for some reason, then you can design a really simple module to pass your custom expenses, that works, only "custom expenses without a module" solution/example is failing And just wondering, why do you need to create "a cost of crew salary" ? Pilots do get their pays, it is calculated. If you are trying to simulate cabin crew salaries, then doing it with an expense is much more logical. No need to brake working block time cost for that Best wishes

Are you using phpvms v7 ? If not, this may not be the correct place to get support... To me that change looks like a css/styling issue or a browser rendering problem in general.

If you mean making it changeable/selectable by the user, like a language selection dropdown at frontend, no it is not possible. If you want to change the language from English to French, then it is done in env.php file. APP_LOCALE=xx setting is for that.

You can check the docs about how to build addons covering your special needs, https://docs.phpvms.net/developers/addons Needs at least basic knowledge about php itself (specially php7.4 and up) and laravel framework (version 8 and up) to begin with (some database engine knowledge may be needed depending on your needs of course), rest is up to your imagination and coding skills as the webmaster. Good luck and God speed.

For pilots to use their salaries/earnings there are two public ways currently, provided by Disposable Basic "Jumpseat Travel" and "Aircraft Transfer" and some penalties applied by Disposable Special. It is possible to develop many more things to spend that virtual money, like type ratings payments done by pilots, free flights tied to some payment by pilot, maybe a virtual shop for them to buy items etc. All these ideas needs to be developed by the operator or some freelancer for the operator only or a third party developer/company as modules. As far as I know core v7 will not provide this kind of features as it is focused on providing a stable backend which you can build things on and use.

It all depends on how your settings are done, how often you do database cleanup (how many months back you keep records of old/non relevant data), how much data (flights/pireps) you have etc. etc. So there will be no "typical" or "normal" database size which will fit everyone or every install. For example, my live site's database is around 150 mb, I do not keep non relevant data more than 3 months old (like simbrief packs, acars position reports), performing weekly database cleanup and optimization too. So my database backups and export/import operations do not cause any timeouts or errors. But this may not be your case or this can not be called as normal/typical size.

It will work At least you will not see that relationship error anymore with an updated phpVMS v7

Looks like the main links you added to your menu/navbar is ok but you are missing a crucial component, your phpVMS v7 is out of date (or not updated properly, missing some critical improvements). That relationship error is a clear sign this, in other words you are using a Disposable addon which requires a more recent (preferably latest dev build of) phpVMS v7. Latest version of the module has this info in its readme, Compatible with any latest development (dev) build of phpVMS v7 released after 10.FEB.22 Anyway, that "Aircraft <> Airline" relationship was added to phpVMS v7 around the first week of November, 02.NOV.21 to be precise. So if you want to stick with an older v7 release you should also find a compatible release of my addons with that version and stick with it too. I kindly suggest you to update your core phpVMS v7 or do not use my addons as I can not support older versions Best wishes and good luck on the update process.

Looks like you are missing a cache cleanup or the module is not installed properly or you have problems with dynamic links. Either way, first try cleaning your application cache (admin > maintenance > application) as it is a part of the module installation, then for us to better understand what is going on, provide details about that "500 | Server Error". Enable debugging to see it live as it happens or check you laravel logs when you see that generic page. https://docs.phpvms.net/help Good luck

Well, if you just hover your mouse over the Disposable link (which should be placed at the footer and should not be removed according to license), you can see the theme version and date it gets released. Anyway, technically what you did not liked is the `$pirep->ident` generated by phpvms v7. If you do not want to use that then you need to find all instances of it being used in the blade files and change it to maybe `$pirep->flight_number` depending on your needs. Pirep/Flight Ident => Airline Code + Flight Number + "/C." + Route Code + "/L." + Route Leg => UK + 156 + /C. + FEB + /L. + 8 => UK156/C.FEB/L.8 So be advised, if you want to use only the flight number, then you need to add the airline code before it too 'cause it will look like `156` only with `$pirep->flight_number` I can not give you exact locations or file names, it is used in many different blades including module pages.

Glad it worked and saved you from more trouble Safe flights

Well, to be honest I do not think you can get the full expenses of a pirep at that stage with the event. So forget charging the full debit total to the pilot. Nothing is impossible and you can do that of course but not with that expense listener and not at the moment it works. What you can do is, as I wrote earlier, charging the pilot with the half of his earnings per flight hours (nice admin). This means that they will earn less and this will make them fly scheduled routes more than free flights. Technically you have the pirep model and all its relationships there in the event, no need to look other places or events to find things. It is all object/model oriented. So when you have the $event->pirep in your hands this means that you have the flight (if it is a scheduled one), you have the user and all of its relationships like rank , type ratings, subfleets he/she can fly etc. You need to study what those models provide to you, what are their relationships and what to they provide too for better understanding what is available and when, also this will give you a better picture to think about. $event->pirep->flight_time , $event->pirep->distance , $event->pirep->user->rank->acars_base_pay_rate , $event->pirep->flight->flight_number are some examples for you. To be practical, you can simply assign them to shorter names variables like $pirep = $event->pirep; $user = $pirep->user; in the beginning of your code, so from that moment on you can use $pirep->flight_time instead of $event->pirep->flight_time or $user->rank directly when needed etc. As far as I remember, the pay rate is calculated like this round($pirep->flight_time * ( $user->rank->acars_base_pay_rate / 60), 2) , you can divide that result by 2 and charge the half of his/her earnings back as a punishment of freely flying https://github.com/nabeelio/phpvms/tree/dev/app/Models You can check the models and their relationships from the link above (source code of v7) Hope this helps, good luck

$amount = 300; // or calculate something with the flight time like round($event->pirep->flight_time * 5) this will result 300 for 60 mins if (filled($event->pirep->flight_id)) { // There is a flight id present, so this is a scheduled flight. // return empty expense array, do nothing more. return $expenses; } Or worse You can just take the pilot pay back for free flights By calculating exactly the same amount a pilot earns with flying that flight, or can be a nice admin, taking half of it back etc. So in theory, that amount should be calculated and must be value.

As this is a free flight, there will be no $pirep->flight_id , you can use that as your condition. For the $amount, you need to find some fixed value (maybe you can calculate something with the flight time or the distance flown as per your needs) at least please explain your wish a little bit more... What does "pirep expenses/debit" mean ? Rest looks ok though

My pleasure as always

He had some covid problems and development was paused, thankfully he is recovering back and keeping up with the changes done to core while he was away. Most probably generator will be back online when he feels fully ok and updated

So for example, that live map widget should use "col-lg" instead of "col" alone. "col" is the default, smallest available one, "col-lg" however is auto optimized for large screens when used with other columns etc. Same applies to cards etc as far as I remember.

This is a theming issue in its core. I did not worked on "responsive" logic much, but it can be easily handled with Bootstrap's responsive auto sizing tools. The latest version of DH Theme had some pages partly fixed for small displays and phones, but it still needs work I do personally not use a small screen and developing things for them is just killing my eyes to be honest Check the latest version and see how I implemented the dashboard and login/register form etc, it may give some clues. Best wishes