Roles and Securable Locations Overview

Modified on Tue, Feb 27 at 12:31 PM

Introduction to Securable Locations & Genesis Security

Primary security in Genesis revolves around finely controlling access to screens and the functions on those screens.

This control centers upon Roles and Users.  Roles grant specific access and specific permissions to users.

Access is provided by a set of “Securable Locations”. Most Securable Locations control access to a screen or screens within Genesis.

A small number of the Securable Locations provide a mechanism for controlling access to and permissions for a resource on a given screen (e.g. ability to see and potentially update student’s Social Security Number).

Access is provided by Securable Locations:  giving a user a Role that contains a specific Securable Location (e.g. studentdata.studentlists) gives the user the ability to see the screens controlled by that Securable Location:  it does not confer any permission to do anything on the now visible screens.

Permissions are granted separately.

TABLE OF CONTENT

What is a Securable Location?

A "Securable Location" is – essentially – shorthand for a set of screens and/or functions.  

Each Securable Location identifies one or more screens or a function on a single screen. For example, you would add studentdata.studentlist.studentsearch to grant access to the Student Data>Student List>Student Search tab.

Securable Locations do not overlap: each controls a unique set of screens or functions.

Each is essentially a name for part of the overall Genesis Student Information System product.

You can view/add Roles via Setup>Security>Roles.

You can see the securable locations within those roles if you click to MODIFY the role (seen below).



Locations vs. Permissions & Timeframes – and Reports

Securable Locations control access: the ability to view a screen.

What a user can actually see and do on a screen is controlled by permissions and timeframes:

  • Permissions specify what a user is allowed to do.
  • Timeframes specify the School Years the user is allowed to act upon.

Timeframes

The Genesis database contains data for all the School Years for which your school district has used the Genesis product.  Additionally, it may contain data for previous school years if that data was converted and uploaded into Genesis at the time Genesis was installed.

Data is never removed from the database:  it always contains all the data for all the School Years during which it has been run in your district.

This allows users to choose the School Year of the data they wish to view:  it is always possible to view prior year data, permissions permitting.

Data within the Genesis database is organized by School Year. The School Years are grouped into four possible timeframes:

  1. Current Year – Access for the current School Year. This is the most important timeframe and the one most users have access to and update permissions for.
  2. Last Year – Access and permissions for the previous School Year. This timeframe is important for administrators and guidance counselors who must occasionally access and possibly even update data from the previous school year, including the printing of reports and student transcripts from that year.
  3. Historic – Access and permissions for all years earlier than the last School Year for which you have Genesis data. This is important for administrators who may need to look back over multiple years of data.
  4. Next Year – Access and permissions related to the next School Year. This is the least important and is restricted to the setting up of administrative information for the coming year.

A Securable Location specifies permissions for each of the four timeframes:  a Role may grant access to one timeframe and completely restrict access to another.

Typically, very few individuals are granted access to prior year data.

Permissions

Permissions constitute the “What the user can do” on a given screen in a given timeframe.  In each timeframe there are 5 possible permissions that can be granted or denied:

  • Add permission – “A” – User can ‘add’ on the screen.
  • Delete permission – “D” – User can ‘delete’ on the screen.
  • Change permission “C” – User can update the data on the screen.
  • Inquiry – “I” – User can see the data on the screen though perhaps in a read-only fashion.
  • Print – “P” – User can use the Genesis facilities to print the screen.

Not every permission is available for every Securable Location.  

Only those that make sense for a given Securable Location will be available for that location.

On some Securable Locations one or more of the permissions may have special meanings.

Securable Location Anatomy

Format of Securable Locations

Every Securable Location consists of two or specifiers which, as a whole, identify a set of screens and functions within Genesis.

The format is:  module.category[.screens/functions]

  • Module” identifies the Genesis ‘module’ or ‘top tab’ the Securable Location controls.  E.g. “studentdata” for Student Data.
  • Category” identifies the second level (or ‘Category’) tab controlled by the Securable Location
  • screens/functions” optional elements identify third/fourth+ level tabs or functions controlled by the Securable Location

Some sample Securable Locations:

Securable Locations vs. Screens

Not every individual screen is controlled by a Securable Location:

·         Most Securable Locations control multiple screens:  a Category tab and all screens below it.

·         Some screens are not controlled by any Securable Location:  they are available only to System Administrators.  When there is no Securable Location controlling a screen, that screen is very secure:  access to it cannot be granted to any non-System Administrator.

·         There are special “Access” locations that must be added to Roles  simply to gain access to other locations. 

Was this article helpful?

That’s Great!

Thank you for your feedback

Sorry! We couldn't be helpful

Thank you for your feedback

Let us know how can we improve this article!

Select at least one of the reasons
CAPTCHA verification is required.

Feedback sent

We appreciate your effort and will try to fix the article