The aim of this project is to provide administrators with a graphical user interface – the permissions editor – to restrict features and data access to an SOS instance for the defined user roles.  During the second half of the project we mainly worked on the user stories and focussed on providing additional functionalities and improving the process of creating permission sets and permissions.  The previous blog post contains the work conducted during the first half of the project, after which all the basic user stories were in place. Below are the resources for the project which track the status and work done:

• User stories
• Weekly Reports
• User Documentation (Project Wiki)
• Project Repository

The following user stories and use cases highlight the major work done on the project since the mid-term.

GENERAL CHANGES IN THE USER INTERFACE

We dropped the idea of a wizard style User Interface for creating a permission and came up with the concept of a single page. This page contains all the information in one place, which, from usability point of view, we thought would be better. Figure 1. depicts the current user interface of the application.

USER AUTHENTICATION

The application is now protected with an HTTP Basic Authentication mechanism. Only the correct combination of username and password will allow the user to proceed.

CREATE NEW PERMISSION SET

Figure 1. Create Permission Set (left) and Create Permission (Right)

This use case dealt with creating a new permission set (see Figure 1). Every permission set contains at least one permission. This is not trivial because, a permission has to be stored against a permission set, but since we were creating a new permission set the permission had to be stored somewhere. The Timeseries Protector handles this use case very well.

SAVE AS NEW

With the completion of this user story, the user is now able to save an existing permission set/permission as a new permission set/permission (see Figure 2).  This option will come in handy when a user wishes to create something almost similar to an already existing permission set/permission.

HELP TEXT IN UI

Help text has been added in the UI wherever we felt it was necessary. Figure 3 shows an example. The help text gives the user the right context and will guide him/her to make sense of the information and actions on the page.

SEPARATION OF FORM FIELDS

Fields required for creating a permission set are now divided into “basic settings “and “advance settings” for user convenience. The fields in “advance settings” are not required, but if a user feels the need, he/she can enter the values explicitly (see Figure 4).

DOWNLOAD PERMISSIONS XML

The Timeseries Protector now comes with the facility of viewing and downloading the permissions.xml - the raw data file for storing the permission configuration – under the condition that at least one permission set has been created. Figure 5 provides an example.

MAPPING RESOURCE PARAMETERS TO ENFORCEMENT POINT

Previously, the resource parameters displayed in the UI were fetched from all the defined SOS instances. After mid-term, the Enforcement Point URL is now mapped to a specific SOS instance, so that only the necessary parameters are fetched. The user must manually configure this in the editor-config.xml , shown in Figure 6.

Demo

Within the next few days, the demo server will provide an up and running instance of those user stories completed to date.

Future Tasks

Although we accomplished most of the tasks which were planned, there is always a scope for enhancements and additional functionalities as you keep on building things. Below are some of the future tasks:

• provide the user with the option to map enforcement points to the SOS instances from the User Interface
• enhance the search functionality which is currently implemented in the UI and additionally filter the content by column rather than just by row
• allow the user to add obligations while creating a permission
• enhance the UI architecture a bit more and use a more structured approach
• constantly improve the help documentation and Project Wiki thus making it more useful for the developers and users.

Summary

As a graduate student in GeoInformatics, it was a great experience for me to connect with such a big community and learn a lot about “open source”. I feel the Timeseries Protector will be a very useful tool for anyone who will be working with SOS as it provides a crucial restriction mechanism. From Project and Time Management to learning new technologies – I was always motivated to do more and stay connected with 52°North.

I was a bit new to Sensor Web, so it was a bit tough in the early phase since I had to design new screens and lacked the right perspective of the application’s usability. I owe sincere thanks to my mentors for always helping me with almost everything. Concerning the goals of the project, I believe most of them have been completed, but there is still a lot scope for improvement and I would encourage students to extend this application or connect with other projects the community has to offer.