Slate Standard Athletics Portal

Slate provides a standard Athletics Portal that can be imported using Briefcase and edited in an institution's database. This portal is configured to leverage the Slate standard Sport table, and coaches are set up as users with specific roles in Slate.

Important!

A good understanding of the data tables is recommended before altering any custom SQL.

Slate Standard Sport Table

Slate provides a standard [sport] table in the underlying database (custom sport-scoped fields can also be created as needed). This table consists of the following columns:

  •  id
  • record
  • sport
  • position
  • rating
  • notes
  • external_id
  • created
  • updated
  • priority
  • rank

Sport information can be viewed, added, and edited on the Profile > Sports tab of the person record.

The values for the standard fields "sport" and "rating" are dependent on specific prompt key values.

  • Sports - The list of sports offered should be added as prompts using the key of "sport."
  • Ratings - The rating options should be added as prompts using the key of "sport_rating."
    Custom Roles

prompts.png

Custom Roles

Coaches should be added as users in Slate with specific roles related to their sport(s). The naming convention for these roles is as follows:

Coach - <<Exact Name of Sport Prompt Value>>

roles.png

For example, if the sport prompt was "Basketball", the role would be "Coach - Basketball". Any basketball coaches would then be assigned this role in Slate.

  Tip

If sport prompts are broken out by sex, you'll want the sport to be "Basketball Men" and the role to be "Coach - Basketball Men" to allow for easy matching of athletes to coaches in the portal. Some of the filters in use in this standard portal look for the content in the role name following "Coach - "; these existing filters are most easily implemented without changes by using sport prompts and roles that do not contain additional dashes.

Editing the Queries

Once the Athletics portal has been imported via Briefcase, the exports can be customized to return the data points to display in the portal. There are two main queries that may be edited:

List of Athletics Query

The first is the list of the athletes. More filters can be added to limit the results to specific records if desired, such as only recruited athletes or only those in a particular application period.

The standard Athletics portal comes with a custom SQL snippet filter to restrict the list of athletes whose sport/s match the logged-in user's role/s. This filter should not be removed, as it ensures that coaches see only their athletes.

sql.png

This query also has a "node", which allows you to leverage Liquid looping in the view to display one row per result. The node can be assigned by opening "Edit Parameters" within the query.

Query Node

Athlete Details Query

The second query is the athlete details query, which is used to display information in a pop-up when the user clicks on a specific athlete.

We recommend adding the majority of athlete details in this query to display within the pop-up. This helps save space on the main view and prevents the page from looking too cluttered. This query leverages a parameter, which accepts the sport ID of the athlete that was clicked on.

Parameter

<param id="sport_id" type="uniqueidentifier" />


The only filter that should be associated with this query is the custom SQL snippet. This filter indicates that the information returned by the query should be associated with only the record the user clicked, identified by the sport ID passed into the query parameter.

  • Status - Active
  • Name - Clicked on Student
  • Source - Custom SQL
  • SQL - (sp.[id] = @sport_id)
Editing the Views

You may also edit the views to display any additional data points added to the queries, or remove items, or reformat in a different visual layout, etc.

The standard Athletics Portal Default view includes a static content block for user information, which displays a list of coach roles associated with the logged in user.

p1.png

The Default view also contains a table of athletes. This table uses data from the list of athletes query.

p2.png

The portal also includes a view for the athlete details pop-up, which displays information when a specific athletic is clicked. 

p3.png

This pop-up also allows coaches to save a rating value for the athlete. 

Important!

Be careful when editing the pop-up that the information in the source code is not altered. It adds in the necessary values and code for the rating to save back on the student record.

p4.png

p5.png

Portal Methods

The various methods in the Athletics portal include GET methods, which call data from queries and display them in views, as well as a POST method, which saves the rating value back to the record.

Some methods have actions, while others do not. The methods without actions are called immediately upon accessing the portal:

Method Action Type Status
Get Athletics List   GET Active
Get Coach Role(s)   GET Active
Get Logged-in User Identity Info   GET Active

That is to say, the queries that pull the user information, the list of the user's coach roles, and the list of athletes in the user's sports are all run when the user logs into the portal.

Other methods run when the "detail" cmd is called:

Method Action Type Status
Get Athletics Details (Popup) detail GET Active
Get Rating Options (Popup) detail GET Active

