-
Notifications
You must be signed in to change notification settings - Fork 42
Home
- Asset: An individual piece of equipment that is uniquely identifiable.
- Attribute: A property or metric of a model or asset, with a specified value.
- Category: A hierarchical organization for the purpose and/or form factor of a model, such as Handheld Multimeters. Models may be assigned to multiple categories.
- Manufacturer: The producer or vendor of an asset that specifies a model.
- Model: A manufacturer code that identifies a specific design or option. There may be may assets of the same model, each with different serial numbers.
- Location: A hierarchical organization for the physical storage and/or usage location of an asset, such as Campus > Building > Room. Every asset has a home location (where it is stored), and possibly a usage location specified by the user during check-out.
-
Transaction: A timestamped action that changes the state (availability) of an asset.
- Check-in: Return an asset to its home location.
- Check-out: Claim temporary custody of an asset by moving it to a specified location for a specified purpose and estimated time period.
- Restrict: Prevent check-outs of an asset. This does not preclude use of the assets, but it must remain at its home location, such as for a permanent test fixture or workstation.
- Unrestrict: Allow check-outs of an asset that is currently restricted.
-
User: An authenticated person, assigned to one of the following roles with associated permissions:
- Disabled: No access.
- Viewer: Can view all assets, models, manufacturers, locations, categories, and attributes, but not transactions or users.
- User: Viewer permissions, but can view transactions, and can check in and out assets.
- Contributor: User permissions, and can add/edit/delete assets, models, manufactures, locations, categories, and attributes.
- Administrator: Contributor permissions, and can add/edit/delete users and transactions, including (un)restricting assets; import/export SQL and uninstall.
TODO
The Administrator role can emulate other roles and/or users via the admin
query string parameter array with keys:
-
role
: Numeric ID of role to emulate listed in theroles
table andwww/includes/classes/DataModels/Role.php
. Non-persistent, must be present in HTTP GET request. -
user
: Numeric ID of user to emulate listed in theusers
table. Persistent until changed or re-authenticated.
Note that if both role
and user
are provided, the given user is emulated with the given role. Example: ?admin[role]=8&admin[user]=3
Without modifying the source code, there are some convenient options to customize some features of ISLE, all of which are accomplished my modifying www/includes/settings.php
, which is generated by the setup wizard. The complete list of settings and their defaults can be found in www/includes/classes/Settings.php
.
While most settings have literal values, hooks are PHP callables that may return a value and/or output to the buffer.
ISLE has a built-in simple user/password authentication function (ISLE\Service::userAuthenticator
), but this can be overridden by a custom function. A common example is to implement LDAP authentication:
return [
'hooks' => [
'authentication' => function() {
try {
$entries = Ldap::search('uid=' . $_SERVER['PHP_AUTH_USER']);
if (!($entries['count'] ?? 0)) {
throw new Exception('User ' . $_SERVER['PHP_AUTH_USER'] . ' not found in the LDAP directory!');
}
$entry = $entries[0];
$id = ISLE\Service::executeStatement(
'
SELECT `id`
FROM `' . ISLE\Settings::get('table_prefix') . 'users`
WHERE LOWER(`email`) = LOWER(?)
',
[['value' => $entry['email'][0], 'type' => PDO::PARAM_STR]]
)->fetchColumn();
if (!$id) {
throw new Exception('You are not authorized. Please contact an administrator for access.');
}
} catch (Exception $e) {
$_SESSION['message'] = [
'type' => 'danger',
'text' => $e->getMessage()
];
require 'views/layouts/pagestart.php';
require 'views/layouts/pageend.php';
exit;
}
return [
'id' => $id,
'name' => $entry['displayname'][0],
'email' => $entry['email'][0]
];
},
]
...
];