Minor updates and code changes occur every day. Only significant or noteworthy updates are shown here. Updates shown with a gold background are (or were at the time) only available to Advanced HOPS members.

You are NOT currently subscribed to HOPS compliance system updates. More info

You are NOT currently subscribed to HOPS retail system updates. More info

Search: Clear


Time DateSystem Updates
Update 1364
31 December 2025

Ticket Email QR Scanning Updates

The process around scanning QR codes to confirm validity has been overhauled.

Note this only applies to scanning QR codes on emails by ticket inspectors, not scanning on the POS in order to recall an order / print tickets, which is unchanged.

Part of the objective here is to increase ticket security, as requested by several clients, while maintaining the ability to process queues quickly.


PERMISSIONS

Ticket QR codes can now only be scanned by logged-in users. Previously anyone could scan a code. While there was no personal information shown, limiting the scan to logged-in users both reduces the ability for 'everyone' to see what the resultant page looks like, and also means all scans are 'official' scans, rather than the customer scanning it speculatively.


LAYOUT

The layout has been changed to group together tickets for the same event. Eg instead of showing:

Sunday Lunch - Adult - 12:30 - 15:00 - Thursday 1 January 2026 - DATE OK
Sunday Lunch - Child x2 - 12:30 - 15:00 - Thursday 1 January 2026 - DATE OK
Sunday Lunch - Senior - 12:30 - 15:00 - Thursday 1 January 2026 - DATE OK
Sunday Lunch - Dog - 12:30 - 15:00 - Thursday 1 January 2026 - DATE OK

It now shows:

Sunday Lunch - 12:30 - 15:00 - Thursday 1 January 2026 - DATE OK
- Adult
- Child x2
- Senior
- Dog

We hope this is more intuitive.

Both the quantity of tickets and the number of seats is shown.

For 'travel' it is not as easy to group tickets together (as there are so many fine details), but effort has been made to make it as quickly-readable as possible.


ITEMS SHOWN

Only event tickets and travels tickets are now shown. Seat reservations are not shown as lines in their own right - the seat reservation information is shown in the row for the ticket it applies to. Other items such as vouchers and stock products are not shown.


TICKET DELIVERY

The page also now highlights if the ticket is not an e-ticket. It is envisaged that the QR scanning method of checking tickets is only used for e-tickets. It works for all methods of ticket fulfilment, but non e-tickets are highlighted.


TICKET FRAUD - PREVIOUS SCANS

All previous scans are now shown. If the order or items have ANY previous scans [by logged-in users*] an orange banner will be shown at the top of the page. The ticket inspector can then examine the tables of previous scans to determine the situation. This does require some interpretation, eg as a user may have purchased tickets for two events in the same order: The order will have been scanned when they attended the first event, then on attending the second event the ticket inspector will see 'Already Scanned', but examination of the detail will reveal that this is a legitimate case.

* - Although it is now only possible for a logged-in user to scan tickets, many previous scans were conducted by non-logged-in users. Only scans by logged-in staff are considered here.


ORDER SCANS VS ITEM SCANS

Note that it is possible to scan an ORDER confirmation email, or an ITEM details email ("Additional" email). 'Additional' emails can be configured in the ticket system settings for items that require a great deal of additional information, eg a Driver Experience might have many paragraphs of 'things to bring' and 'what to expect' etc.

The scan page has tables for scans on the ORDER and scans on each ITEM, to give the maximum detail to the inspector if they are trying to resolve the circumstances and determine whether a customer is legitimate. It isn't possible to predict whether the customer will present their ORDER qr code or their ITEM qr code, so both must be considered.


INTERPRETATION

It is up to individual clients to determine a policy on interpretation of the scanning data. Eg if you know that you only ever scan customers once at your one-and-only entry gate to an event then you can be pretty sure that if someone has already been scanned then they are trying to get two people in on the same email. Whereas if you have several entry points, or are scanning tickets several times during the day then it might be entirely reasonable that a person is scanned more than once, so the examiner will interpret the data shown to determine whether the pattern is reasonable.


TICKET FRAUD - FURTHER CONSIDERATIONS

In addition to the risk of two visitors trying to gain access on the strength of the same email, an additional risk has been identified: It would be easy for a user to save a copy of the HOPS 'ticket valid' page onto their own site, and present the ticket inspector with a QR code to that site instead of the real QR code which leads to HOPS. To mitigate this, two additional items have been added to the page:

- The name of the logged-in ticket inspector is shown at the top of the scanning page. A ticket inspector should expect to see their own name there every time. A visitor trying to defraud the company would need to know the name of the inspector in order to fake this.

