-
Notifications
You must be signed in to change notification settings - Fork 198
Resource management
Users of a task management system are often required to track and link other resources along with their tasks. Some example are:
- meeting rooms
- vehicles
- tools of trade (eg acetylene torch for plumber)
- computer hardware and software
The particular requirements of this author is the last one: computer resources, but the goal is to create a resource management concept which is useful more broadly.
Because my particular requirements are based on password and IT hardware management, I’ll focus on that use case. However, I encourage others to add further use cases here so that they can be considered within the design.
In acting on a task, support staff often need to log into a computer or piece of hardware. Having it linked to the task makes it quick and easy to find. Details of the hardware configuration are at hand, as is the password to log into the relevant server and software. Finding a particular resource can be difficult, so not only is keyword searching available, but also filtering by client and resource type. Typical resource types in this environment are:
- printer
- desktop
- laptop
- router
- mysql database
By arranging resources hierarchically (resources have a ‘parent’) it makes navigating through a long list of resources quick and simple.
An administrator can create resource types by adding them to a list. For each resource they can then define a list of attributes. Removing an attribute must be accompanied by a warning that this attribute will be deleted from all resources currently in the system. Removing a resource type merely sets any linked resources as having a null (unassigned) resource type.
Each attribute has a name which will be displayed as a label in the resource edit view. It may be set as mandatory in which validation prevents saving that resource without entering a value. It may also be set to allow multiple attributes of this type, for instance for a server with multiple IP addresses defined as attributes. The defaultFieldLength can be blank, or a number of characters which changes how large a field is used to display this attribute for each resource (it doesn’t perform validation on the length). Finally, for advanced users, they can define a regex which is used to validate any value entered, (eg. “(\d{1,3}\.){3}” for an IP address).
“[ ] This attribute is a password” is a final option for these preferences.
- view resources
- create/edit resources
- view resource passwords
- edit resource passwords
In addition, the entire resource subsystem can be enabled per company.
Finally, in the config file on disk is a 32 character random string (created as a random string by setup.rb) which is used as the preshared key for encrypting passwords. A note above it read “Changing this key will render all passwords existing in the system forever inaccessible.”
Users with appropriate rights can edit, create and view resources. A new item in the top menu is available called “Resources” which allows access to the resource list. A filter at the top has options for:
- client (only clients with actual resources in the system, not all clients display in the popup)
- resource type
Ideally, the existing tags system could be extended to resources, but not sure about degree of difficulty of this one.
Resources are displayed hierarchically, just as tasks with dependencies are drawn.
Clicking on a resource takes you to the edit view. Here all the attributes are shown along with a large notes field. Attributes are displayed with the ResourceTypeAttribute.name as the label and a text entry field next to it. Any ‘password’ fields have a button to the right of the value entry field: “show password”. Clicking this button displays the password with an Ajax request and write out a log entry.
Upon creating or editing a resource, all mandatory attributes are displayed in the list with null values. A popup of attribute types at the top allows the user to add additional attributes to the list. They are kept sorted by the sort order in the ResourceTypeAttribute.
At the bottom of the resource edit view is a history view very similar to the task history. It shows the history of every edit to each resource, along with the history of every password view (that is, every time someone requested to view the password). This history is non-editable.
Assigning access rights per resource to users is necessary in the long term, but will need to await work on the access rights system for CIT.
[ResourceType] company_id id name [ResourceTypeAttribute] company_id id resourceType_id -> [ResourceType] name isMandatory allowsMultiple hasPassword validationRegex defaultFieldLength sortOrder [Resource] company_id id resourceType_id -> [ResourceType] name parentResource_id -> [Resource] client_id -> [Client] createdOn modifiedOn notes [ResourceAttribute] company_id id resource_id -> [Resource] value password (this is a separate field stored encrypted)