KID Access
Introduction
This section explains the access control in the KID. It will help you to understand what data each type of user can access, what data they cannot access and why.
Access to data in the KID is controlled by a number of restrictions. First, users are grouped into User Types, then there can be restrictions on the States and Areas that a User can access and the database fields that can be read or written. The final access allowed is a combination of these restrictions.
Access Restrictions on the Search Page
| Entity | Guests can see: | Updaters can see: | Administrators can see: |
|---|---|---|---|
| caves: | |||
| simple, standard, | all | ⇐ same | same |
| long/deep, top10, | all | ⇐ same | same |
| advanced | only caves in their allowed states (S1) and only fields that are allowed (S2) |
||
| cave map references | all | ⇐ same | same |
| other map references | all | ⇐ same | same |
| areas | all | ⇐ same | same |
| article references | all | ⇐ same | same |
| organisations | all | ⇐ same | same |
| people | limited fields (S3) | all fields | same as updater |
In the table above the text “all” means that there are no restrictions. This is because that particular search only provides publically available information and no restriction on the user is required. A superscript on a statement of access refers to a search test that can be used to prove the access restriction false.
Note: The user type (i.e. whether guest, updater, statecoord, or admin ) is not used for searches.
Access Restrictions on the Update Home Page
The user type (i.e. whether guest, updater, statecoord, or admin ) is checked to determine if the user can access the Update Home Page. Once this is checked there are further checks for access.
On the Update Home Page updaters can either “Start new updates”, “View or edit your current updates” or “Check updates by others”. An example is shown below.
Under “Start new updates” on the left hand side of the Update Home Page, the access restrictions for checkout of entities is described by Table 1.
| Entity | Updaters can checkout | State Coordinators can checkout |
Administrators can checkout |
|---|---|---|---|
| caves | if they are in their allowed states list (1) | ||
| if they are in their allowed areas list (2) | same | ||
| maps: | if maps is checked on user admin page (3) and | ||
| cave maps | if they are produced by updaters org(s) (4) | same | |
| other maps | if they are in same state as updater | same | |
| areas | if areas is checked on user admin page | ||
| organisations | if orgs is checked on user admin page | ||
| if they are in updaters org list | same | ||
| people | if people is checked on user admin page | ||
| if they are in same org(s) as updater | same |
Table 1: Access restrictions for checkout of entities.
Example:
If they were a member of SUSS they would be able to checkout cave maps
or cave area maps produced by SUSS
(i.e. 517:Map_numberer_org_code must match one of the updater’s Organisation_code_1,
Organisation_code_2 or Organisation_code_3 values).
They would be able to checkout other maps such as topographic maps if their State
was the same as the map coverage (i.e. 490:State_code of updater matches the
map’s 197:Map_scope_state_code).
Organisations example:
If they were a member of SUSS (e.g. Organisation_code_1 = SUSS) they would be
able checkout the organisation SUSS and edit that
clubs details. If they are also a member of SSS (i.e. Organisation_code_2 = SSS) they also
be able to edit SSS details.
People example:
If they were a member of SUSS and SSS they would be able checkout any person
that is also a member of SUSS or SSS (i.e. any one of the updater’s
Organisation_code_x needs to match the other persons Organisation_code_y).
-
Under “View or edit your current updates” in the centre of the Update Home Page, the access restrictions are the same as Table 1 above.
-
Under “Check updates by others” on the right of the Update Home Page, the access restrictions are described by Table 2:
| Entity | Updaters can check others updates of | State Coordinators can check others updates | Administrators can check |
|---|---|---|---|
| caves | in their allowed area list | same | yes |
| cave maps | in same org(s) as other | same | yes |
| cave area maps | in same org(s) as other | same | yes |
| other maps | in same state as other | same | yes |
| organisations | in same org(s) as other | same | yes |
| people | in same org(s) as other | same | yes |
| areas | no | if in same state | yes |
Table 2: Access restrictions for checking updates by others.
Access Restrictions on the Current Updates Page
On the “Current Updates” page (example shown below) the updates that will be visible to an updater are their own updates and those updates of others described by Table 3.
| Entity | Updaters can see | State Coordinators can see | Administrators can see |
|---|---|---|---|
| caves | in allowed areas list | same | all |
| cave maps | produced by updaters org(s) | same | all |
| cave area maps | produced by updaters org(s) | same | all |
| other maps | if in same state as updater | same | all |
| organisations | if in same org(s) as updater | same | all |
| people | if in same org(s) as updater | same | all |
| areas | no | if in same state | all |
Table 3: Access restrictions for checking updates by others.
Access Differences between an Updater and a State Coordinator
In most cases for updating there is no difference between an Updater and a State Coordinator. The Administrator may have set a restricted set of allowed states, allowed areas and allowed fields. Access is based on these settings. However the exception is for updating areas – only a State Coordinator can update areas. The reason for this is that the names of areas, their extent and description is decided at a state level.
User Types
There can be several types of users in the KID. Currently the user types are:
- Administrator
- State Coordinator
- Updater
- Guest
When a new user is created they are assigned a "user type". There is just one user of type guest. That is the one that a normal user logs on as when they visit the KID as a guest user. The login name for this is guest and the password is on the ASF’s KID introduction page. The other users are either an administrator, a State Coordinator or an Updater. Each one has a personal login name and password which is not to be shared by anyone else.
The user type determines what areas of the KID the user can access. Guests can access the read-only search area at caves.org.au/kid/users/search/ but cannot access the administration or updaters area. Updaters can access the updaters area at caves.org.au/kid/users/update/ but cannot access the administrative areas of the KID.
Administrators can access all areas.
State and Area Restrictions, Read and Write FIDs
When a user is created as well as being assigned to a user type there are also restrictions that are applied depending on who they are. These restrictions are:
- Allowed States - the States that a user is allowed to access e.g. NSW
- Allowed Areas - the areas that a user is allowed to access e.g. Jenolan & Wombeyan Caves
- Read FIDs - the database fields that a user can read e.g. 56 Length, 77 Contents
- Write FIDs - the database fields that a user can write to
Here is an example of the restrictions for the current user types:
|
|
|
||||||||||||||||||||||||||||||
The guest user can view all states and all areas but has a restricted set of database fields that they can read. For instance they cannot read the fields 12 Decoration, 21 Latitude, 22 Longitude, 27 Nearest Locality, 37 Genus name, 38 Species name, 72 Contents and some other fields. They cannot write to any field and in any case they cannot access the updating area.
An updater is usually restricted to the state and area(s) that his club has tagging or updating rights to as determined by the State Coordinator. They would be able to read from and write to any of the KID fields.
A State Coordinator is the same as an updater.
The above access restrictions can lead to some updaters or State Cordinators getting confused. For instance if an updater in a NSW club was logged on as an updater and tried to access TODO
How the above Restrictions are Used
The state, area, read and write FID restrictions are checked whenever an updater goes to update an entity. Entities are things like caves, maps, people or organisations.
- Caves - An updater can update a cave if that cave is in their Allowed Areas list. The read and write FIDs are also checked.
- Cave Maps - An updater can update cave maps if they are a member of the organisation that produced the map. For example if the map is 2B4.SSS107 (i.e. a map of cave number 4 at Bungonia Caves, NSW and produced by SSS) you would have to be a member of SSS to be able to checkout that cave for editing.
- Other Maps - An updater can update any of these maps i.e. topographic, cadastral, geological.
- Organisations - An updater can update organisations data if they are a member of that organisation.
- People - an updater can only update a persons data if that person is in the same organisation as the updater.
- Areas -
TODO I have removed all State restrictions except for CAVES entities.
People
An updater can only checkout a person for updating if they are also a member of the same organisation as the person they are attempting to checkout. That is one of the organisation codes for the updater must match one of the organisation codes of the person being checked out.
Notes: It does not matter if the person lives in another state. This because an organisation may have members that live in other states.
(See 501 organisation_code_1, 502 organisation_code_2 and 503 organisation_code_3)
Cave Maps
An updater can only checkout a cave map or an cave area map for updating
if they are a member of the same organisation that produced the map.
That is, one of the updaters organisation codes (501, 502, 503) must match the maps
200 map_source_organisation_code.
(See 200 map_source_organisation_code)
e.g. A SUSS user should not be able to edit maps done by club SSS.
Cave Area Maps
The same restrictions apply as for cave maps.
All Other Maps
All other maps can be checked out and updated by any updater. This lower level of restriction is because such maps are usually not owned by any one organisation so it’s simpler to let any updater update them. Other maps include: topographic, cadastral, geological, thematic, road, aeronautical and hydrographic maps.
An org may produce a map of a cave in another state (in fact it’s quite common) so they need to be able to checkout a map if the map_numberer_org_code matches one of the orgs that the updater is in: e.g. In Tasmania there is a map of Mill Cave, MC 63, map number 7MC63.UQS213, produced by University of Qld. Speleological Society.
This map number 7MC63.UQS213 (partially) follows the ASF map numbering guidelines where:
7 = Tasmania
MC = Mole Creek area
63 = the cave number
UQS = the org that produced the map (Uni Qld Speleos)
213 = the 213th map that UQS produced.