- A 'Code Word' has been added. This can be set in Ticket System Settings in HOPS. If set, it is shown after the name of the ticket inspector of the scanning page. A ticket inspector should expect to see same code word every time. Eg the code word of today could be 'CHOCOLATE', and then this would show on every scan. A visitor trying to defraud the company would need to find out the code word in order to fake this. The code word can be set/changed whenever required. This system is used by some 'main line' bus and tram operators.

While neither of these are 100% fool-proof, they both introduce a further level of difficulty for a person attempting to illegitimately use a QR code. Like all systems, it can almost never be 100%, it just needs to be more hassle than it's worth for a bad actor.


FUTURE

It is our plan to further develop this facility to include a camera view on the page, to avoid the need to return to the native camera app after each customer.

It is also intended to allow the user to state their role, so that further interpretation of the data can be made. Eg a Guard could state their role as '1030 Padd-Oxford' or '1D22' (to use a main line example) when they are operating that train, and then '1300 Oxford-Padd' on the way back. This would enable easy distinction between a passenger being scanned on their outward and return journey. When being scanned on the way back, the system would show 'Already Scanned', but the guard would see the first scan was on the 1030 Padd-Oxford, so the passenger is obviously now on their return journey. Whereas if they look at the first scan and find it's on the 0700 Oxford-Padd then it is possible the passenger is trying to make a second journey on the same ticket.

Another example could be events where the visitor is allowed access to several attractions - eg 'Your day ticket includes a one brake van ride, one trip on the miniature railway, and one session on the ice rink'. If this were to be strictly access controlled, the ticket inspectors at each location could state their role as 'BV', 'Mini Railway', and 'Ice Rink' - it would then be possible to control the 'Already Scanned' alert to 'Already Scanned at this part of the event'.

We will be interested to hear feedback from users on if/how useful this would be.
Update 1164
25 April 2025

POSTCODE / ADDRESS LOOKUP

A new postcode / address lookup feature in HOPS it now available to all railways for a trial period until the end of June 2025.

This is available when adding or editing a user's address (themselves or a manager entering details of another user), emergency contacts, and for public customers making online ticket sales, shares sales, membership sales, and shop sales.

This aims to:
* speed up the entry of user data
* reduce the effort required by customers complete their checkout for purchases
* reduce the propensity for errors / missing address components

Addresses can still be added 'manually' for occasions where the required address isn't in the Royal Mail list.

There is a cost to HOPS in providing this service, so the lookup feature will be an optional add-on for railways for which a small fee will be charged (£5 per month). The railways with which we have developed this feature believe that the time, staff effort, and wasted postage, saved will deliver an overall saving to their railways.

The system is currently switched on for all railways for a trial period (without charge) until the end of June. Railways may OPT IN at any time to subscribe to the service to continue after then if they wish. (If no action is taken, the feature will disappear at the end of the trial, and no fee charged). Please do this by raising a support ticket in the Helpdesk, or emailing in.

We hope this new feature is useful - Thank you to everyone who has worked with us to develop it.
Update 1064
5 August 2024

A warning has been added in the 'Add New User' page if a user with the same firstname and surname already exists.

This will hopefully reduce the volume of duplicated users being added.
Update 964
4 February 2023

I have added a new link to the Asset Management system to assist in displaying in kiosk mode, eg on large screens in depots. This builds on Update 904, as requested by several railways.

I have added a 'Kiosk View' link to the top right hand corner of the Asset list pages, which hides the tabs and other links at the top of the page, to make it more useful for display.

To exit from kiosk view, there is a link at the very bottom of the page.

To collapse the side menu and allow the whole width of the screen to be used by the display press Ctrl + F10 and the HOPS left hand menu will collapse. The menu can still be reached via the hamburger icon, or pressing either Ctrl + F10 again or F5 (refresh) will bring the menu back permanently. Note that focus must be in New HOPS for this to work, so if it doesn't work first time, click into the green bar at the top to give focus to New HOPS and then it will work.

Pressing F11, in most browsers, will collapse the browser's links and bars at the top of the page. Pressing F11 again will bring them back.

If you wish to increase the size of the text, to better fit the information on your display screen, I recommend using the browser zoon facility to zoom in (or out).

It is recommended to use a browser extension to handle automatic periodic refreshing, eg once a minute, such as the one linked below for Chrome:

https://chrome.google.com/webstore/detail/easy-auto-refresh/aabcgdmkeabbnleenpncegpcngjpnjkc?hl=en