When clicking on a specific athlete, the "detail" cmd is called, which runs the queries that pull additional details about the athlete and the rating options for the dropdown in the pop-up. These methods are associated with the pop-up view, so the pop-up renders on the page, and the data from the queries populates in that view.

The "saveDetails" cmd is a POST method:

Method Action Type Status
Save Rating (Popup) saveDetails POST Active

This method runs the custom SQL query that updates the rating for the athlete.

  Best Practices

The POST method uses a custom SQL query which should be edited with care. Please submit a Service Desk Request should you need any assistance when making changes to this method.

Testing

To test the Athletics portal, you will need to have an example user with at least one coach role. You will also need to create several records that have sports associated with your example user's coach roles.

To view the portal, go to the portal URL. If your account has a coach role, you will be able to access the portal. If you do not have a coach role, you will need to impersonate your example coach user and then go to the portal URL.

Once in the portal, ensure that you see the expected athletes in the list. Click on different athletes to view the pop-up, and make sure to also test saving the rating. You can always return to the Portal Editor to make any changes to the queries and views as desired.

If you need assistance with these items, please detail what steps you have taken and what you would like to or expect to see, but currently do not. As always, include screenshots and links to examples users and athletes. 

Additional Customizations

The standard Athletics portal can be updated in various ways, depending on your institution's process.

Update Custom SQL Snippets to Account for Custom Permissions

For example, if your institution uses custom permissions rather than roles, the custom SQL snippets in the portal queries can be updated. The standard snippet looks at the [role.user] table, but this may be adjusted to use the [user.right] table. It also looks for the prefix of "Coach - " in the role name, but this may also be updated to be "Athletic Director - " or other verbiage.

Student's Sport Matches Coach's Sport Custom SQL filter:

(spp.[value] in
(
select dbo.getToken(' - ', r.[name], 2) as [name]
from [role.user] ru
inner join [role] r on (r.[id] = ru.[role])
where (ru.[user] = @identity)
and (r.[name] like 'Coach - %')
)
)

  Tip

If making changes to the roles/permissions, remember to edit the query that pulls the coach roles as well.

Track Recruit Data Using Custom Fields

Some institutions track athletic recruit data using custom person- or application-scoped fields. The SQL snippets can also be modified to reference these fields instead.

The portal can also be edited to allow for updating of custom sport scoped fields.

The SQL post query associated with the Save Rating (Popup) method updates the [sport] table:

update [sport]
set [rating] = @rating
where ([id] = @sportid)
and ([record] = @prospectid)


In order to update a custom sport scoped field instead, the POST query would need to reference the [field] table, and would also require a "delete" as well as an "insert".

Add Missing Checklist Items to Athlete Details Popup

Rather than adding joins and exports to an existing athlete details query, use a Checklists-based query to pull one row per checklist item in order to ultimately list all of the desired checklists belonging to each applicant.

To do this, take the following steps:

  1. Create the Checklists query in your portal and filter as necessary. The query must contain:
      • A filter (expand the example below for details) to only show checklist items associated with the sport being clicked,

        Example_Athletics_Portal_Checklist_Filter.png

      • A node like "checklist"
      • A parameter to pass in the sport_id from the clicked row
      • Any exports you would like to display in the pop-up
  2. Associate the query with the appropriate pop-method so that its data can be displayed in the portal.
  3. Adjust the pop-up view table to loop through the checklist items from the new query. The HTML could look something like the following example:

    <tr>
    <th style="text-align: left;">Checklist</th>
    <td>
    <table class="plain">
    <colgroup>
    <col style="width: 20px;" /><col />
    </colgroup>
    <tbody>{% for result in checklist %}
    <tr>
    <td>{% if {{result.status}} == 'Received' %}<img alt="" height="16" src="/shared/ok.png" title="Status: Received" width="16" />{% elseif {{result.status}} == 'Waived' %}<img alt="" height="16" src="/shared/waived.png" title="Status: Waived" width="16" />{% else %}<img alt="" height="16" src="/shared/cancel.png" title="Status: Awaiting" width="16" />{% endif %}</td>
    <td>{{result.subject}} {% if {{result.optional}} == '1' %} (optional) {% endif %}</td>
    </tr>

    This example includes Liquid markup for displaying certain images when a checklist item has or has not been satisfied, and displaying "(optional)" for checklist items that are not required. A for loop dynamically lists the rows related to the checklist items present in the checklists query. 

Was this article helpful?
1 out of 1 found this helpful