BCM - Core Facility Management System - dev.mri.cnrs.frdev.mri.cnrs.fr/.../1573/BCM-Core-Facility-Management-System.pdf · • as an inventory and help-desk system the open source

“BCM - Core Facility Management System” Montpellier RIO Imaging

Contact: Volker Bäcker / 06 50 19 27 42 / [email protected] Version 1.0 / 28.10.2015

BCM - Core Facility Management System

Montpellier RIO Imaging

28.10.2015

Responsible: Volker Bäcker

Developer: Erik Lanave

Contact: 06 50 19 27 42 / [email protected]

1/24

mailto:[email protected]




Table of Contents1 Context..............................................................................................................................................52 Project description.............................................................................................................................53 General requirements.........................................................................................................................64 The structure of BCM and its facilities.............................................................................................65 Modules.............................................................................................................................................66 List of functions.................................................................................................................................6

6.1 Functions of CFMS-Accounting................................................................................................66.1.1 Functions of the cfms admin tool.......................................................................................76.1.2 Functions of the cfms accounting client...........................................................................146.1.3 Report creation.................................................................................................................166.1.4 CFMS Dysfunction Warning............................................................................................176.1.5 CFMS Autonomy Management.......................................................................................196.1.6 CFMS Overbooking Report.............................................................................................226.1.7 CFMS Third-Party-Tool Integration................................................................................22

7 Preliminary Schedule.......................................................................................................................24

2/24




Illustration IndexIllustration 1: GUI to list and create locations......................................................................................7Illustration 2: GUI to modify and delete a location..............................................................................7Illustration 3: GUI to list and create permissions.................................................................................8Illustration 4: GUI to modify permissions............................................................................................8Illustration 5: GUI to list and create roles............................................................................................8Illustration 6: GUI to modify roles.......................................................................................................9Illustration 7: GUI to attach roles to users............................................................................................9Illustration 8: GUI to list and create resource-categories...................................................................10Illustration 9: GUI to update resource-categories...............................................................................10Illustration 10: GUI to list and create resource-kinds........................................................................10Illustration 11: GUI to modify and delete resource-kinds..................................................................11Illustration 12: GUI to list and create resources.................................................................................11Illustration 13: GUI to modify and delete resources..........................................................................11Illustration 14: GUI to list and create tags..........................................................................................12Illustration 15: GUI to modify and delete tags...................................................................................12Illustration 16: GUI to tag resources..................................................................................................12Illustration 17: GUI to list and create users internally........................................................................13Illustration 18: The login dialog.........................................................................................................14Illustration 19: The accounting system client window.......................................................................14Illustration 20: Changing the current user on the accounting system client.......................................15Illustration 21: The one user mode of the Nanozoomer client...........................................................16Illustration 22: The multi-user mode of the Nanozoomer client........................................................16Illustration 23: The GUI of the Dysfunction Editor...........................................................................18Illustration 24: A dysfunction displayed in the reservation system....................................................19Illustration 25: GUI to edit the message of the autonomy-warning...................................................20Illustration 26: The GUI to declare users autonomous on resources..................................................21Illustration 27: Preliminary Schedule.................................................................................................24

3/24




Changes

Version 0.1 04.05.2015 first version

Version 1.0 28.10.2015 first version with a listing of all functions

4/24




1 ContextMontpellier RIO Imaging is a core imaging facility in Montpellier. It is distributed over multiples sites belonging to different institutions in Montpellier. It is part of the BioCampus Montpellier that manages the 12 regional life science core facilities.

Since 2005 different tools for managing the MRI facility have been developed:

• unique login per user by using an ldap server

• a custom build single sign on system that creates a mri session used by multiple applications

• a simple user inscription that asks for minimal data: name, first name, email, password and login

• as a reservation system for resources (microscopes, cytometers, ...) the open source project grr has been used

• an accounting system that

◦ tracks the usage of resources

◦ manages accounting groups

◦ manages resources and tariffs

◦ creates reports

Users have to buy hours that are automatically counted down when a resource is used.

• as an inventory and help-desk system the open source project glpi has been used

• autonomy management: trained users are declared autonomous for a resource category. When a user who is not autonomous for a resource makes a reservation for that resource, theresponsible is alerted by an email.

• dysfunction management: users are informed about dysfunctional resources in the reservation system.

In 2014/15 a user inscription and management web-portal has been developed for BioCampus Montpellier. It allows a unique inscription to BCM for all the facilities belonging to it. Users can than choose the facilities that they want to use and a facility manager can accept or refuse the accessto the facility.

2 Project descriptionThe project aims at developing a consistent, modular and customizable Core Facility Management System that provides the functionalities that have been provided by the different tools at MRI before. This system should be made a available by BCM and each of the facilities belonging to BCM can choose which modules it wants to use.

2 Project description 5/24




