ICT-AGRI Grant agreement no 235460

Meta Knowledge Base Documentation and Guide Deliverable D2.4 Iver Thysen Morten Thysen 31 March 2014

ICT-AGRI Coordination of European Research on ICT and Robotics in Agriculture and Related Environmental Issues

Contents 1 Introduction ...................................................................................................................................... 5 2 Drupal core ........................................................................................................................................ 6 2.1 User account .............................................................................................................................. 6 2.2 User roles ................................................................................................................................... 6 2.3 Community Forum ..................................................................................................................... 7 3 Contributed modules ........................................................................................................................ 7 3.1 Spam user control ...................................................................................................................... 7 3.2 Project Intranet with restricted access ...................................................................................... 7 4 MKB Basic .......................................................................................................................................... 8 4.1 Website sections with separate menus ..................................................................................... 8 4.2 Project documents ..................................................................................................................... 9 4.3 Project calendar with events and registration ........................................................................... 9 4.4 Community event..................................................................................................................... 10 4.5 Content administration and maintenance ............................................................................... 11 4.6 Send email to selected users ................................................................................................... 11 5 MKB Organisation ........................................................................................................................... 11 5.1 Organisations ........................................................................................................................... 12 5.2 User profile............................................................................................................................... 12 5.3 Project and project participants .............................................................................................. 13 6 MKB Project Administration ........................................................................................................... 13 6.1 Work packages and tasks ......................................................................................................... 13 6.2 Milestones and deliverables .................................................................................................... 14 6.3 To-do lists ................................................................................................................................. 15 6.4 Partner consultation and submission ...................................................................................... 15 6.5 Event agenda and minutes....................................................................................................... 16 6.6 Newsletter ................................................................................................................................ 17 6.7 Project Partner Forum ............................................................................................................. 17 7 MKB Call Administration ................................................................................................................. 18 7.1 Call setup introduction (user guide) ........................................................................................ 18 7.2 Call setup .................................................................................................................................. 19 7.3 Call setup guide for call administrator (user guide) ................................................................ 19

7.4 Call topics setup ....................................................................................................................... 22 7.5 Call topics guide (user guide) ................................................................................................... 23 7.6 Call funding agency setup ........................................................................................................ 23 7.6.1 Call setup guide for funding agencies (user guide) ........................................................... 23 7.7 Call description page ................................................................................................................ 25 7.8 Call setup overview and handling ............................................................................................ 25 8 MKB Application .............................................................................................................................. 26 8.1 User groups (user guide) .......................................................................................................... 26 8.1.1 Partnering with User Groups (user guide) ........................................................................ 27 8.2 Application creation and submission ....................................................................................... 28 8.2.1 How to apply (user guide) ................................................................................................. 28 8.2.2 Project info ........................................................................................................................ 29 8.2.3 Partner info ....................................................................................................................... 30 8.2.4 Partner budget .................................................................................................................. 30 8.2.5 Application document ....................................................................................................... 30 9 MKB Call Evaluation ........................................................................................................................ 31 10 MKB Proposal Evaluation .............................................................................................................. 31 10.1 Evaluation guidelines (user guide) ......................................................................................... 31 10.2 Proposal evaluation ............................................................................................................... 32 10.3 Evaluation status and overview ............................................................................................. 33 10.4 Proposal selection .................................................................................................................. 33

1 Introduction The original Meta Knowledge Base (MKB) was developed in ICT-AGRI over a period of four years. It was during this period used as an important tool for the conduction of the ERA-NET with new developments added as needs have arisen. The content and use of the MKB are described in details in Deliverable 2.5 Evaluation of the ICTAGRI Meta Knowledge Base. The ICT-AGRI partners' evaluation of the role of the MKB is described in Deliverable 3.4 Report on ”Lessons-Learnt ” from the evaluation of instruments, mechanisms and processes. During its use in ICT-AGRI, the Meta Knowledge Base attracted interest for use also in other ERANETs and similar projects. The original Meta Knowledge Base was implemented by custom PHP code, which was not feasible for export to other projects. It was therefore decided to re-program the MKB within the framework of Drupal, a widely used Open Source Content Management System. The MKB implementation is thereby safely secured, as it is always possible to find programmers with Drupal experience. Basing the MKB on Drupal provides opportunities for adding extra value to the MKB, not least through the rich supply of user contributed modules, which allow fast implementation and good results. The draw-back of using Drupal (or any Content Management System) is the requirement to know in details how the system works, when it is necessary to develop custom source code for special purposes. The development and application of MKB on Drupal is a joint effort by several ERA-NETs: ICT-AGRI and ICT-AGRI-2 (ict-agri.eu), SUSFOOD (susfood-db-era.net), Cofasp (cofasp.eu), ERA-CAPS (mapping data base eracaps-psd.org) and Core Organic Plus (call administration eracall.eu). MKB on Drupal has its own website (mkb-drupal.org) with information, documentation and downloads. The main purpose of this documentation and guide is to provide an overview of the tools in MKB on Drupal. The documentation is intended for readers with at least basic knowledge to Drupal (e.g. site administrators) and much of the contents require knowledge to basic Drupal development. The documentation is not complete with regards to details. The main intention is to help site administrators and developers to find where settings and code are located in the Drupal application. The MKB Drupal tools are contained in modules, which can be exported from one application to several others. Developments can be undertaken on a development server and exported to production servers when fully tested. The documentation and usage guide is therefore organised after MKB modules. The present documentation and usage guide is print out from the online documentation and guide at mkb-drupal.org. The online documentation and guide is continuously updated according to the on-going developments on the MKB. This printed version must therefore be expected to be