It is better for the browser to handle the auto-refreshing than the web page, as if it was left to the web page code to refresh the page, and it refreshed at a time when the internet connection had momentarily been lost, the page would not be loaded and hence it wouldn't know to try to refresh itself again a minute later, whereas a browser will keep trying each subsequent minute.
Update 950
7 January 2023

ROSTER DIAGRAMS

References to 'Diagrams' on rosters have been replaced with the term 'Roster Lines' without change to functionality.

[Note this was originally advertised as 'Custom Rows'. Thanks for all your feedback on a suitable name!]

This releases the term 'Diagram' to be used with the new train crew diagrams tools.

Train crew diagrams will not be inextricably linked to roster lines, as it will often be required to show more than one diagram in each line on the roster - eg Traincrew diagrams 'Driver 1' and 'Fireman 1' will probably want to both be shown in the 'Train 1' roster line. It might also be a requirement to show 'Driver 1' and 'Driver 2' in the same 'Train 1' roster line, if that is for example the early and late turn for the same train, etc.

In most cases this will only affect roster clerks. In many other places around the system the label Diagram has been retained, as it will contain the current info (roster line) AND the /new/ diagram info in the future.

Eg "Diagram: DS640 (Train 1)" where "DS604" is the diagram and "Train 1" is the roster line.
Update 870
15 June 2022

The availability matrix in HOPS has a new 'white stripe' added when a person is fully utilised.

A person is considered fully utilised when they have been allocated the number of turns they asked for or, if they indicated 'unlimited', when they have been allocated a turn on every day they are available.

This makes it easy to visually distinguish a 'Yes' that is able to be used (green) from a 'Yes' that can't be used as the person is already working their max amount (green with white stripe).

If all Ys are green/white, the max utilisation has been reached and therefore the best efficiency from the roster availability.

Link to examples: https://www.facebook.com/HeritageOps/photos/a.274448152666082/5101371096640406/
Update 864
9 May 2022

Volunteer Attendance Mileage Cost Prediction:

Report 42 in System > Reports & Export lists everyone's post code.

As this is about cost, it will be skewed by the number of turns each person has done. I have added a post code field to reports 72 and 73, so that you can get a figure for the year if you wanted, and I have also added three new reports which show the number of turns in the period 2019-2022 done by each post code:

