If you are editing ES mappings and you use the DataTable filtering option,
the table won't contain all the mappings you have in the DB.
If the form is submitted they will be removed and data will be lost!
Test plan:
Edit ES mappings, filter and submit the form.
Confirm that the table are redrawn before the form submission which
prevent data loss
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch prefixes all of the fields in OpacHiddenItems with
"me." before searching.
Unit tests added to cover this case1
To test:
1 - Create a public list
2 - Set OpacHiddenItems to:
biblionumber: [1]
3 - Attempt to view list in OPAC
4 - Booom
5 - Aply patch
6 - Reload list
7 - Success
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
defining package as 'recommended', as suggested
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Speaks for itself.
Test plan:
Check if the acqui z3950 search works as expected.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Remove the line without the scalar.
Test plan:
Just look at the code.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Test plan:
1 - Find a record in the staff catalog
2 - Edit the record
3 - In the 520 notes field, add an ASCII escape character (27 decimal, 1b hex)
On ubuntu Ctrl+Shift+u, then 1b, enter
4 - Save the record
5 - Set syspref ShowComponentRecords to 'both...'
6 - On record details: New->New child record
7 - Save the record
8 - Attempt to view the parent record in the staff client and opac
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch replaces the use of jquery.cookie.js in the OPAC with the
newer js-cookie plugin. The patch adds the latest version of the
js-cookie library and removes the old jquery.cookie plugin.
To test, apply the patch and go to the advanced search page in the OPAC.
- Perform a search using a number of different limits and settings, e.g.
keyword, item type, and sort-by.
- On the search results page you should see at the top of the results
list a link to "Return to the last advanced search."
- The link should take you back to the advanced search page with all the
same settings filled into the form.
- A search with the "More options" view enabled in the advanced search
form should result in a link which returns to the "More options" view.
- Searching via the "quick search" form at the top of the page should
clear the cookies which were set in order to remember the advanced
search. See
https://developer.mozilla.org/en-US/docs/Tools/Storage_Inspector for
information on viewing your browser's stored cookies.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch updates the holds table to always insert a hidden input when a hold is 'found'
and covers the case where the hold is 'found' but doesn't match known statuses
To test:
1 - Place two holds on a record for two different patrons, with different pickup locations
2 - Check in one item at expected branch to set waiting
3 - Then either:
- Use batch modification or item editor to change the holding branch for the item
- Sign in to a different branch and manually transfer the item back to it's home location
4 - View the holds for the record
5 - Note the 'Pickup library' column is blank for that hold
6 - Change pickup location for other hold and press 'Update holds'
7 - Note the waiting hold is still blank, and now second hold has no pickup location
8 - Check the DB and note the first hold has had the pickup location changed
8 - Apply patch
9 - Delete holds and repeat 1-4
10 - Note the waiting hold now displays:
Hold expected at {Branch}, please checkin to verify status
11 - Change location for second hold and update holds
12 - COnfirm location chanegd correctly and first hold unaffected
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
If a maximum number of checkouts allowed is defined in circulation
rules, C4::Circulation::TooMany will loop over all patron's checkouts.
When a patron has several hundreds of checkouts, it can really slow down
the checkout process by several seconds (or even tens of seconds)
This patch does two things:
- Always prefetch item data so that `$c->item` does not execute an
additional SQL query at every iteration of the loop. Item data is
always needed at the first line of the loop, so there is really no
downside for doing this.
- Build the `@types` array only once, out of the checkouts loop. Since
it does not depend at all on patron's checkouts data, it does not make
sense to build it inside the loop.
Test plan:
1. Before applying the patch, create a patron with a lot of checkouts.
I tested with 1000 checkouts, but the slowness should be noticeable
with less.
2. Make sure you have a circulation rule (one that apply to your patron
and the item(s) you will check out for testing) with a maximum number
of checkouts allowed
3. Check out an item for the patron with a lot of checkouts. Measure the
time it takes.
4. Apply the patch
5. Check out another item (or check in and then check out the same item
used in step 3). Measure the time it takes and compare it to step 3.
It should be faster now.
6. Run `prove t/db_dependent/Circulation/TooMany.t`
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch updates teh search customisations in ill-list-table to
properly fetch the existing flatpickr instances for date searches.
To test:
1. Have at least one ILL request on the ILL requests page
2. Open the broser inspector
3. Choose a date on the left hand form
=> FAIL: Errors in the console, search doesn't work
4. Apply this patch
5. Reload
6. Repeat 2-3
=> SUCCESS: No more errors, filtering works!
7. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Bug 30098 fixed patron search behavior when a later page has only 1 result, but broke the redirect when there is only a single result from search.
To test:
1 - Perform a patron search that returns 41 results, on koha-testing-docker, 'a' works
2 - Go to second page of results, works
3 - On third page you remain in results and are not redirected
4 - Perform a patron search that return only 1 result, name or cardnumber
5 - You get redirected to this patron page
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch fixes the particular use case of the orders route, which has
a slightly modified version of the objects.search helped, embeded in the
controller itself. This controller gets adjusted to the fact q will now
be an array.
Because of the latter, we end up requiring more code duplication
regarding the query fix, so I moved it to an internal sub that gets
reused.
To test:
1. Apply the previous patches
2. Run:
$ kshell
k$ prove t/db_dependent/api/v1/*
=> FAIL: It t/db_dependent/api/v1/acquisitions_orders.t fails!
3. Apply this patch
4. Repeat 2
=> SUCCESS: Tests pass!
5. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch changes the q_param definition so the defined query parameter
is repeatable. This way JSON::Validator will always generate an arrayref
for it and won't skip occurences.
The objects.search helper is updated to always consider the 'q'
parameter as an array, as expected.
To test:
1. Apply the regression tests patch
2. Run:
$ kshell
k$ prove t/db_dependent/api/v1/query.t
=> FAIL: Tests fail!
3. Apply this patch
4. Repeat 2
=> SUCCESS: Tests pass!
5. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
When you install a plugin that requires a newer Koha version, it reports
this:
<<
Warning: This report was written for a newer version of Koha. Run at your own risk.
>>
It is wrong in a couple ways:
- It is not a report.
- It feels like it dates back to when plugins were only run i.e.
pre-hooks, etc.
This patch proposes a change to reflect this.
To test:
1. Verify the string changes make sense to you
2. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch adds the ACCTDETAILS notice trigger to the opac self
registration process. Allowing new users, with varification enabled,
to receive the ACCTDETAILS notice immediately after their account is
varified.
Test plan
1) Enable AutoEmailOpacUser system preference
2) Ensure the ACCTDETAILS notice is configured
3) Ensure `PatronSelfRegistrationVerifyByEmail` is enabled
4) Register a new user via the opac self registration process using an
email address you have access to
5) Verify the user by following the link in the verification email you
should have received.
6) The new user should have been created and you should be able to see
the account details notice in their associated notices
7) Confirm that the email address used above has received the notice.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch adds the ACCTDETAILS notice trigger to the opac self
registration process. Allowing new users, without varification enabled,
to receive the ACCTDETAILS notice immediately after their account is
created.
Test plan
1) Enable AutoEmailOpacUser system preference
2) Ensure the ACCTDETAILS notice is configured
3) Ensure `PatronSelfRegistrationVerifyByEmail` is disabled
4) Register a new user via the opac self registration process using an
email address you have access to
5) The new user should have been created and you should be able to see
the account details notice in their associated notices
6) Confirm that the email address used above has received the notice.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
The original notice was sent using SendAlerts, which triggers
immediately on submission and doesn't wait for the cron task.
This patch restores that immediacy and also fixes a bug in the imports
on the original patch.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
We actually have a Koha::Patron method to do all the work of finding the
right patron primary email address for notices.. we can use that here
instead of doing it long hand.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
The ACCTDETAILS notice apparently bypasses message_queue; notices are sent directly to the linux mail queue.
Test Plan:
1) Apply this patch
2) Create a new patron with an email address
3) Note the patron's ACCTDETAILS notice shows in the patron's messages
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
We removed a bit too much from the skeliton here ;)
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
We should not give libraries the ability to compromise patron accounts,
it is considered a huge security issue and nobody in network security
would never recommend allowing passwords to be transmitted in clear text
over email.
It should simply not be possible to send a patron's password in plain text
via email. As such, we should remove this ability from Koha.
Test Plan:
1) Apply this patch
2) Create a patron to generate the ACCTDETAILS email
3) Note you can no longer transmit the patron's password in the email
Signed-off-by: Amit Gupta <amitddng135@gmail.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
1 - Define default messaging preferences for a patron category
2 - Go into an existing account and change the patron category to the
one set in step 1.
3 - Confirm that the messaging prefs have been reset to that of the
default patron category
4 - Apply patch
5 - Repeat Step 2, this time you should see a warning asking if you want
to set messaging prefs to the category default
6 - Press OK and save. Confirm that the messaging prefs are now set to
the default for that category
7 - Try it again with an existing account and press Cancel this time.
Notice that there should be no change to the patron messaging prefs.
8 - Try making a new patron and switching the category, you should see
no warning and the message prefs should be proberly set to the
defaults of any category you choose.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch makes select2 available for ILL backend developers to use on
their templates.
To test:
1. Have a configured backed and an ILL request
2. Open the inspector and load any action on the backend (intranet)
=> FAIL: no select2 asset is transfered from Koha to the browser
3. Apply this patch
4. Reload
=> SUCCESS: There's select2
5. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This makes two changes:
1 - We no longer call get_items_that_can_fill if there are no holds
2 - The subroutine will return an empty Koha::Items object if there are no holds passed
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
To reproduce (paycollect.pl):
1) Prepare or use some existing patron with outstanding fines, go to
the accounting section and open page where you make payment towards all
fines.
2) The error message should have appeared in your log file about
"File not found : default/js/locale_data.js".
3) Apply the patch.
4) Open the edit page again, ensure that the new error massage like
that didn't appear.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
To reproduce (memberentry.pl):
1) Head over to the patron details page, press edit button to open the
memberentry.pl page.
2) The error message should have appeared in your log file about
"File not found : default/js/locale_data.js".
3) Apply the patch.
4) Open the edit page again, ensure that the new error massage like
that didn't appear.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch updates the OPAC suggestions form to update the variable
used to pre-select the logged-in user's library.
To test, apply the patch and make sure the "suggestion" preference is
set to "Allow."
- Log in to the OPAC and click "your purchase suggestions" in the
sidebar menu on your summary page.
- Click "New purchase suggestion."
- The selected library should match the logged-in user's home library.
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch adds a check for both mandatory and important fields when
validating bibliographic records during cataloguing.
To test:
1. Go to Admin -> Biblio frameworks. View the MARC structure of your
default framework.
2. Search for tag 082. Edit the subfields for this tag.
3. Check the 'important' checkbox for subfield a and Save.
4. Go to add or edit a new biblio record under Cataloguing.
5. Ensure the 082$a field is empty and hit Save.
6. Notice the confirmation pop-up is an unreadable display of HTML.
7. Click Cancel on the pop-up box.
8. Apply the patch and refresh the editor page.
9. Ensure the 082$a field is empty and hit Save.
10. Notice the confirmation pop-up is more helpful this time. Click
Cancel on the pop-up box.
11. Notice the 082$a field is displayed at the top of the page as an
important field that is missing information. Use the 'go to field'
link and confirm this works as expected.
12. Leave 082$a empty and hit Save.
13. This time click OK on the confirmation pop-up. Confirm you are able
to save your record as normal.
Sponsored-by: Education Services Australia SCIS
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
to test...
1/ set git repo
$ git reset --hard v21.11.03
2/ run test
$ prove ./t
OK
3/ apply patch
4/ run test again, observe FAIL
$ prove ./t/00-check-atomic-updates.pl
./t/00-check-atomic-updates.pl .. 1/?
# Failed test 'check for unhandled atomic updates: bug_29596.pl'
# at ./t/00-check-atomic-updates.pl line 34.
# 'bug_29596.pl'
# matches '(?^u:.*pl$)'
# Looks like you failed 1 test of 3.
./t/00-check-atomic-updates.pl .. Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/3 subtests
JD Amended patch: fix copyright year
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Jonathan Druart
David Cook
Nick Clemens
Mason James
Marcel de Rooy
Owen Leonard
Julian Maurice
Martin Renvoize
Fridolin Somers
Tomas Cohen Arazi
Katrin Fischer
Kyle Hall
Lucas Gass
Andrew Nugged
Petro Vashchuk
Adam Styles