increasingly out of date. Certain tools are under development at the time of writing and the documentation will be completed after the development phase.

2 Drupal core Specification: Tools referring to Drupal core are not included in any MKB module and must be edited manually. See documentation at Drupal. Implementation: The latest version of Drupal core

2.1 User account Module: Drupal core Specification: Custom fields in user account:    

Title First name Last name Country

Visitors can create account with administrator approval and without email verification Implementation: Manually set in Configuration -> People -> Account settings Who can register accounts?    

Administrators only Visitors Visitors, but administrator approval is required Require e-mail verification when a visitor creates an account.

Tool status: OK

2.2 User roles Module: Drupal core Specification: The purpose of user roles is differentiate access view, edit and delete content in the website among users. The Drupal standard roles are: 

Anonymous

 

Authorized Administrator

The roles added in the MKB are:  

Project member (access to the Intranet) Call adminstrator (access setup calls)

Implementation: Drupal core standard permission system is used. Tool status: OK

2.3 Community Forum Module: Drupal core Specification: The community Forum serves as discussion tool for the community Implementation: Drupal's standard forum Tool status: OK

3 Contributed modules Specification: Contributed modules installed from Drupal See documentation at the module page in Drupal Implementation: Installed and enabled in Modules

3.1 Spam user control Module: Contributed modules Specification: Prevention of spam users created by web robots. Implementation: Contributed module Botcha The text issued when a user is refused is quite cryptic and needs to be replaced Tool status: OK with need for improvements

3.2 Project Intranet with restricted access Module: Contributed modules

Specification: The purpose is to have a closed area in the website with access for project partners only. This closed area is called Intranet in the main menu. Implementation: The restriction of access is implemented by the contributed module Access Control, which adds the opportunity to specify access control to content types. For the Intranet it is used to block view access for anonymous and authorized users. This is an addition to Drupal's standard permission system, which grants all users permission to view all published content. Menu items, which links to blocked views, are automatically hidden by Drupal. The Intranet menu item in the main menu is also hidden when it links to blocked content. Tool status: OK

4 MKB Basic Specification: The very basic Meta Knowledge Base module Implementation: In accordance with Drupal principles and code of development

4.1 Website sections with separate menus Module: MKB Basic Specification: The main idea is to organise the content in sections corresponding to items in the main horizontal menu bar below the page header. Each section has its own sub-menu, typically in a left side column. There may or may not be a right side-column showing information related to the section. The dynamic content will therefore occupy one or two columns according to requirements to show the content in a suitable layout. The access attributed to user roles must be respected so that users are not shown menus if they do not have access to any of the menu items. Implementation: The display of menus in Drupal is controlled by a menu property of each piece of content. When a page is displayed, the corresponding menu is shown. Menu items, which the current user does not have access to are hidden, and if the current user does not have access to any of a menu's items, the menu is not shown. The MKB sites have a horizontal main menu with items, which each are pointing to an item in a separate side menu. When an item in the main menu is chosen, the page will also show the right side menu.

Menus are configured in Structure -> Blocks - Configure. There is an option to restrict the display of the menu by php code (in Visibility settings). This is chosen and this line is inserted: menu-machine-name can be found in the menu setup page.

The php function mkb_display_menu() is in the MKB Basic module; it return true if the current menu is the one named by the function's parameter. The menu-machine-name is stored in a session variable, which is used if the next page has no menu, causing the previous menu to be shown again. This is useful for example when shifting to an edit page. Tool status: OK

4.2 Project documents Module: MKB Basic Specification: The purpose is to make documents regarding the project available for the project partners only in the Intranet Implementation: The tool is implemented by a node content type with fields: Title, Body, Document (multiple files). Access control is set to view, edit and delete by project partners only (see Project Intranet with restricted access) Tool status: OK

4.3 Project calendar with events and registration Module: MKB Basic Specification: The purpose is a calendar in the Intranet with project events. The project calendar is a list of project events ordered by time. A project event includes a title, a text description, dates, location, event documents and presentations, and an option for adding registration of event participants. If registration is chosen, a link to registrations is added in the calendar. Registration of participants is shown in a list with person, arrival and departure or a message of decline, and optional remarks. A link to edit existing registrations is also available. A link to create a new registration is available at the top of the list.

The list of registrations is available in several versions via its URL (where [nid] is the id of the event node):    

project-event-registration/[nid]: Participant, Country, Arrival, Departure, Declined, Remark, Edit project-event-registration/[nid]/print: Participant, Country, Arrival, Departure project-event-registration/[nid]/print: Participant, Country project-event-registration/[nid]/xls: Participant, Country, Arrival, Departure, Declined, Remark, Edit to be downloaded and opened in Ms Excel

Implementation: Project event is implemented as a node content type wit h fields: Title, Body, Event dates (year, month, day hour, minutes; start and end dates), Event URL, Event location, Event registration (boolean), Event presentations (multiple files), Event files (multiple files) Project event registration is implemented as a node content type wit h fields: Title (pre-set to "Event registration"), Event (reference to Project event), Participant (reference to user), Decline (Boolean), Arrival (date; year, month, day hour, minutes) and Departure (date; year, month, day hour, minutes). The Project calendar is implemented as a view of Project events. Display is modified by a custom template file, which adds a link to registrations for events with this option checked. The event registration list is implemented as view of Project event registrations. Display is modified by a custom template file, which adds a link to the create and edit registrations. The template file also hide date if the participant has checked decline. Improvements may be made concerning filtering the calendar on past and recent/coming events, links to the special registration lists The template file furthermore creates special versions of the view when /print or /print/nodate are added to the URL. The export of the registration to a csv file is facilitated by the Drupal contributed module Views Export XLS. Tool status: OK with need for improvements

