A discussion functional additions to the Helpers Blazor Server app._

Previously blogged here is a Blazor Server app for an athletic sporting club. The blog post discuss Blazor Server and Entity Framework features. The app is an Azure App Service with an Azure SQL Database with Entity Framework the API used to interact with the database. The app was originally developed to allow members and associates to volunteer for on-competition-day duties that he club is assigned by the sporting association. The database requires volunteers to register with a mobile number as their password which is used a day or so before the competition day, to remind them and to confirm their availability for the task. Twilio is the host for that functionality. The site allows volunteers to view the dates for which we are tasked, as well as the tasks’ details including the time period for each. Having logged in they need only click on a task and they are then enrolled for that task.

The database was extended to parse a CSV document of club members as downloadable from the sporting association. The membership table then adds new members and updates the registration status and meta-information of existing members. Members can belong to a number of groups, The CSV parsing includes determining automatic groups that they belong to such as Athlete, Recreational Runner, Coach, Official. Age groupings are also determined based upon data of birth. There are also manually added group memberships such as Committee, Life Member and Associate Member which are not part of the meta-information from the sporting association. There is also a search functionality that searches for an athlete based upon their BIB number; the number that they wear front and back during competition.

The app was extended to make use of the members data by sending emails to all members and to groups. If the email is sent to and age group, then the team leader for that group also gets the message in the CC field. Whilst sending emails to all is generally handled by a more formal mail out handler, it is useful to be able to send emails to specific subgroups of the club.

Privacy is a key issue front and centre with the app. The public can only see a list of the dates and meets that we are required to perform duties at. A logged in registered helper can also see the tasks on the day and nominate for them. Note, having nominated, they can’t undo that. That requires an email to the club secretary who has admin capabilities. The BIB look up is limited to the designated person who publishes competition photos on the club web site and social media.

The app has recently been extended to include the handling of club records. A record can be a time for track and road events, a distance or height for field events or points for multievents. Grading points are also part of Masters records. In the past this has been a hand-me-down from committee to committee as a spreadsheet. Spreadsheets can be error prone, and the information flow needs to be handled by one person at a time. A database would open up the information flow whilst enforcing checks and balances of it. The app now facilitates the display in a filterable manner, of the current records. You can filter on such things as event type or name, age grouping etc. Club members can make record claims. An athlete can make a claim against an existing record which is then verified by a designated person and then approved (if verified) by the committee. Once approved it becomes the current record for that event-age group and the previous record is tagged as historical, which is also viewable in the records table. There is a designated person to do the verification and to action the approvals; the Records person. Note that to help enforce the committee’s involvement, the final approval can only be after 6 days from verification, even though it is done by the verifier. It was decided as design principle, the committee, except for the app admins, can’t directly action any of this. The app manager and the club secretary are the only Admins for the app. No record data can deleted, even rejected claims, except if required by the app manager.

A claim consists of athlete’s details including current age group, the performance, the data, the meet type, and location as well as supporting evidence. The evidence can simply be a link to the meet results with the event number and meet type round number, if relevant. There is also an ability to submit, as text, any other supporting information. A future iteration may allow for upload of a PDF or image, but not at this stage. A Wind Gauge speed needs to be included in a claim for shorter track events as well as the horizontal jumps. If submitted by someone other than the claimant, the submitting person is included.

Their are checks and balances such as, an athlete can only make a claim on their own behalf for events for which their age group matches or is less than the record age group. Also, a Masters athlete can claim an Open record. Coaches, Team Leaders and the Records person can also submit claims on behalf of any club athlete. This could be tightened to athletes under their charge for coaches but this is more trouble than it is worth. A claim can either be Current, Pending, Verified, Historical or Rejected. When a claim is submitted it is pending. The Records person verifies the authenticity of a claim. If invalid, a claim is rejected. The committee takes a monthly report of all verified claims and approves them and indicates thus to the Records person who is responsible for actioning the approval. The committee can also reject a claim. When the Records person views a pending claim’s details, the page also displays details of the current record including the name, performance and year. No automation of the comparison of the 2 performances is envisaged at this stage.

A major feature of records was to present the current records in a colourful formatted manner in a printable manner such that they could be printed large (say A1) sheets. This need has come about because the ultra-large pegboard style records board is past its use-by date … can’t get replacement lettering. This has been implemented as Save-As-PDF functionality and includes shaded background.

In making these latest changes, the app was upgraded form .NET 5 to .NET 6. .NET 6 is LTS; Long Term Support. Telerik Blazor components are used and these were upgraded to V3.4.0 for a version 2. .Net 5 reached end of life this May and is out of support as per here.


<  Prev:   Jekyll
 This Category Links 
Category:Blazor Index:Blazor
  Next: > Blazor Helpers Server App
<  Prev:   Blazor Helpers App Members