1. Updated the refund journeys so that they use the payment Gateway Factory.
2. Improved request data going in and out of the session.
3. Show error message when Stripe SCA journey fails.
4. Update migration.
1. Removed dependencies on $gateway->id in the database which made the codebase fairly brittle in places. Use the name field of payment_gatway instead.
2. Refactored Event Checkout so that in theory it should be a lot easier to add other Omnipay gateways.
3. Removed Paypal Express as a gateway supported by default.
4. Payment Gateways are now configurable by specifying an admin and checkout template in the database directly.
5. Broke each payment option out into its own template instead of trying to handle all payment gateways in one form with funny if conditions.
6. Account settings for Payment Gateways is now dynamic based on what is in the database.
7. Added migration and updated Seeder to make sure the payment_gateways is correct on in stall and when upgrading.
# Summary
Added the ability to specify hidden ticket access codes on an event. This would allow for special types of tickets to be created on an event and have an unlock code link to one or many hidden tickets.
## Value
The value this adds is to allow event organisers to play with marketing to aid in ticket sales etc.
## Changes
**Admin**
- Added migrations to allow for the access codes table on events and the pivot for many to many codes to tickets
- Added the ability to create an access code in the event customisation
- Added the ability to view access codes on a hidden ticket
- Added the ability to attach one or multiple access code(s) onto the hidden ticket
**Public event page**
- Shows a box to enter your access code if the event has hidden tickets
- Added the validation messages for empty codes
- Added the check to fetch the hidden tickets if the code was entered correctly
1) Removed references to Bitpay and Migs.
2) Use the payment Gateway configured for the account. Fixes#551.
3) Allows switching of default payment gateway between Strip and Paypal.
1) added better validation across all user input both for the operator of Attendize and end user.
2) Remove html from translations so {{ }} can be used instead of {!! !!} as its more secure.
> Verifiers SHALL require subscriber-chosen memorized secrets to be at least 8 characters in length. Verifiers SHOULD permit subscriber-chosen memorized secrets at least 64 characters in length. All printing ASCII [RFC 20] characters as well as the space character SHOULD be acceptable in memorized secrets. Unicode [ISO/ISC 10646] characters SHOULD be accepted as well. To make allowances for likely mistyping, verifiers MAY replace multiple consecutive space characters with a single space character prior to verification, provided that the result is at least 8 characters in length. Truncation of the secret SHALL NOT be performed. For purposes of the above length requirements, each Unicode code point SHALL be counted as a single character.
https://pages.nist.gov/800-63-3/sp800-63b.html#-5112-memorized-secret-verifiers
1. After we have save the order to the database forget the session.
2. Firing events to create and send tickets should only be done after the we have saved the order to the database
Going forward Attendize will only support Stripe and Paypal as defaults. In future we will add instructions on customising Attendize with your own payment gateway.
1) Changed method call from lists to pluck.
2) Use set put instead of session set.
3) Removed references to artisan optimize command.
4) Added additionl check to base controller if auth user not set redirect to login.
5) Flush the session on logout.
6) Updated Event and Route service providers to work with Laravel 5.6.
7) Added new default logging config file.
8) Bump PHP versions from 7.0.30 to 7.1.20.
9) Added missing translations.
10) Fixed some issues with the templates.
1) Added Javascript partial so display and hide of the Charge Tax functionality can be shared.
2) Moved @yield head for the the master without menus layout to the correct place. Using jQuery functionality @head anywhere wouldn't work as the library was included afterwards.
3) Moved the question for organisers about Tax and the labels for tax fields to the language file.
1) When Taxed is charged display it on the various views where tax should be displayed. Orders Listing Page, Orders Summary page.
2) Use the Order service to display correct values in emails and views.
1) Omnipay doesn't accept decimals with more than a precision of 2.
2) Once order is created organiser_booking_fee is the correct value to use else use total_booking_fee
3) Controller makes use of OrderService instead of Order Model
1) Surfaced more logic from from views into service.
2) If charge_tax is set in database tax is charged.
3) Made the name of the Order service OrderService so its not confused with the Order Eloquent Model.
4) Move order totalling logic in to Service and call service where necessary.
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) 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)
- Tax name, a text field (so the user can call it VAT, TVA, sales tax, etc. as required by their country)
- Tax value, a float number
Also added tax value on these pages.
- The ticket sales page, to show how much tax will be added on top of a ticket
- The total basket value that is sent through to Stripe
- The receipt email that gets sent to the user
Edit an order [firstname, lastname and Email]
Resend an entrire order (especially useful if someone entered a wrong email which has then beed edited)
Show ticket reference in the order refund modal, so you can quickly refund/cancel multiple tickets in an order
Added 'receipt_email' to the Stripe charge creation request so customers get a payment receipt as well as their tickets. Also removed a blank line.
I would still like to see the $order->order_reference in the description, but I'm not sure if $order has that property at this point: line 330 of EventCheckoutController.php.
In EventTicketsController::postUpdateTicketsOrder, sort_order is generated in ascending order, however, when displaying tickets, tickets is sorted in descending order. 964e456 tries to solve the issue but it is the other way around.
merdan
ilmedova
Jeremy Quinton
Etienne Marais
James Dahlen
Kerrin Hardy
Sam Bell
Maxime
Etienne Marais
Delena Malan
Sebastian Schmidt
Jeremy Quinton
dsnap1993
Scott Bowler
Jacek Marianski
githubertus
EC2 Default User
Sachin
Dave Earley
JapSeyz
jharris70
Gary Guo
Jacob Catayoc
James Mowatt
James Mowatt
Yoann Lecuyer
bretto36