79 counts it up for complete post codes (eg (TQ9 5DB)
80 counts it up by the first part of the post code (eg TQ9)
81 counts it up by the letters only (eg TQ)

You can copy and paste or export as CSV it from there into Excel for analysis.
Update 764
19 May 2021

A new field has been added to the recording of cyclic maintenance tasks to record who conducted the task.

(The user saving the record is also recorded separately.)
Update 664
13 June 2020

TIME REGISTER

The anomalies tab now has a set of tick boxes on it. Where two records for the same person on the same day are ticked, and 'Execute' pressed at the bottom, they will be joined together.

It can't cope with four records for the same person on the same day so, if someone signs on and off twice in the same day, that will need to be done as two operations.

It can cope with many records for the same person if they are on different days.

If it can't cope with anything it'll just ignore it, it won't damage it.

A record highlighted in blue is one that believes it can be joined to a previous record.
Update 649
16 March 2020

New reports now added (62 and 64) for users over 65 and users over 60, by department.
Update 647
15 March 2020


This has been sent to the admin contact for each organisation.
Please pass it on to those who might need it at your organisation.


Hello everyone,

Here are some HOPS tools that might be useful in the Coronavirus situation regarding the potential isolation of over-70 year olds that might help you to plan ahead. https://www.bbc.co.uk/news/uk-51895873


Overview:

We all know that the average age of a heritage volunteer is high, so isolation of over-70s is likely to have an impact on us. For context, there are 6871 current users in HOPS with DOBs recorded. Of these, 2119 are over 70. That's 30%. Generally there is a higher proportion of operational staff with DOBs recorded than non-operational, so that 30% is unfortunately probably weighted more towards the operational staff, rather than an even spread across the board.


Rosters:

Users who are over 70 by the date of the turn are now shown on construct rosters with a "[70+]" next to them. This enables you to easily see who might not be available to cover their turn. Only users with a DOB in HOPS can be monitored.

This is turned on by default, if you don't want it to show you can switch if off in System > XYZ Settings.

Tip: You can use your browser's Ctrl+F (or Cmd+F on a Mac) and search for all the instances of "70+" on the page.


Reports:


Report 34 shows users over 70 years of age:

https://www.heritage-ops.org.uk/report.php?r=34

Permission 131 required.


Report 22 shows users with no DOB in HOPS:

https://www.heritage-ops.org.uk/report.php?r=22

Permission 131 required.


Report 60 is a new report that has been added that allows you to see the numbers of staff over 70 in each department. This has links for each department row which show the names of staff affected. Only staff with DOBs in HOPS can be shown, of course.

https://www.heritage-ops.org.uk/report.php?r=60

Permission 131 required (it isn't possible to split this by department, so if you want your department managers to take action then you'll need to copy/print the list for each dept and send manually) .


If there are any queries please let me know.

Many thanks

Danny Scroggins
Update 648
15 March 2020

The Unassign Turns Report is now separated out by year.
Update 646
20 February 2020

CASES

A delete option has been added. Permission 380 required (red dagger).
Update 645
20 February 2020

MESSAGING

You'll be pleased to know that archived departments no longer show up in the messaging system.
Update 644
14 January 2020

USER DETAILS

An option has been added to have a prompt appear at the top of the Home page when a user's details have not been checked for 14 months.

This only shows to users with permission to update their details (186).

To use this facility it has to be switched on for the organisation in System > XYZ Details. It is switched OFF by default, so you'll need to switch it on to see it.

The banner that shows up contains a link for the user to confirm/update their details (links to the normal user details editing page, with additional explanatory text at the top https://www.heritage-ops.org.uk/user_details_edit.php?p=confirm )

The 14 months is counted since the last time the 'Update 'last updated'' box was ticked on the user's details page by either the user themselves or an admin.

For organisations that use the HOPS ID Card system, you will almost never see this message, as your users update their details every year as part of the ID Card renewal process.
Update 643
14 January 2020

USER DETAILS

Two new fields have been added to user's emergency contact data:

- This person also works for the organisation.
- This person's address is the same as mine.

The latter removes the need for the user to enter the same address twice when their emergency contact is their partner who lives at the same address. It also reduces the burden (and probability of forgetting) to update the EC address when the couple move house.
Update 642
1 January 2020

FUNCTION LOGS

It is now possible to select, in the configuration options for a Function Log, whether it defaults to the 'Today's Items' tab or the 'All Open Items' tab.

The different options suit difference circumstances of use.

Permission 139 (red dagger) is required to edit this setting.
Update 641
1 January 2020

FUNCTION LOGS

New permission 371 is now required to close a Function Log item.

The permission has been allocated to all users and groups who already had the permission that was previously required, so no action = no change.

This is designed for scenarios where all logs are reviewed before they are closed.
Update 640
1 January 2020

FUNCTION LOGS

It is now possible to delete a Function Log Item.

Permission 373 is required.
Update 564
13 March 2019

A second-revised menu has now been implemented.

Hopefully this is better.

(We will perfect the background colours in the near future!)

Apologies for the issues this morning relating to usability with iphones/tablets/etc.
Update 464
20 January 2018

The 'year' tabs at the top of the turn count matrix now run back as many years as data is available.
Update 437
22 February 2017

Some basic functions to assist in the management of employees working shifts have been implemented.

New permissions:
265 - to assign users to an 'employee pool'
264 - to view the shifts of employees (per pool)
266 - to edit the shifts of employee (per pool)

A 'pool' is a group of employees. Permissions are granted per pool, and are almost the equivalent of departments except that a user can only belong to one pool.

I've used SHIFT as the word to describe a person working, to keep TURN for a thing on a roster. (A person could be working a shift AND a turn, ie and employee driving a train.)

A new menu "Employees" is available with a menu option "Employee Shifts" which is a matrix of shifts. Clicking edit under a name will allow you to edit the whole month for that single person, or clicking edit on a date will allow you to edit all the people on that single date.
Update 364
10 September 2016

A yellow bar has been added on 'today' on the Group Bookings diary.

Also the name of the last person to edit a group booking now appears next to the time.
Update 264
1 March 2014

Some new fields have been added to the group bookings system to show things like whether catering has been agreed, whether a numbers return has been received, etc.

The new fields are intended for tracking the progress of a group booking from first contact to receipt of final payment.

The fields all have a yes/no/maybe value, an option to add text remarks, and a date field.

Any custom fields can be added to individual railways if required.

This is part of subscription module 6.
Update 164
2 October 2012

On 29 September I adjusted the 'Volunteer for Vacant Turns' function only available if the users is competent for the turn. I didn't consider departments where competence isn't relevant, so I have now made it so that in order to volunteer for a turn the user EITHER has to have the in-date competence OR the department allows rostering of non-competent staff (an option in the department rostering structure).
Update 64
24 February 2011

Spacing of telephone numbers has now been standardised throughout the system, including the area prefix and code, ie, Ashford area (01233) 123 456.