Skip to main content

Admin & Maintenance Interface

The purpose of this code is to administer the GramChain. The GramChain Admin interface interacts entirely via JSON APIs to the GramChain DB. The Admin interface needs to be secured via its own usernames and passwords (not to be confused with scanner logins) and will be used by a small number of internal staff. The default access control functionality is recommended, additional APIs can be built to support this.

Admin UI Scope​

The following objects edit functionality is of high-importance:

  • StorageProviders: These are the vault locations where a bar is or was stored. Basic information that needs to be maintained includes address and vault contact info. A short code, created by us, is used to identify each location.

  • Scanners: These are the devices used to scan, via RFID, and insert GramChain Data. The Scanners are Identified by unique scanner ID coming from the device. Use any string until scanners are live.

  • ScannerLogins (FK StorageProviderID): These are the scanner logins used by vault operators at a StorageProvider Location. In practice, depending on the vault, we will likely assign a fixed number of logins per StorageProvider such as (Login1_SP1, Login2_SP1, Login3_SP1) with associated passwords. Password management will be implemented later. Currently only basic functionality is needed. When inserting a login, a StorageProvider ID is needed (e.g. Dropdown in UI).

  • ScannerAtLocation (FK ScannerID and StorageProviderID): This is a log which keeps track where a specific scanner is located given a certain time period. When a scanner boots up it will send it’s ScannerID to the LoginList API to check where the scanner is assigned (using ScannerAtLocation table) and then a list of logins for the assigned location is returned. This system prevents the scanner from being used at the wrong location as vault operators would be unable to log in (given that login from other location are returned).

  • BrandCodes: These are used by the scanner to limit and control the quality of the assets we add. This entry might have frequent additions.

The following objects are of secondary-importance:

  • ItemTypeCodes: Used as a grouping. This will not be updated often.

  • MetalCodes: Used as a grouping. This will not be updated often.

The following objects do not need an edit UI:

  • MeasurementUnits: Nearly unchanging.
  • EventTypeCodes: additions imply new functionalities, requiring coding.
  • LockStatusCodes: additions imply new functionalities, requiring coding.