4.4 Community event Module: MKB Basic Specification: The purpose of community events is to inform users about relevant conferences and other events

Implementation: Community event is implemented by a node content type with fields: Title, Body, Event days (year, month, day; start and end dates), Event URL, Event location, Event country, Event presentations (multiple files), Event leaflet (multiple files) Community events are displayed by a view with link to the event node. A filter on past and coming events is needed Tool status: OK with need for improvements

4.5 Content administration and maintenance Module: MKB Basic Specification: The purpose is to provide project partners with tools to review and modify content added by authorized users Implementation: Content administration tools are implemented by views with extensible filters (search opportunities) and with links to edit the content displayed in the views. Administration views are available for users and organisations. The views are restricted to project partners. Tool status: OK

4.6 Send email to selected users Module: MKB Basic Specification: A list of users with a select box for each user and button to send mail through the site or open the current user's mail client with addresses inserted. Implementation: The tool is based on the contributed module Views Send, which is extended with the option to open the mail client with email addresses inserted. The code is in MKB Basic: mkb_basic.module and js.views_send.js Tool status: OK

5 MKB Organisation Specification: Organisations stored in a hierarchical structure and tools for utilising organisation data.

Implementation: Module

5.1 Organisations Module: MKB Organisation Specification: Organisations are stored in a hierarchical structure. If for example your organisation is Institute of Berries in University of Fruits, one must first create University of Fruits leaving Parent organisation = None, and then create Institute of Berries with Parent organisation = University of Fruits. All information which is identical for the two need only be entered for the first organisation. The organisation content type includes organisation type, a text description, contact information and address. Implementation: The hierarchical structure is implemented via the field parent-organisation in the organisation content type, which is selected from existing organisations in the database. Custom code reorganises the selection list by country and by the hierarchical structure. Two fields are generated when an organisation node is saved: Org_name holds the organisation name completed with its parents and Org_path holds the organisation path with top organisation first, which is used for ordering by the hierarchical structure. The code is in the MKB Org module. Organisation type is referenced from the taxonomy Organisation. Authorized users have access to add organisations and to edit/delete own organisations The selection list is restricted to the country of the current user in order to reduce the size Need: Update tree downwards when an organisation has been edited. Tool status: OK with need for improvements

5.2 User profile Module: MKB Organisation Specification: Optional user profile with fields:   