3 General requirementsCommunication should ideally be possible without the need of opening special ports.

All applications except of the component watching the usage of a resource should be web-applications.

4 The structure of BCM and its facilitiesEach user inscribed to BCM with a possible role: user, staff, manager, admin. Each user can be subscribed to one or more facilities with one of the roles: manager, staff, user.

A facility can have sites and each site can have staff and managers.

5 ModulesThe following modules must be available:

• single sign on

• reservations system

• inscription / user management

• facility management

• resource management

• project management

• accounting

• reporting

• inventory

• help desk

• dysfunction management

• autonomy management

6 List of functionsIn this chapter the elementary functions that have to be migrated are described.

6.1 Functions of CFMS-Accounting

The accounting system allows to follow the usage of the resources of a facility. It manages credits and tariffs and allows to create reports.

The system has two parts: a REST-server that allows to execute operations from the distance and a web frontend.

6 List of functions 6/24




6.1.1 Functions of the cfms admin tool

The cfms-admin tool allows to enter and modify data in the cfms-accounting system.

1. Locations (Task #1112)

A location represents a logical or physical site of the facility at which users can access resources. Resources (microscopes, analysis pcs, ...) will reference locations. In the accounting system locations are mainly used for reporting. Associated with a location can be a number of responsible engineers.

TASKS:

1. Create a rest API that allows to create, edit, delete and modify locations.

2. Write an editor that allows to create, edit, delete and modify locations.

Illustration 1: GUI to list and create locations.

Illustration 2: GUI to modify and delete a location.

2. Permissions (Task #1116)

Permissions are used in roles to determine the specific access a user has to a resource or location. The predefined permissions are:

list, read, modify, create, delete and create_report.

Since for a permission to have an effect the program must know and use it, editing permissions is ofrestricted use.

TASKS:

1. Write a REST API to create, edit delete and modify permissions





2. Write an editor to create, edit, delete and modify permissions

Illustration 3: GUI to list and create permissions.

Illustration 4: GUI to modify permissions.

3. Roles (Task #1117, Task #1116)

A role determines what permissions a user has on a resource. A role consists of a set of permissions for each resource-type in the system. A role can be restricted to all resources (microscopes, etc) on alocation or to a specific resource.

Roles can be attributed to users. If a user has multiple roles, the permissions for a resource are the union of the permissions of the different roles.

TASKS:

1. Write a REST API to create, edit delete and modify roles

2. Write a REST API to attach roles to users

3. Check the access rights in all REST-requests

4. Write an editor that allows to create, edit delete and modify roles.

5. Write an editor that allows to attach roles to users.

Illustration 5: GUI to list and create roles.





4. System Change Log (Task #1118)

All changes are logged into the system change log with a timestamp, the user-id of the person executing the change, the old values and the new values.

TASKS:

1. Write a library so that the server-side services can access the system-change-log.

2. Add the logging to all the REST-services.

3. Write a REST API to read and query the system-change-log.

4. Write a user-interface to read and query the system-change-log.

5. System Error Log (Task #1119)

Errors and warnings are logged into the system error log. The log message can have different levels so that less important things will not hide more important messages.

TASKS:

1. Write a library so that the server-side services can access the system-error-log.

2. Add the logging to all the services.

3. Write a REST API to read, query and write the system-error-log.





4. Write a user-interface to read, query and write the system error log.

6. Resource Categories (Task #1121)

All resources of the same kind, that have the same tariff, are attached to the same resource category.This allows to change the tariff of all resources of the same kind easily.

TASKS:

1. Write a REST API to create, edit delete and modify resource categories.

2. Write an editor to create, edit, delete and modify resource categories.

7. Resource Kinds (Task #1122)

The resource kind allows to create reports for special kinds of resources only (acquisition, analysis, deconvolution, ...).

TASKS:

1. Write a REST API to create, edit delete and modify resource kinds.

2. Write an editor to create, edit, delete and modify resource kinds.





8. Resource (Task #1123)

A resource is a machine or software that is managed by the facility and that users of the facility can use, for example a microscope, an analysis pc or a web-application like huygens remote manager. A resource has a location at which it is placed, a category that determines its tariff and a kind. The kind tells if the solution is an image acquisition machine, an analysis-pc or eventually a software like huygens-remote-manager.

TASKS:

1. Write a REST API to create, edit delete and modify resources.

2. Write an editor to create, edit, delete and modify resources.

9. Tags (Task #1124, Task #1125)

A tag is an arbitrary keyword that can be attached to an entity, especially to a resource (microscope, pc, ...). The tags provide a generic mechanism to treat a number of resources differently from others. Currently the tag time-lapse-tariff is used to mark the resources for which the special night tariff applies.

TASKS:

1. Write a REST API to create, edit delete and modify tags.

2. Write an editor to create, edit, delete and modify tags.





3. Write an editor to attach tags to resources.

10. Price of hour (Task #1126)

The price of a reference hours for each user category (public, private). The price is a value with history, so that the current price and the price at a given point in the past can be accessed to calculated costs of usage.

TASKS:

1. Write a REST API to create and read price_of_hour entries.

2. Write a gui-interface to create and read price_of_hour entries.

11. Groups and Membership (Task #1127)

A group has a number of users who are members of the group. The group has a credit (in reference hours or euros). A group can be a subgroup of another group, which means that members of the subgroup have access to the credit of the super-group.

TASKS:





1. Write a REST API to create, read, update and delete groups and memberships.

2. Write an editor to create, read, update and delete groups and membership.

12. Users (Task #1114)

Users can either be created within the system or imported from an external source (ldap or other). The external source can be configured in the system. The data needed are the login, the password, the firstname, the name and the email.

TASKS:

1. Write a REST-API to create, edit, delete and modify users.

2. Write an editor to create, edit, delete and modify users.

3. Write a REST-API to set the user import settings.

4. Write an editor to set the user import settings.

Illustration 17: GUI to list and create users internally.

13. Authentication (Task #1206)

To use the application a user must authenticate himself by providing a username and a password. This can either be done on the login-page of the application or in an external single-sign-on system (LemonLDAP).

Independently from the angular-client application, each call to the REST-server needs an authentication. For this purpose a token is created at the authentication and used in subsequent requests to the REST-server.

TASKS:

1. Write a rest api for authentication that sends a jwt-token when valid credentials (login, password) are send.

2. Check the token for all REST accesses except the authentication.

3. Write a login page and make the client use the token obtained after login in subsequent requests.

4. Check and import the user session from a single sign on system (LemonLDAP)





14. Manager Transactions (Task #1134)

Manager transactions modify the credits of groups. A transaction can be a withdrawal or a deposit. Besides a credit can be set to zero or transferred from one group to another.

TASKS:

1. Create a REST-API for the manager transactions.

2. Create a user interface that allows to execute manager transactions.

6.1.2 Functions of the cfms accounting client

The accounting client is installed on the resources of the facility (microscopes, analysis pcs, ...) and is started when an operating system session is opened. It sends a withdrawal for each time unit to the server. If a user is member of multiple groups he can select which credit he wants to use in the beginning. The user can be changed from the client. An admin can log-in for a user. The remaining credit is displayed on the client.





15. Communication with the REST-server (Task #1130,Task #1135)

Instead of the current communication with a java server application the client must now communicate with the REST-server. The client must authenticate the user against the REST-server. It must retrieve the available credits and groups of the user, the remaining hours and the server-time.It must send a withdrawal each given time-interval (usually 15min).

TASKS:

1. Provide authentication for the client.

2. Write a REST API for the information retrieval (available credits, remaining hours and server-time)

3. Write a REST API for the withdrawals.

4. Rewrite a client to use the REST API instead of the current client-server communication.

16. Update of the accounting client (Task #1137)

The java client should check by itself if a newer version is available on the server and download it. It will schedule the update (the replacement of the jar files) in the operating system.

17. Adaptation of the Nanozoomer Client (Task #1132)

The nanozoomer accounting client is the special accounting client for the Hamamatsu Nanozoomer. In contrast to the normal accounting client it offers three modes:- an administrator selects a user for each set of slides- count the time needed to scan the sessions of the current user





- use bar-codes to attribute the slides to users (not fully implemented)

TASKS:

1. Write a REST API for the information retrieval - the client needs a list of all available users and credits.

2. Modify the java client to use the REST API instead of the current client-server communication.

6.1.3 Report creation

Create a system that allows to create reports of the accounting system data using Jasper Reports.





Allow users to create reports about their own data online.

TASKS:

1. Create the report "releve de compte partiel titulaire"

2. Create the report "releve de compte sous groupe"

3. Create the report "releve de compte partiel personnel"

4. Create the report "global activity report"

5. Create the report "activity report per facility"

6. Create the report "mri activity report"

7. Create the report "report per resource"

8. Create the report "Usage per day".

9. Create the report "Users per resource".

10. Create the report "internal report".

11. Create the report "excel report".

12. Report all users autonomous on a given category.

13. Report all users autonomous on at least on category but not on the given category.

14. Report all users autonomous for at least one category and for the given category.

15. Report all users autonomous in no category except for the given category.

16. Install and configure the jasper reports server.

17. Create a user interface to run the reports with selected parameters (from- and to-date, user, group, credit, ...).

6.1.4 CFMS Dysfunction Warning

The dysfunction management allows to inform users about dysfunctions of resources.

18. Create and update Dysfunctions (Task #1142, #1143)

A dysfunction means that parts of a resource are not functioning and can not be used by users for the time being. When a user reserves a resource, the current dysfunctions of the resource are displayed in the reservation system.

The evolution of the dysfunction can be entered into the system. A history entry represents an update of a dysfunction. The dysfunction can be created, updated or closed. Each update can have a message for the user.

Users that have reservations on a system with a dysfunction are informed per email.

TASKS:

1. Write a REST API to create dysfunctions.





2. Create a REST-API for the creation of dysfunction history entries.

3. Write a dysfunction editor user interface.

19. Display Dysfunctions in the reservation system (Task #1144)

When a user makes a reservation for a resource that has a dysfunction an alert showing the dysfunction message will be displayed.

TASKS:

1. Write a REST-API to get the dysfunction message for a resource.

2. Write a plugin for the reservation system.





6.1.5 CFMS Autonomy Management

The system allows to manage the autonomy of users concerning a resource or a category of resources. A user is declared autonomous for a given category of resources after he received instructions of how to use this kind of resources. He remains autonomous as long as he uses the resource. However after he did not use the kind of resource for a longer time he loses his autonomy.

When a user who is not autonomous for a given resource makes a reservation on that resource, the responsible engineer of the facility is automatically informed.

20. Administration of the Autonomy System (Task #1140)

The hour at which the autonomy-reset task is executed and the duration for which a user remains autonomous, even without using the system, must be configurable in the admin-interface of the application. The message displayed to the user must be editable in the admin interface.

TASKS:

1. Write a REST-API to set the property values.

2. Write a user-interface to set the property values.





21. Autonomy Categories (Task #1136)

Categories group similar resources. When a user has acquired autonomy on one of the resources in a category he is considered autonomous on all of the resources of the category.

1. Write a REST API to create, update, read and delete competence categories.

2. Write a user interface to manage autonomy categories.

22. Manage Resources (Task #1138)

Allow staff members to group resources in autonomy categories. Add a resource to a category or remove it from a category.

1. Write a REST API to add and remove resources to and from categories.

2. Write a user interface to add and remove resources to and from categories.





23. Manage autonomy of users (Task #1139)

Allow staff members to declare users autonomous or to remove the autonomy. The autonomy must be reset automatically when a user did not use a resource of the given category for a given time.

1. Write a scheduled task that removes outdated autonomies.

2. Write a REST API to declare users autonomous and to remove the declaration for a category.

3. Write a user interface to declare users autonomous and to remove the declaration for a category.





24. Access control by autonomy (Task #1141)

Write a plugin for the reservation system that allows to send an email to the staff managing the resource, when a user who is not autonomous for the resource makes a reservation for it. Display a corresponding warning to the user.

6.1.6 CFMS Overbooking Report

A system that allows to create reports concerning the overbooking of resources. It reads the worked hours from cfms-accounting-system and the booked hours from an arbitrary reservation system, using an appropriate adapter.

25. Configuration of the system (Task #1145)

The report will compare the time reserved for a resource to the time the resource has actually being used (of the time being reserved). The information comes on the one hand from the reservation system on the other hand from the accounting system. A system administrator must be able to configure the input data for the report.

1. Write a REST-API to configure the overbooking.

2. Write a user interface to configure the overbooking.

26. Overbooking (Task #1146)

A staff member can create overbooking reports for resources between two given dates.

TODO:

1. Create a REST-API for the creation of the report that can be downloaded as pdf.

2. Create a user interface for the creation of overbooking reports.

6.1.7 CFMS Third-Party-Tool Integration

27. Install LemonLDAP (Task #1148)

LemonLDAP has been selected as single-sign-on system.

1. Install LemonLDAP

2. Connect our applications to LemonLDAP

28. Install a reservation system (Task #1149)

Users make reservations for microscopes and other resources via the reservation system. Autonomy control and Dysfunction warning need to be integrated into the reservation system, via plugins.

TASKS:

1. Install Booked (formerly phpScheduleIt) and find a way to realize our workflow with it.





2. Connect Booked to LemonLDAP

3. Write a plugin for autonomy control.

4. Write a plugin for the dysfunction warnings.

29. Authentication on pcs (Task #1150)

Adapt the authentication of the users on the microscopes and analysis pcs to the new system.

30. Adapt GLPI (Task #1151)

Adapt the helpdesk and inventory software GLPI to the new authentication.

31. Services on machines (Task #1152)

Adapt the different services on the microscope and analysis pcs, like the information display on thebackground, to the new system.

32. Redmine (Task #1153)

Configure the project management tool Redmine to use the new authentication.

33. Huygens Remote Manager (Task #1154)

Adapt the huygens remote manager to use the new authentication and accounting.





7 Preliminary Schedule

7 Preliminary Schedule 24/24


Documents

BCM - Core Facility Management System - dev.mri.cnrs.frdev.mri.cnrs.fr/.../1573/BCM-Core-Facility-Management-System.pdf · • as an inventory and help-desk system the open source