1) Added new field to the organiser model called charge_tax. Added the migration for this.
2) Renamed tax fields columns in the database to be the same as the other organiser fields for consistency.
3) Added charge_tax option to the various organiser create and edit pages.
4) Have re-enabled some tests and used the @group passing label so we can start running tests for the various parts of the applicaiton.
1) Added additional edge case for installer that I missed.
2) Reference class via use statement and correct namespacing.
3) If we are using the docker environment set certain defaults from environment variables instead of hardcoding.
1) If a user tested the database connection previously it worked no matter what they entered into the form. Fixed logic to return error message based on whether database exists or not.
2) If a user enters valid text data into the database connection fields but the database doesn't exist fail gracefully.
1. If Attendize is already installed don't throw an Unauthorized 403 error but instead ask user to create default account or login if default account already created.
2. Added defaults to the install process for database connection so if user gets to install page and hits install will use default database values.
3. Added basic validation on database connection details. If the details where empty previously allowed user to submit form.
1. Added csrf token to form on install. This was causing Laravel to throw an error as no CSRF token was present.
2. During the install process default to MySQL as the default database.
1. Bumped the PHP version in the PHP Docker file so that composer can run successfully as some packages are depdendent on PHP 7.0.8 or higher
2. Added a composer image that is dependent on the same version of the PHP container so that there are no issues running composer.
In the docker compose file we are using Postgres as the DB but the
default adapter is set to use MySQL so trying to create the default app
out the box does not work.
1) Added localization components to the package. They allow usage of localized routes, like http://attendize.site/en/login
2) Added English and Polish localization files. They are ugly, repetitive, but mostly true to the original and relevant. It required rewriting several phrases, and certainly required editing most of the views and controllers.
3) Edited routes to accomodate point 1
4) Rewritten several rules regarding dates. In most cases using English notation (with English names for months) is bad in all other languages. I used environment wide date format that is used.
5) Updated installer. Haven't tested it yet, but should work. Rewrites .env.example file instead of creating it from scratch (by concatenating strings).
There are some minor changes that were simple fixes or other funky requirements from my employer that kinda make sense:
1) QR code reader wasn't working in firefox, fixed it. Works in chrome/firefox on mobile on https sites.
2) Added subscript text in some instances: below ticket registration, below ticket. It is kinda dumb, but in most cases is necessary to receive less complaints from clients.
3) Fixed geocoding api by adding api key in env file. At some point in 2016-2017 it was required by google to use API key from developer console and this requirement wasn't challenged in the code.
4) Ticket has been displaying either flyer or site logo on the side. Now displays both (which may affect 1d barcode - it might need some fixin). Regarding the same issue - description of an event contained the flyer image on the side, it was removed, cause it didn't fit in here.
5) Ticket style was updated, because of the above and because it didn't fit longer character strings. Now it's slightly uglier, but works in all cases.
and other.
There are also some inconveniences, like:
1) Unfinished translations. It was impossible for me to create translations based on strings located inside of a database, which I ignored (I think it's only at one place - surveys).
2) Ugly translation files. At some point I thought it is going to be easier to locate when I try translating vased by file name. Later I divided it by topics, and then I segmented it even more. It might require some serious clean-up.
3) Redundancy. In some cases there are several definitions for the same phrase in my localization files. I used it mostly to protect myself from different contexts for the phrase usage in different languages.
4) File division. There are several files that are placed in dedicated language directory (in /view/, like /view/pl/ or /view/en/). These files don't use language phrases, but they are translated as a whole. Mostly because using language phrases would make those view files unreadable.
5) Localzation helper marks some phrases as obsolete (in file "basic"), because they are used in app/Helpers folder (where this plugin doesn't reach)