Organisation of the user Social media (links to the user's accounts in social media and personal website) CV

Implementation: Implemented by the contributed module Profile2. Fields are defined in Profile2 configuration (Structure -> Profile types)

Organisation is selected from organisations in the database (see organisation module) Social media can have several values. Edited with format plain text, the format are set to filtered text in order for display as links. Tool status: OK

5.3 Project and project participants Module: MKB Organisation Specification: The purpose is to present the project(s) and the project participants (organisation and contact persons) to the public. A further purpose is to relate work packages to projects. Implementation: Project is implemented by the node content type Project with fields: Title, acronym, duration (start and end date) and body (for a text description of the project). Project participants is implemented by the node content type Project participants with fields: Title, project (reference to Project nodes), participant number, participant organisation (reference to Organisation nodes), participant role (reference to taxonomy Project roles), participant contact (reference to Users) and participant people (reference to Users). Presentation is by the view Consortium, which takes Project as argument. The view is modified by views-view-table--consortium.tpl.php (adds an edit link for project member users). The Project node for ICT-AGRI-1 and ICT-AGRI-2 are not fully updated. Should be move from MKB Organisation module to MKB Project Administration module Tool status: OK with need for improvements

6 MKB Project Administration Specification: The MKB Project Administration module includes tools for an effective and open administration of ERA-NETs and other similar projects. Implementation: Under development

6.1 Work packages and tasks Module: MKB Project Administration Specification: The objectives of this tool are for the public:



To show the work packages and tasks as defined in the DOW to the public with contact forms to key persons

And for the Intranet   

To maintain and show the engagement in the project of the individual project partners To provide selection of WP in the send mail to partners tool To relate to-do-lists and other tools to WP

Persons shall be related to WP or tasks. The first person in a list is considered responsible. It shall be possible to create "not in DOW" WPs to capture extra tasks which are not foreseen and defined in the DOW. Implementation: Work package is implemented by a node content type with fields: Title, body, dates (start and end), WP number, reference to project (see the tool Project and project participants) in the DOW (whether the WP is defined in the DOW) and persons (responsible first). Task is implemented by a node content type with fields: Title, body, dates (start and end), task number, reference to work package, in DOW (whether the WP is defined in the DOW) and persons (responsible first). Presentation in Intranet: A view with WPs, tasks and responsible person (project as argument) A view with persons and related WPs and tasks (project as argument) Presentation in About: A Drupal book of WPs and tasks (for each project) Tool status: OK with need for improvements

6.2 Milestones and deliverables Module: MKB Project Administration Specification: The purpose is to show milestones and deliverables and to monitor their completion. The project's milestones and deliverables are taken from the DOW. In addition, fields for status (not due, in progress, delayed, in review, delivered), time of delivery and multiple file upload. Comments shall be open. Implementation: Milestones and deliverables are implemented by a generic node content type, Deliver-item, which also is used to generate to-do lists. Deliver item fields: Item type (Milestone, Deliverable, To do), Number, Title, Body, Project (reference to Project), WP (reference to Work package), Task (reference to Task), Person

(reference to user, multiple, responsible first), Delivery (date), Comments, Status (not due, in progress, delayed, in review, delivered), Delivered (date), Document (file: multiple). Comments open, Intranet menu. Fields are filled in as appropriate for the the item type. Milestones and deliverables are presented in views with link to items.

Tool status: OK with need for improvements

6.3 To-do lists Module: MKB Project Administration Specification: The objective is to add to-do lists to Work Packages and tasks. The items in the to-do lists shall describe the break down of the work in manageable pieces with regard to volume and time. The to-do list items shall relate to WP, task and persons, and they shall include text description, time schedule and status. Presentations of to-do lists shall include views by WP, by task and by persons. Implementation: To-do lists are implemented by use of the Deliver item (see Milestones and deliverables). To-do-item are presented by views, which can be filtered by project, WP, task, and person. Tool status: OK with need for improvements

6.4 Partner consultation and submission Module: MKB Project Administration Specification: The objective is to facilitate response from all project partners to inquiries, voting, reviews, meeting dates, reporting, submission of periodic reports, etc. The tool shall produce a page with the inquiry and time frame at the top and below a table with a row for each partner, where the response is shown when delivered. A first version shall implement a text form and file upload for the response. Later version shall implement appropriate forms for special inquiries. Appropriate aggregation and statistics facilities shal be added. Implementation: Consultation is implemented by a Consult item node content type with fields: Title, Body, Consult_type (inquiry, response), Inquiry (reference to a Consult item node of consult_type = "inquiry"), Participant (reference to Project participants), Delivery (date), Files (multiple). Comment: open; menu: Intranet.

A consultation is composed of one Consult item node of consult_type = "inquiry" and many referencing Consult item nodes of consult_type = "response". Presentation and operation is done by two views: Consultation list and Consultation Consultation list:  Filter by Consult item node of consult_type = "inquiry"  Fields: Participant number and acronym (from node Project participants), title linking to Consultation (with node id as parameter), body, delivery, Consultation: Contextual filter: URL parameter on field inquiry (therefore must a type "inquiry" node point to itself) Sorting: Consult type, Project participant number Fields: Participant number and acronym (from node Project participants), title linking to Consultation (with node id as parameter), body, delivery If there is no data from participant a link to create a node is provided. A custom template file is used to make create a user friendly layout and operation. A node form hook is use to customize the form to the two different input situations. Tool status: Not implemented

6.5 Event agenda and minutes Module: MKB Project Administration Specification: The purpose is to add agenda and minutes to project events. The tool shall facilitate the development of the agenda in an open and participatory manner and the tool shall facilitate the writing of minutes in an easy way, possibly during the event. Implementation: The agenda is composed of a set of agenda-item implemented by a node content type with fields: Title, Motivation (body), Event (reference to Event node), Presenter (reference to user), Files (multiple), Minutes, Rapporteur (reference to user). Comments shall be open. The agenda is presented by a view with a contextual filter for Event. The view is displaying an unformatted list with the fields (including comments) in an appropriate order and grouped on title. The items on the agenda are made collapsible on title via a template file (see https://drupal.org/node/1169632). A checkbox for Agenda is added to the Project event content type and a link to agenda is added to Project calendar (see Project calendar with events and registration)

Advanced additions are to provide a way reordering the agenda items and an option to close addition of new items at some time before the event. Tool status: Not implemented

6.6 Newsletter Module: MKB Project Administration Specification: The purpose is to create periodic newsletters from the contnet in the website. The newsletter creation shall include: A page with newsletter content teasers and links to full content to be displayed in the website and to be sent in a mail to newsletter recipients A pdf file with the complete newsletter to be downloaded from the website Implementation: It will take some looking around and experimentation to find a good way to do this. One possibility is to create the contents as article and provide each article with a tag for a prticular newsletter. A view of teaser can filtered by tag and thereby give the page of teasers. How to reorder articles? The Book module allows selection of articles, reordering of the articles in the book and gives a nice content menu. It is possible to create a socalled printer-friendly version of the whole book, but it looks terrible and requires styling. PDF export is not in standard Drupal. For the newsletters it can be done by saving a print a pdf (option in Chrome, at least). Tool status: Not implemented

6.7 Project Partner Forum Module: MKB Project Administration Specification: The purpose is a Partner Forum in the Intranet. Partners shall be able to raise a question or suggestion in a text and optionally attach a file. Other partners shall be able to add comments to the question or suggestion. Implementation: The Partner Forum is implemented by a node content type with fields: Topic (title), Body, Document (multiple files), Comments are open and threaded. Access to the Partner Forum is through a link in the Intranet menu to a view showing a list of topics with Topic (with link to the node), Name of creator, Post date, Number of comments, Date

of last comment, and author of last comment. The view has a link to create a new topic in the header. Tool status: OK

7 MKB Call Administration Specification: The MKB Call Administration module provides tools to setup a call in the MKB. By these tools a Call Administrator can define the call text, schedule, topics, fields in the application, funding agencies, budget conditions, contact persons, evaluators, etc. Call administrators can in addition open and close for creation of new applications and open and close for editing of existing applications. More information about the setup of calls can found in the specific guidelines in this section. This module is closely related to the Call Application module, the Evaluation module and the MKB Eval module. Implementation: The module contains a complete installation of content types, views, nodes (e.g. guidelines) and menu for call setup. Some additional manual work is required. The module also contains several hooks that modify the forms as well template files which modify the display of views.

7.1 Call setup introduction (user guide) The call submission and administration system can be customized to the requirements of each call and to the requirements of each participating funding agency. This page explains the overall principles in the setup of a call. The call setup is started by the call administrator defining the mode, topics, time schedule and application fields of the call. This is done by creating and editing a Call-main-page; detailed guidelines are in Call setup guide for call administrator and included in the edit page. The call topics must be created in the Call topics vocabulary as described in the Call topics guide. Each participating funding agency can then register their participation with funding contribution, conditions, contact persons and budget restrictions. This is done by creating and editing a Callfunder-page and one or more Funding-schemes; detailed guidelines are in Call setup guide for funding agencies and included in the edit pages. The definitions provided by the call administrator and the funding agencies are used to generate the call description to be published in the website. Publishing is done by placing a link to the call description page in the call menu.

The definitions are furthermore used to generate the application forms used by the applicants and to provide information for applicants in the application edit pages. The call administrator must be a user with the call administrator role. The funding agency representatives must be users with the project member role.

7.2 Call setup Module: MKB Call Administration Specification: Each call is, by this tool, setup by a Call Administrator with regard to call modes, opening and closing, time schedule, fields in the online application, budget issues, call office, etc. Implementation: Call Administrator is a user role. The Call Setup is implemented as the node content type Call-main-page. It has a a large number of fields documented in Call setup guide for call. The Call-main-page node ID is referenced throughout several modules: MKB Call Admin, MKB Application and MKB Evaluation. Needs: Separate forms to edit e.g. opening/closing of the call Tool status: OK with need for improvements

7.3 Call setup guide for call administrator (user guide) 1 Introduction This guide is intended for setting up a call on a MKB ERA-NET website. 2 Definition and description of the call Create a new page of the type call-main-page and fill in the fields as follows: Title: Fill in the title of the new call CALL DEFINITIONS 





Body: Fill in a description of a new call. You may provide a full description or a short description intended for the web and provide the full call description in a pdf. You may consider to edit the summary connected to the body field, if you are not satisfied with the automatically generated summary in teasers. Call open creating application: Check this field when the call is open for creating new applications. Uncheck the field when the call is closed creating new applications. ERA-NET partners with the 'project partner' role can test the submission system even when the call is closed. Call open for edit: Check this field when the call is open for editing existing applications. Uncheck the field when the call is closed for editing existing applications.

 

   

ERA-NET partners with the 'project partner' role can test the submission system even when the call is closed. Number of stages: Select "1" or "2". A two stage call has a selection of applications between the two stages. Current stage: Select the current stage of a 2 stage call. When stage 2 is selected only applications approved for the second stage will be open for submission. In a one stage call select stage 1. Funding mode: Select "Virtual Common pot", "Real Common pot", "Non competetive" or "Mixed mode" Topics: Select taxanomy. You will need to first create a taxanomy with the topics, possibly with sub-topics Theme funding: Select " No, funding agencies may only allocate a total funding" or " Yes, funding agencies may allocate funding per theme" Call documents: Upload call documents for download by applicants

TIME SCHEDULE Define the important dates and times for the call. Only filled in dates are displayed. Dates are only only used as information for applicants, they are not used to open or close submission.        

Date launch: Select date from pop-up calendar Date pre-registration close: Select date and time from pop-ups (if appropriate) Date pre-proposals open: Select date and time from pop-ups (if 2 stage call) Date pre-proposals close: Select date and time from pop-ups (if 2 stage call) Date pre-proposals notification: Select date from pop-ups (if 2 stage call) Date full proposals open: Select date and time from pop-ups Date full proposals close: Select date and time from pop-ups Date full proposals notification: Select date from pop-ups

3 Online application form The application form consists of four parts: A Project information, B Partner information, C Partner budget, and D Description of work (pdf upload). 3A Project information (filled in by the proposal coordinator) The project information form is defined by the content type application-project-info, which has pre-defined fields typically used in applications. These fields can be deactivated below. In addition there are five additional fields, which can be activated below. If additional fields are activated it is necessary to modify the content type with regard to the label of the activated fields. It is safe to modify the application-project-info content type, as long as machine-name are not altered and fields are not deleted. Please note that changes to to content type will apply to all calls defined in this website.

In the edit page you will find check boxes for enabling/disabling the following fields (default setting):    

        

Title (required) Acronym (required) Duration (enabled) Topics (enabled). The call administrator must define the topics for this call in the taxonomy Call topics. This must be done as a parent term named as the id of this page (see the url when this page is saved) and all topics for the call as children terms. Keywords (enabled): Applicants can provide up to five keywords Summary (enabled) Expected impact (enabled) Expected European added value (enabled) Supplementary information (enabled) Additional field 1 (disabled) Additional field 2 (disabled) Additional field 3 (disabled) Additional field 4 (disabled) Additional field 5 (disabled)

3B Partner information (filled in by each partner) Information about the partners' contact person and organisation is automatically included from the information provided int he user's profile. The project information form is defined by the content type application-partner-info, which has pre-defined fields typically used in applications. These fields can be deactivated below. In addition there are five additional fields, which can be activated below. If additional fields are activated it is necessary to modify the content type with regard to the label of the activated fields. It is safe to modify the applicationpartner-info content type, as long as machine-name are not altered and fields are not deleted. Please note that changes to to content type will apply to all calls defined in this website. In the edit page you will find check boxes for enabling/disabling the following fields (default setting):          

Title (required) Role (enabled) Publications (enabled) Business plan (enabled) Additional field 1 (disabled) Additional field 2 (disabled) Additional field 3 (disabled) Additional field 4 (disabled) Additional field 5 (disabled) Acronym (required)

3C Partner budget (filled in by each partner)

The budget can include 1, 2 or 3 project types (e.g., RTD (Research and Technological Development). Demonstration, and Innovation). The number and definition of type are defined in the main call page. In addition a short description of each project type can be added; these description are presented to applicants in the budget form. A further option is whether project partners with in kind budgets are allowed. If so, the call administrator must create a call-funder page and a funding-scheme page in order to facilitate in kind funding in the call. The budget has pre-defined cost items. The funding agencies can disable cost items they cannot fund in their funding-scheme pages. 3D Description of work (uploaded by coordinator) DOW upload. A template can be made available in the call documents. 4 Call office The contact persons in the Call Office can be selected among website users. Contact forms will be available for applicants.

7.4 Call topics setup Module: MKB Call Administration Specification: Call topics are an important part of a call. The purpose of this tool is to provide a flexible facility to define call topics. See Call topics guide for a further description. Implementation: Call topics are implemented by the Call topic node content type with fields: Topic (title), Call id (reference to Call main page), Topic level (1,2), Topic parent (reference to a Call topic node when level=2), Topic weight (for ordering), Topic description. Call topic set up is implemented by a view with the relevant Call main page nid as parameter. A template file is used to display the topic hierarchy and to provide links to edit existing topics and to add new topics. The user is returned to this view after saving (by ?destination=). The view uses collapsable fieldsets to hide description until click on title. The topics are integrated in the Project info page for selection by the project coordinator. If the checkbox Theme funding in Call main page is checked (meaning that funding agencies can devote funding to specific topics), the Funder main page form has fields to enter funding. Call topics are shown in the Call description and are also used in Call evaluation and selection.

Tool status: OK

7.5 Call topics guide (user guide) The call themes and topics are created and edited via a link in the Call setup overview. You can add an unlimited number of themes and an unlimited number of topics within each theme. Themes and topics may include a description, which is displayed in a pop-up fashion in the call description. If Theme funding is enabled in the Call main page, applicants are only allowed to select one theme and multiple topics within this theme. Otherwise, multiple selections of themes and topics is allowed.

7.6 Call funding agency setup Module: MKB Call Administration Specification: This tool creates a relation between a call and the funding agencies participating in the call. The tool also defines the funding conditions for each funding agency. See Call setup guide for funding agencies for further description and explanation of the use. Implementation: Implementation of funding agency participation is by the Funder-main-page node content type. The fields are described in Call setup guide for funding agencies. Implementation of funding conditions is by the Funding-scheme node content type. The fields are described in Call setup guide for funding agencies. Need: A special in kind funding scheme is currently added manually, and should be better implemented. Tool status: OK with need for improvements

7.6.1 Call setup guide for funding agencies (user guide) 1 Introduction This page describes how funding agencies can register their participation in a call and provide details concerning their funding contribution, funding conditions, contact persons, call management persons and budget restrictions.

The registration to the call is done by two types of pages as described below. These pages must be created and edited by a website user representing the funding agency. The call administrator has rights to modify the pages after the have been created. The funding agency must be created as an organisation before the pages described here can be created. 2 Definition and description of the participation in the call By this page, the funding agency is connected to the call with contibuted funding and conditions. Create and edit a Call-funder-page (* required fields):     

    

Title*: Enter the name or acronym of the funding agency Call indentifier*: Select the appropriate call from the drop down list Funding agency*: Select your agency from the drop down list Country specific*: Check "Yes" if the funding scheme is only for applicants from your country (the default); otherwise check "No" Funding*: Enter your funding contribution (EUR). If the call has theme funding, ie. funding agencies can committ to individual themes, a field is available for each theme. If you commit to themes individually, enter funding as appropriate; if not, leave the fields empty. The total funding must always be entered in the funding field. Conditions short: Enter main conditions intended for the funding overview table in the call text Conditions full*: Enter all conditions intended as information to the applicants Contact persons*: Select contact persons for applicants in the check box (from your organisation, available after first save) Call managers*: Select persons to have access to manage the applications for you agency in the check box (from your organisation, available after first save) Evaluators: Enter user names of persons you give access to read and evaluate applications (use the User profile page to find user names; this is typically done after submission has closed)

3 Definition and description of funding schemes By one or more Funding-scheme pages, it is defined and described how different types of applicants can apply for funding. The budget form presented to applicants is modified accordingly. Create and edit a Funding-scheme page (* required fields):   

Title*: Provide a title, which makes it easy for applicants to recognize the type of organisation this is meant for (e.g., Public Research Organisations, SMEs, etc.) Call indentifier*: Select the appropriate call from the drop down list Funding agency*: Select your agency from the drop down list (by the title in the Call_funder_page)

   

Scheme conditions*: Provide the conditions specific to this scheme (are presented to the applicant with the budget form) Budget categories*: Check the budget categories which can be funded by this scheme (overrides all checks for cost items) Cost items*: Check the cost items within each budget category which can be funded by this scheme Requested max*: The maximum funding as a percentage of total funding, ranging from 1 to 100.

7.7 Call description page Module: MKB Call Administration Specification: The purpose is to collect all information about a call in one page to be shown to funding agencies and applicants. Implementation: The Application page is implemented by use of the contributed moduel Panels. The URL to the panel page is /call_description/[call-main-page-nid]. The panel collates into one page     

the call-main-page body, the view call-description-definitions (selected fields from call-main-page), the view call topics (the call topics) the view call-description-time (time schedule fields from call-main-page) the view call-description-funders (fields from funder-main-page)

Theme template files are used to modify the display of some of these views Tool status: OK

7.8 Call setup overview and handling Module: MKB Call Administration Specification: This tool provides access to create and edit call-main-page, call-topics, funder-main-page and funding-scheme. Implementation: A first view shows for each call in the site links to call-main-page, call-topics, call description and funder-main-page / funding-scheme. It shows also the status concerning opneing of the call. The links to funder-main-page / funding-scheme opens another view with links to funder-mainpage and related funding-schemes. Needs for improvements: Edit selected fields (e.g. open/close) in separate forms.

Tool status: OK with need for improvements

8 MKB Application Specification: The MKB Application module provide tools for authorized users for consortium building and for application development in a secure and confidential way. The consortium building facility is available for any purpose. Users can create a group, which provides a confidential room for the exchange of information amongst group members, Groups can be public (meaning that all users can see the group and apply for membership) or private (meaning that the existence of the group is hidden). The application development facility is available when there is one or more open calls. After selection of a call, the group members can be added to the consortium. The consortium members can edit project information, partner information and partner budget according to the specifications defined by the Call Administration module. Implementation: The MKB Application module is based on the contribute module Organic Groups, which provides the facilities for group membership and confidentiality. The module contains hooks for modifying the data input forms according to specifications defined by the Call Administration module. This include the use of Ajax to modify forms according to selections in sequential select boxes. Permission settings, in particular Organic Groups settings, need to be carefully checked after installation

8.1 User groups (user guide) Module: MKB Application Specification: A User Group is a closed room where users can communicate in confidence. The primary purpose of User Groups is to provide a facility for partnering in relation to ERA-NET calls, but User Groups may also be used for any other purpose users may have. See Partnering with User Groups for more information. Implementation: User groups are based on the contributed module Organic Groups, which provides the facilities for group membership and confidentiality. When the Organic Groups module is enabled, node a content type can be defined as a 'Group' or as 'Group content' belong to a 'Group'. In this tool, the 'Group' content type is named Group. Two content types, 'Post' and 'Group documents' are associated. These are providing confidential forum and file repository.

The node content type 'Group' has fields: Title, Purpose (body), Group (boolean to determine if this is an OG group), Visibility (public or private), Call id (reference to call_main-page). Organic Groups has internal roles and permissions, which must be set correctly. The default OG roles are non-member, member and administrator. Creation of a new group is permitted for authorized users. The Group content type has an extra pane with link to edit people (add new members, delete members and change member roles). The group membership is shown by use of a panel (path: iprojects/workspace/members/%node) which opens a view (iprojects ws members) The access to groups is controlled by two views, iprojects my groups (where current user is member) and iprojects public groups (where current user is not member). The menu shown with the group (the group Workspace) is created by the custom block 'iprojects ws sidebar block'. PHP code in the block body creates the menu and PHP code in visibility settings controls when the menu is displayed. Needs for improvement: Separate forms to make the group management more user friendly. Tool status: OK with need for improvements

8.1.1 Partnering with User Groups (user guide) A User Group is a closed room where users can communicate in confidence. The primary purpose of User Groups is to provide a facility for partnering in relation to ERA-NET calls, but User Groups may also be used for any other purpose users may have. The user who creates a User Group is automatically the Group Coordinator, who has the sole rights to make changes in the group, including adding/deleting group memberships and giving administration rights to other members. User Groups can be of two types related to visibility:  

Public: Other users can see the group, read a summary description and apply for membership Private: The group is invisible for other users and memberships is by invitation only

Public / Private can be reset during the life of the group. In both groups internal communication and memberships are confidential. Files uploaded to the group are secured against unauthorised access. To create a new group, use the link in the menu. A form wil open, where you can enter a title, a description, set the visibility, and optionally upload a file. If you opts for a public file, the title and the description will be displayed to other users.

8.2 Application creation and submission Module: MKB Application Specification: The purpose of this tool is online creation and submission of applications to a call. The tool is an extension of the User group tool. See How to apply for further information. Implementation: The application part of the User Group Workspace is activated when the group admistrator has selected a call in the Group node. The application uses special OG roles: Project coordinator, project partner and project editor (who can edit everything). Permissions for these roles are defined in the OG settings. The application is composed of three node content types, Project info, Partner info and Partner budget. These are described separately. A fourth component is Description of Work as a pdf file to be uploaded via the project info content type. Access to these three nodes is provided through the custom page Edit application. It displays a table with a row for the project coordinator and each project partner. The fields in the rows contains links to create Project info (only coordinator), Partner info and Partner budget for the current user (if she/he is a project partner); when these pages are created the rows has links to view for everybody; the coordinator and the project editor can edit these pages, while project partners can edit own content. Needs for improvement: Separate forms for e.g. managing consortium members, upload of Description of Work, Submission. Tool status: OK with need for improvements

8.2.1 How to apply (user guide) Applications are made within a group. Edit group and choose the open call in Call identifier. After saving you will get two new links in the menu. Use Edit application to write the application. The group administrator is automatically the project coordinator. Project partners are added by assigning this role to group members in Edit group => Group => Add people or Edit group => Group => People. A special role is the Project editor, who can be a Project partner or an ordinary Group member, and who has rights to act as the coordinator regarding editing the application. Only one person may have the project coordinator role and this person may not have the project partner role. The Project coordinator must create a Project info page and he/she and all Project partners must create a Partner info page and a Partner budget. The budget form to be filled in is modified

according to the conditions of the appropriate Funding agency and has a link to the contact person. The steps in making an application is illustrated below.

8.2.2 Project info Module: MKB Application Specification: The purpose is a description of the application as defined in the call setup. See Call setup guide for call administrator and How to apply for further information.

Implementation: Project info is implemented as Application-project-info node content type. A detailed documentation will be added when development is completed. Tool status: OK with need for improvements

8.2.3 Partner info Module: MKB Application Specification: The purpose is a description of each partner's role in the proposed project, as defined in the call setup. See Call setup guide for call administrator and How to apply for further information. Implementation: Project info is implemented as Application-partner-info node content type. A detailed documentation will be added when development is completed. Tool status: OK with need for improvements

8.2.4 Partner budget Module: MKB Application Specification: The purpose is data concerning each partner's budget in the proposed project, as defined in the call setup. See Call setup guide for call administrator and How to apply for further information. Implementation: Project info is implemented as Application-partner-budget node content type. A detailed documentation will be added when development is completed. Tool status: OK with need for improvements

8.2.5 Application document Module: MKB Application Specification: The purpose is collate the elements of the application into one document suited for evaluation of the proposal. The applicants are given warnings about any missing elements. Implementation: The application document is created by custom code.

A detailed documentation will be added when development is completed. Tool status: OK with need for improvements

9 MKB Call Evaluation Specification: The Call evaluation module defines a new Drupal entity for questionnaires. The purpose of creating a new entity is to make the setup of a new questionnaire easier. This is obtained by   

defining the fields, which are used in every questionnaire, directly in the entity definition define a database table for storing questionnaire data defining the layout of the questionnaire directly in the entity definition

With the Call evaluation module new evaluation types can be created with fields in the same way as content types are defined for the node entity. Permissions for user access is also as for the node entity. The Call evaluation entity can be used by the Views module in same way as the node entity. The Call evaluation entity is used by the Call eval module. Implementation: The Call evaluation entity is created by use of Drupal hooks. The default fields in the entity are: Evaluation_id (unique id), title, created, changed, eid (reference to evaluation type), gid (reference to group node id), uid (reference to user), recommendation (text), comment (text).

10 MKB Proposal Evaluation Specification: The MKB Proposal Evaluation provides tools for evaluation and selection of proposals submitted to a call. Implementation: The MKB Proposal Evaluation is based on the Call evaluation module.

10.1 Evaluation guidelines (user guide) The evaluation of applications (and later also selection of applications) is done online through the pages available in this section. Access Access to evaluations is granted to users who are listed as Call managers or Call evaluators in the Funder pages of the present call. Users with the Call admin role have also access. Call evaluators may be used when a funding agency wishes to include an expert. Pages

The pages in evaluation suite have similar layout (one line per application) but differs in content from the applications and in which applications being shown. There are usually several links in each line: The acronym links to the application page (all information entered online by project coordinator and partners); Coordinator links to the coordinators profile (including a contact form); DOW links to Description of Work; Eval links to an evalution form. All applications page This page shows all applications associated with the present call, including applications that were not submitted. The main purpose is to find an application in response to a request from an applicant. Formality check page There is a link to the formality check form and relevant content from applications. Only submitted applications are shown. The formality check is done by the call office. Eligibility evaluation page Eligibility evaluations are done by the funding agencies, who can find a link to the evaluation form. Only submitted applications passing the formality check are shown. The page is only showing applications, which have a partner requesting funding from the funding agency the current user is representing (call manage or call evaluator in the appropriate funder page). Content evaluation page Content evaluations of pre-proposals are done by the funding agencies, who can find a link to the evaluation form. Only submitted applications passing the formality check are shown. The page is only showing applications, which have a partner requesting funding from the funding agency the current user is representing (call manage or call evaluator in the appropriate funder page). Evaluation overview page The purpose is provide information about the outcome of all evaluations. The column evaluations links to a page containing all evaluations performed.

10.2 Proposal evaluation Module: MKB Proposal Evaluation

Specification: The purpose of this tool is to facilitate the evaluation of proposals in a call in a cost-efficient manner. The tool is constructed in according with the usual procedures for the evaluation of a transnational call with many participating funding agencies. The basic idea of the tool is that all activities related to proposal evaluations can be done directly in the website without any needs for transferring documents by for example emails. This saves much work and safeguards against errors in the communication with the funding agencies. The way proposal evaluation is conducted and how this tool support the work is described in the Evaluation guidelines. Implementation: This tool is under develoment. Details concerning the implementation will be added when the development is completed. Tool status: OK with need for improvements

10.3 Evaluation status and overview Module: MKB Proposal Evaluation Specification: The purpose of this tool is to provide an overview of the current status of the evaluation process. The tool includes a page for each evaluation type (see Evaluation guidelines). Each page shows proposals as rows and funding agencies as columns in a table. The table cells have content when a proposal row has a partner requesting funding from a funding agency column. A colour mark-up shows whether the evaluation is pending (grey) or the evaluation has resulted in approval (green), approval with conditions (yellow) or approval denied (red). A click on the row opens a new page showing all evaluations regarding the proposal. Implementation: This tool is under development. Details concerning the implementation will be added when the development is completed. Tool status: OK with need for improvements

10.4 Proposal selection Module: MKB Proposal Evaluation Specification: The purpose of this tool is to support the selection of proposals for invitation to submit a full proposal or for funding.

A critical issue of selecting proposals in a virtual common pot transnational call is to match the funding of projects to the funding available from each funding agencies. This tool support the selection in this respect by calculating and displaying the consequences of possible selections. The selection page shows proposals as rows and funding agencies as columns in a table. The table cells contain requested funding when a proposal row has a partner requesting funding from a funding agency column. Three additional rows at the top show per funding agency the available funding and the sum of requested funding and the deficit funding (available less sum of requested). Each row has a checkbox for selection. When checkboxes are checked or unchecked, the numbers in the Requested funding and Deficit funding are recalculated. Negative numbers are shown in red. Selection pages are shown by call theme, when the call includes theme funding. Call administrators can save the selection for later use. Implementation: This tool is under development. Details concerning the implementation will be added when the development is completed. Tool status: OK with need for improvements