Euphorie – Euphorie Risk Assessment tool¶

Step 1: Identification¶

All the hazards on one list: draw up a list of all the hazards in your company. You can draw this list up yourself. (Or you can ask an expert to conduct your RA.)

Your RA must answer the following six questions:

• Have there been accidents in the past in my company?
• What could currently go wrong in my company, causing accidents or absenteeism?
• How great is the chance of this happening?
• How do I limit a risk? Or limit the damage if something does go wrong?
• What precautions are necessary? And how do I implement these?
• How do I ensure that the precautions continue to work?

Step 2: Evaluation¶

The result is a summary of the bottlenecks in your company. For each bottleneck you will evaluate the magnitude of the hazards: you define the risks.

Step 3: Action Plan¶

You indicate how you will solve the bottlenecks. Compare all the risks on the list and place them in the correct order. Which risks are the most threatening? Are there situations in your company that are not legally permissible? Which risks could cause damage to your employees, equipment or the production process? Which risks would your employees like you to tackle? Which modifications are technically feasible and – also important – how much can you invest?

Next step: compare who does what and when? You now have a list of ‘Things to Do’. The third step is: set time periods for tackling the risks in your company. Who will start working on which risk? And when will you be satisfied? What will it provide? In short, a plan of action. This allows you to resolve the risks one at a time, preferably at the source. Perhaps you can solve several problems at once.

Step 4: Report - Keep it up-to-date¶

Done? Then you are on your way! That sounds odd. Once you are done that means you are finished, right? This does not apply to the RA. You will implement the Plan. You will discuss the progress with your employees every year. If you make changes in the company, you must change the RA too. New machines, new working method, reorganisation? Changes in your company mean a modified RA. So, if you have finished your (first) RA, you have only just started. You have started to improve the health and safety standards in your company. And improvements are never finished!

1.1 Keep in mind your end-user¶

It is important to keep in mind your end-user: the micro and small sized enterprise (employer and worker(s)) and the structure of the risk assessment tool should be as relevant as possible to the daily activities of the enterprises; the end-user thinks and acts in terms of his own business processes. Often, the expert’s way of thinking differs from the practice of the end-user. The latter thinks in terms of his own work processes and uses his own language. Some examples:

• the expert thinks of physical workload; the end-user of physical work
• the expert thinks of the thermal environment; the end-user of working in the heat/in the cold
• the expert thinks of safety and creates a module containing everything in that area; the end-user may think of opening and closing a shop, for example, and what that involves, or dealing with aggressive customers and what to do about them.

1.2 Use easy language¶

Structuring the content of the risk assessment tool so that it is in line with the way the average end-user thinks and acts makes the content recognisable, and it makes it easier to carry out an action plan to tackle the risks with feasible measures.

Another decisive aspect is the language used. The language should be easy to understand with no need for interpretation, referring to things by names that are familiar and usual to enterprises.

Short sentences (at best no longer than ten words) and clear everyday language that can be easily read by the layman will prevent the end-user from developing an aversion, and enable him to draw up an assessment and use the OiRA tool properly.

At the beginning of the tool you will be given the chance to write a short introductory text sending a positive and encouraging message regarding:

• the importance of risk assessment
• the fact that risk assessment is not necessarily complicated (the idea is to contribute to demystify risk assessment)
• the fact that the tool has especially been conceived to meet the needs of the enterprises in the sector

It is important that the text is not too long; otherwise it could discourage the end-user from using the tool.

3.1 Structure the content hierarchically¶

Before you start creating an OiRA tool, we recommend considering the number of matters which you want to address. Thorough consideration of the structure will pay dividends later on, so classify the subjects in a way that is relevant to end-users.

The system offers a way to group topics, subtopics and types of risks together. The main goal of this grouping is to make it easier/more logical for the end-user to complete the risk assessment tool. Your risk assessment tool will therefore consist of:

MODULES = subjects (locations, activities, …)

Example:

Module 1: Hair Shampooing (hairdresser sector)

SUB-MODULES (not compulsory) = sub-subjects

Example:

Sub-module 1: Working posture

Sub-module 2: Contact with water and cosmetic products

RISKS = statements about a situation which is in order

Example:

1.1 The shampoo station is adjustable

2.1 Suitable protective equipment, such as disposable safety gloves, is purchased

SOLUTIONS = preventive measures to solve the problem recommended by the expert

Example:

1.1 Taking regular breaks to be able to recover from physical work

2.1 Using dust-free products

The system also offers the possibility to:

• skip one/a whole set of modules in case the content does not apply to the company activity
• repeat some modules in the case of enterprises having multiple locations.

3.2 Think about the risk as an affirmative statement¶

Once you have decided about the main structure of the risk assessment tool you can start to identify and explain the various risks.

The system works with affirmative statements; that is, it states whether a situation is ‘in order’ (the goal to be attained) or ‘not in order’;

Note

Example: Good lighting is present.

The end-user answer is either a clear ‘yes’ or ‘no’. If the end-user answers with NO (= the situation is not in order), then the problem is automatically included in the action plan step and the end-user will have to propose a measure to tackle the risk.

3.3 Consider the different types of risks¶

You can choose from 3 types of risks:

• priority risk: refers to a risk considered by the sector to be among the high risks in the sector.

  Note

  Example: Working at height in the construction sector: the scaffold is erected on a firm foundation

• risk: refers to existing risks at the workplace or linked to the work carried out.

  Note

  Example: All office chairs are adjustable

To identify and evaluate the above two types of risk it is often necessary to examine the workplace (to walk around the workplace and look at what could cause harm; consult workers, …).

• policy: refers to agreements, procedures, and management decisions regarding OSH issues.

  Note

  Example: Manufacturers are regularly asked about alternative safe products

These policy statements can be answered from behind a desk (no need to examine the workplace).

3.4 Pre-set evaluation for the risk¶

For each “risk” type you can choose from 2 evaluation methods:

• Estimated: by selecting from high, medium or low.
• Calculated: by evaluating the probability, frequency and severity separately. The OiRA tool will then automatically calculate the priority.

End-users will not have to evaluate the following risks in the “Evaluation” step:

• Priority risks (considered by default as “high priority” and displayed as “high” in the action plan)
• Policy (strictly speaking this is not a risk).

3.5 Propose solutions¶

The sector is generally well-informed of the risks that are most likely to lead to occupational accidents and diseases. In order to help the end-user to find solutions to these risks, you can include the solutions recommended by the sector/experts. While working on the action plan, the end-user will have the possibility to select the solutions and rework them (modify the text) according to the situation that prevails in their enterprise.

Why evaluate?¶

Once you have answered all the questions, you can evaluate. That means that you will receive a summary of all the bottlenecks in your company. Please bear in mind that: one bottleneck may be more severe than another. Therefore, the magnitude of the risk is determined here.

High, medium and low¶

The step Evaluate is performed by answering three questions for each bottleneck. Your three answers will be used in a calculation, based on which the programme determines whether the risk is high, medium or low. In the next step, ‘Action Plan’, you will find more information about the outcome of this calculation.

What are bottlenecks?¶

Bottlenecks are questions in the phase Identify that were answered with a ‘No’. These questions are flagged again here. However, it is possible that you answered ‘No’ to certain questions but these questions do not pop up in the phase “Evaluation”. There are two possible reasons for this.

• Either: a certain bottleneck is known to cause high risks in your sector (for example, in the case of occupational diseases). In that case the bottleneck will only be listed in the Action Plan, with the warning ‘Risk: high’.
• Or: this is a bottleneck for which the risk cannot be determined based on these three questions (for example for the bottleneck: absence of policy). In that case the bottleneck will also only be listed in the Action Plan, with the warning ‘Risk: not defined’.

You will assign priorities to these bottlenecks yourself in the Action Plan.

How can you check that all bottlenecks have been evaluated?¶

They will appear in the Action Plan with the warning ‘Risk: not defined’.

What if there are no bottlenecks?¶

That is possible. This is good as it means there are no health or safety risks in your company. You can simply skip the steps ‘Evaluation’ and ‘Action Plan’.

How to evaluate?¶

The step Evaluation is performed by answering the following three questions for each bottleneck:

• How often are people exposed to this risk? You can select: ‘Never’, ‘Almost never’, ‘Regularly’ or ‘Constantly’.
• What is the chance of this risk occurring? You can select: ‘Small’, ‘Medium’ or ‘Very big’.
• Which is the severity of the damage? You can select: ‘Weak severity’, ‘Significant severity’ or ‘High (very high) severity’.

An example¶

There are hazardous substances in a storeroom. The employees enter this room briefly several times per week. The storage has been fitted with an extractor. The chance of hazardous substances being released (for example by leakage or vaporisation) is estimated to be medium (there are various substances in different types of packaging). The exposure is defined as regular (the employees enter the room several times per week). And the severity is significant (the substances are irritating, but not toxic).

Suggestion!¶

Use your common sense when filling in the forms. Do not pay any attention to all sorts of other possible and conceivable effects.

Why set up an Action Plan?¶

You have defined the bottlenecks in your company. You have determined the level of risk for each bottleneck. The question that remains is: what can you do about it? In other words: what measures can you implement to remove these bottlenecks?

First priority...¶

The programme runs through the bottlenecks one at a time. First you must set the priority: how important do you think it is that this bottleneck is tackled quickly? The programme automatically assigns a high priority to a bottleneck with a high risk et cetera. You can modify the priorities yourself.

...then the measures¶

Now there are two options for each bottleneck: you select one of the standard measures suggested by the programme. These are measures that are normally used in your sector. Some sectors list several standard measures, others do not. Or you decide on the best measures by yourself.

How to set the priority?¶

You select a high, medium or low priority for the bottleneck. You leave the priority as set by the programme, or you modify it.

How to select measures?¶

Sometimes one or more standard measures are suggested. You can select one or more of these measures, or you can modify the text of the measure yourself! Or you can add your own measures. If you have added at the phase Identify your own notes, you can see them at the page Action Plan.

Fill in

• Prevention plan: the tasks that have to be carried out.
• Requirements: the knowledge and experience needed to carry out the tasks.
• Responsibility: the person in charge of the implementation.
• Budget: the costs that will have to be incurred.
• The start date and end date.

Report¶

Why report and print? You have now completed your RA. You can print copies for yourself and your employees. Please ensure that you always have a printed version of your RA available. This is useful when a Labour Inspectorate team visits. They will ask to see this document. (This can vary in each country).

How to modify the RA?¶

Once you have saved the report, you can modify it using your word processor (for example, Microsoft Word or Windows WordPad). Or restart the digital RA, and modify.

Why add additional information to the report?¶

If you have saved the report you can add additional information like the name of your company, person(s) who carried out the examination, date of the RA. This additional information can be useful for supervisory authorities.

Final words¶

Keep it safe! Store your RA safely. You have put a lot of effort into it. You can close the RA by clicking on the button ‘Log out RA’ on the top right. This will automatically save the RA and close it. Your data have been stored. Once the save has been completed you will return to the screen ‘Select RA’. Here you can open another (existing) or new RA if necessary. However, you will probably just want to close the programme.

What will happen next?¶

You will start to implement your Action Plan. Conduct an RA regularly. Especially if there are any changes in your company. For example, when you buy a new machine, before and after reconstruction or moving. A rule of thumb is once every four to five years. You do not have to start the RA from scratch every time.

Requesting a Login Account¶

To request a Login Account, send an email to OiRA Support (oira@osha.europa.eu) with the following information:

• The name of your sector (as known by the general public).
• Your fore- and surname.
• Your email address.
• Your preferred password for the OiRA tools generator (with a minimum of 5 characters, the user name will be confirmed by the EU-OSHA OiRA Team)
• The name of your sector (as known by the general public) and NACE code

In addition, clearly state in your email that you are requesting an account for the OiRA Tool, and explain why.

We will use this information to create your sector and will link this your Login Account.

Once your account has been created you will receive an email, at the provided address, containing the login information. Please note: Both your user name and password are case sensitive!

In addition to the login information you will receive an agreement, which determines the Terms and Conditions for using the OiRA tools generator (such as: full public access, responsibility to keep the sector’s OiRA tool up-to-date). The agreement has to be signed and returned within three weeks.

Logging in¶

Preferred web browsers are: Mozilla Firefox version 3.6, or any later version, or Google Chrome (both are available to download for free). Alternatively Microsoft Internet Explorer version 7, or any later version.

You start on: http://admin.oiraproject.eu/

And login with your User Name and Password. Did you forget your password? Check the confirmation email or click at the bottom of the page on ‘request a password reset’. Then add your user name and click on ‘Send’.

The password will be sent to the email address you provided.

If your login has been successful, a green bar with a confirmation will appear.

After logging in, you will be brought to a page with an overview of the Risk Assessment Tool for your sector. Here you can: click on a tool to amend it, or start a new OiRA tool by clicking on –> ‘Add New OiRA tool’ at the bottom of the page.

Logging out¶

Don’t forget to logout when you stop working in the OiRA tools generator. This is done with the button at the top right: click on your login name and select ‘Logout’. After logging out successfully, you will be brought back to the login screen where you will see the notification ‘Logout successful’.

Creating a new OiRA tool¶

After clicking on ‘Add New OiRA tool’ you will be brought to the page below:

When creating a new OiRA tool you can choose from the following three options:

1. Start with a blank OiRA tool
2. Base my OiRA tool on an existing OiRA tool of my organisation.
3. Base my OiRA tool on an existing OiRA tool of another organisation.

Ad 1) Starting with a blank OiRA tool is particularly useful when you already have a paper-based OiRA tool for your organisation and would like to transfer this to the digital system.

Ad 2) This option is recommended when you are: (a) planning to revise the contents of your OiRA tool and/or (b) would like to add new modules. This option is also useful for organisations which manage multiple (sector-)OiRA tools, of which the base modules are applicable to other OiRA tools.

Note

When dealing with minor amendments, e.g. typos, it would be best to implement these in the existing OiRA tool and simply republish it.

Note

When the risks won’t be amended, but, for instance, only the clarifications you can simply create a new version (a copy) of the existing OiRA tool.

Ad 3) You can decide which existing OiRA tool is most suitable for your sector. You can copy and modify it, and thus avoid having to create one from scratch. You have to determine the amendments for your own sector. For example, the butcher could copy and modify the OiRA tool of the fish retailer.

In addition to the OiRA tool of a specific sector, you can also use the so-called generic checklist as a starting point. It’s slightly more general, but it does contain all the relevant aspects for an OiRA tool. The base-OiRA tool has been an inspiration for many sector-specific Digital OiRA tools and is considered to be a suitable starting point.

Note

THE BASE-OiRA TOOL WILL BE AVAILABLE IN THE FUTURE

The base-OiRA tool provides solutions at module level, which you can copy and modify if needed. It doesn’t provide solutions at a risk level. In addition, most modules of the base-OiRA tool start with a ‘filter question’, which determines whether the situation concerned will be applicable to the end-user.

Note

After you’ve copied an existing OiRA tool, any changes made to the ‘source-OiRA tool’ will not automatically be reflected in your own OiRA tool. When, for example, the butcher has copied the OiRA tool of the fish retailer and the fish retailer implements changes in their OiRA tool afterwards, these changes will not appear in the OiRA tool of the butcher.

If you would like to copy the OiRA tool of another sector as a starting point, you need to first select the country in the drop-down menu and subsequently the sector of your choice.

When this sector provides more than one version, you can view these versions and select one.

Give the OiRA tool a name (title). This name will be shown to the end-user in the overview. Tip: The overview is in alphabetical order, so make sure to choose a name based on your sector, for example ‘New Risk Assessment 2010’.

Then click on ‘Save Changes’ at the bottom of the page.

Your OiRA tool will then be created. Please note that this can take a while if you’ve chosen to use a copy of an existing OiRA tool.

In case of a new (blank) OiRA tool you will see a screen as shown below:

What are profile questions?¶

It is possible to skip or repeat modules in case they do not apply to the activity of the end user (optional profile question) or they apply to multiple objects (repeatable profile question).

Such questions are asked before starting the risk identification and evaluation. If the end-user does not tick the optional profile questions or does not add multiple objects, the related modules and risks are not displayed.

When determining which main modules and potential submodules should be created, it’s important to consider the option of using a so-called profile, a profile question is asked before one starts the OiRA tool. It is used to determine the main sections, activities, etc. of the company.

For example, for the bakery owner:

• Do you have a store?
• Do you have a stall at the market?
• Do you own a sales truck?

When the end-user answers with ‘Yes’, the submodules/risks are activated. The answer ‘No’ does not activate the submodules/risks. Imagine this to be the same as if you would include or exclude a certain part of a checklist, because it applies or does not apply to your situation.

Apart from this, the end-user will be required to complete a certain number of obligatory modules.

If you use a repeatable profile question, it will be possible for the end-user to indicate ownership of more than one object (e.g. multiple stores, stalls, sales trucks). Instead of putting a question, you would ask the user to name each object (“Name your bakery locations”) and the user will name the objects with names relevant to him (e.g. city center bakery, bakery head quarters, bakery city park). Through this, the modules associated with this repeatable profile will get repeated in the tool - once for each object. Imagine this to be the same as if you would make paper copies of a certain part of a checklist, because it needs to be filled for each location’s characteristics.

Using a profile is particularly useful in sectors, where it’s probable that a substantial number of modules with risks aren’t relevant to all companies. If you expect that most companies will complete practically all modules, creating a profile will be unnecessary unless you would like to have the possibility of completing part of the modules multiple times (as in the example with the multiple stores).

When someone replies with ‘No’ to an optional profile question, all subsequent risks will be nullified (when you don’t own a market stall, these risks won’t be shown). If someone replies with ‘Yes’, then all the applicable risks will be shown.

This module can thus be further completed as a normal module.

Adding profile questions¶

You can create profile questions as follows: click on the top level of the OiRA tool (top link in the navigation tree on the left-hand side) and in the grey bar underneath the title you will find the button ‘Add Profile Question’.

You will see the following page:

Here you can add:

• Title: the title of this module, for instance ‘Working Circumstances’, ‘Acquisition’ or ‘Physical Strain’, etc. The end-user will see this title at the top of the page for the duration of answering this module’s risks. Don’t put a full stop after the title. A number isn’t needed either, the module will be numbered automatically.

• Description: a short description of this module.

• Type:

  • optional: when you would like this module to start with a filter question.
  • repeatable: when you would like to offer this module multiple times (e.g. per object).

The profile question acts as a module. You now have to add submodules and risks to it. You can do that by clicking the “Add Risk” or the “Add Module” button on the profile question object.

You can modify the modules at a later stage by using the ‘Edit’ button. With the Action menu (top right) you can cut, copy and delete modules and by dragging them (up or down) you can change their sequence.

Add Modules¶

You can create modules as follows: click on the top level of the OiRA tool (top link in the navigation tree on the left-hand side) and in the grey bar underneath the title you will find the button ‘Add Module’.

For a module you will see the following page:

Here you can add:

Title:

The title of this module, for instance ‘Storage room’, ‘Working at height’ or ‘Physical Work’, etc. The end-user will see this title at the top of the page for the duration of answering this module’s risks. Don’t put a full stop after the title. A number isn’t needed either, the module will be numbered automatically. Keep it short and simple. Use everyday language and make sure end-user will immediately understand it.

Description:

Provide a short general description of the content of the module. You can create links to useful external pages providing additional relevant information.

This module is optional:

Choose if you want to force the end-user to go through this module and the related risks or if the module can be skipped, as not every company in the sector has the same activities.

Question:

If you have decided to make the module optional, you have to enter a question to ask the end-user if the activity is carried out in the enterprise. The answer has to be YES or NO. If NO is answered, the end-user will skip the module.

Image:

You can add an image.

Overview of solution:

At this level (module), in most of the cases only generic/orientative solutions can be provided. Here it is important to stress the importance of avoiding the risk, substituting the dangerous by the non-(or less) dangerous, combating risk at source. The solution can underline or focus on different aspects: technical and/or organisational, ... This text will appear in the action plan step. This overview of solution at module level is compatible/complementary with the measure(s) proposed at risk level.

Click on ‘Save’ at the bottom of the screen.

To add more main modules, again click on the top link in the navigation tree and select the button ‘New Module’.

To add a submodule to the current module, click on the module to which you want to add a submodule and select ‘Add Submodule’.

You can modify the modules at a later stage by using the ‘Edit’ button. With the Action menu (top right) you can cut, copy and delete modules and by dragging them (up or down) you can change their sequence.

Add Risks¶

A risk is always placed inside a module or submodule. You first select the required module on the left-hand side. Don’t add risks in the top level of the OiRA tool, only in the modules or submodules underneath.

Open the required module and click on ‘Add Risk’ in the grey bar underneath the title.

You will then see the screen below:

Statement:

Write a short positive statement about a possible risk For example: ‘There are no obstacles or trailing cables on the floors’. Put a full stop after the statement. For more information on how to properly formulate risk statements, see below.

Problem description:

This is the inverse of the statement = a negative statement This field is mandatory as the negative statement will appear in the risk evaluation and action plan steps (if the end-user answers NO to the positive statement). For example: ‘There are obstacles or trailing cables on the floors’.

Description:

Describe the risk and provide the end-user with any relevant information. You can create links to useful external pages providing additional relevant information. For example, put a clarification/explanation of the exact meaning of ‘timely inspection’

Legal and Policy References:

Provide relevant legal information related to the risk/topic/issue. You can create links to useful external pages providing additional relevant information.

Identification Phase:

If checked, this offers to the user the possibility to answer with ‘Not Applicable’ in addition to the usual Yes/No in the Identification phase.

Evaluation Phase:

Specify the risk type and the evaluation method. For more information on risk types and evaluation, see below.

Main Image and Secondary Images:

On the risk page you can add images. One Main image, which will appear on a prominent position and up to three secondary images, which will appear below. You should use these images to help describe the risk situation and eventually also the correct situation as a contrast.

You will have to upload these images yourself. Make sure that the images are clear and legible, not too large in surface size (maximum 300 x 300 pixels on the screen) and file size (maximum 100 kB). Give the image a clear file name, without spaces (for example: Danger_logo.jpg). When the image is ready to upload, you select it from your computer by using the ‘Browse’ button. The location and file name will appear in the field.

This function will only allow you to upload images with a ‘gif’ or ‘jpeg’ extension. Any other files will first have to be placed onto a website and can be linked to from the text.

After uploading the image, click on ‘Save’ (at the bottom of the page).

You can modify the risks at a later stage by using the ‘Edit’ button. With the Action menu (top right) you can cut, copy and delete modules and by dragging them (up or down) you can change the sequence. You should do this before the OiRA tool has been published.

Solutions / measures¶

One of the goals of this tool is to help users with information on how to solve problems they encounter during the process. This is done by providing typical solutions to general problem areas (by module) or specific problems (by risk). Therefore you can add such solution information in a module and attach it to a risk.

It is most comfortable for the end-user if you provide a solution for each risk, because then the user will be able to pick solutions with a click to prepopulate the action plan form.

In some cases it might however be not possible to provide that specific solution information. Then you should at least specify an ‘Overview of solution’ on the module. This text should contain an approach for the user how to tackle the risks described in that module in a general way. This information will be displayed in the Action plan before each specific risk is handled.

You can add the “Overview of solution” in the module edit form.

• When you don’t work with solutions per risk, it is important that you give an “Overview of solution”
• If you do work with solutions per risk, it is optional

Solutions/measures - per risk¶

In addition to an ‘Overview of solution’ per module level, it is recommended that you create solutions for all risks. You can do this as follows:

A solution is related to a concrete risk. First select the risk in the correct module and then click on ‘Add Measure’ in the grey bar.

You will see a new screen with blank fields:

Description:

Start with words which reflect the core message of the measure, for example: ‘Information and Instruction’, and then offer the rest of the solution. This text helps to get the end-user started and explains the possibilities. In this field you can format the text and include links to documents or websites. If you would like to include an image, you can do this at the risk itself. This description text will not be incorporated into the Plan of Action.

General approach (to eliminate or reduce the risk):

Describe what is your general approach to eliminate or (if the risk is not avoidable) reduce the risk. This text will be incorporated into the Plan of Action. For example: ‘Ensure the correct means of Personal Protection are used, according to...’. If the end-user selects this measure it will be copied over to the Plan of Action.

Specific action(s) required to implement this approach:

Describe the specific action(s) required to implement this approach (to eliminate or to reduce the risk). For example: ‘Purchase a new machine which produces less noise/dust’.

Level of expertise and/or requirements needed:

Describe the level of expertise needed to implement the measure, for instance “common sense (no OSH knowledge required)”, “no specific OSH expertise, but minimum OSH knowledge or training and/or consultation of OSH guidance required”, or “OSH expert”. You can also describe here any other additional requirement (if any). For example: Budgeting, Rraining for Prevention/Safety staff, incorporating this subject in team meetings, etc.

If the end-user selects this measure it will be copied over to the Action plan. End users can also rework the text.

If the end-user selects this measure it will be copied over to the Plan of Action.

Click on ‘Save’ at the bottom of the page.

You can add more standard measures for each risk if needed, by clicking on the button ‘Add Measure’.

Checking your OiRA tool¶

When all the work has been done, i.e. the structure, contents and profile have been completed, you can view your OiRA tool (prior to making it public).

This is done by clicking ‘Preview’ in the ‘Versions drawer’. The online program with your (unpublished) OiRA tool will be shown in a new window.

To view the preview you will have to register to the OiRA tool front-end, the end-user will have to undertake the same action when starting the OiRA tool. After registering, you can complete the OiRA tool as an end-user.

Tip

check as many boxes as possible in the profile, answer the filter questions with ‘Yes’ and the risks with ‘No’. This way you will view all risks and possibilities.

When you discover faults in the preview you can amend these in the OiRA tools generator. Access the Preview again to check your modifications.

Note

The preview is stored in a separate place on the server, it won’t be viewable to the end-users until you publish the OiRA tool.

Implementing your company logo and design into the OiRA tool(s)¶

Straight after logging into the OiRA tools generator, you go to the ‘Settings’ menu (top right).

You will see the following screen:

Here you can select the two most important colours: a main colour and a supporting colour. You can do this by clicking on the white circle (don’t let go of it!) and dragging this to the colour of your choice. You will immediately see the effect on the logo at the top.

You can also enter the colour code into the Hex-field underneath.

Note

It’s recommended to let a designer determine the colours, who can ensure amongst other things that:

• Appearance is clearly identifiable with the sector.
• Legibility of the text (the OiRA tool end-user will often have to read large portions of text).
• Forms of colour blindness (at 10% of the male population) are taken into account.

The design changes are made to the sector, so they will apply to all OiRA tools created within that sector.

Ready? Publish!¶

Once you’ve successfully completed all steps it’s time to publish your OiRA tool.

When you click on ‘Publish’, the OiRA tool will be made available.

Note

It can take some time to perform this action.

A confirmation will appear in a green bar:

From now on, the public can view and complete your OiRA tool. If it’s a new OiRA tool we would like to be notified (oira@osha.europa.eu), and will put the link onto our site: www.oiraproject.eu. You don’t have to notify us when you’ve updated the OiRA tool.

Example¶

<sector xmlns="http://xml.simplon.biz/euphorie/survey/1.0">
  <title>Information technology</title>
  <account login="coders" password="s3cr3t" />
  <contact>
    <name>Team lead</name>
    <email>leader@example.com</email>
  </contact>
  <survey>
    ...
  </survey>
</sector>

Example¶

<survey>
  <title>Software development</title>
  <classification-code>A.1.2.3</classification-code>
  <language>en</language>
  <evaluation-optional>true</evaluation-optional>
  <profile-question>
    ...
  </profile-question>
  <module>
    ...
  </module>
  <module>
    ...
  </module>
</survey>

Example¶

<profile-question>
  <title>Mobile access</title>
  <question>Do your employees work remotely?</question>
  <description>&lt;p&gt;Working out of the office can introduce many
    new risks that may not be under your direct control.&lt;/p&gt;
  </description>
  <module>
     ...
  </module>
  <module>
     ...
  </module>
</profile-question>

Example¶

<module optional="yes">
  <title>Laptops</title>
  <question>Do your employees use laptops?</question>
  <description>
    &lt;p&gt;Laptops are very common in the modern workplace.&lt;/p&gt;
  </description>
  <risk>
    ...
  </risk>
  <risk>
    ...
  </risk>
</module>

Example¶

<risk type="risk">
  <title>Are your desks at the right height?</title>
  <problem-description>
    &lt;p&gt;Not all desks have the correct height.&lt;/p&gt;
  </problem-description>
  <description>
    &lt;p&gt;The right height is important to prevent back problems.&lt;/p&gt;
  </description>
  <evaluation-method default-probability="small" default-frequency="regular"
     default-effect="high">calculated</evaluation-method>
  <solutions>
    <solution> ... </solution>
  </solutions>
</risk>

Example¶

<solution>
  <description>Use height-adjustable desks</description>
  <action-plan>Order height-adjustable desks for desk workers.</action-plan>
</solution>

Example¶

<image content-type="image/gif">R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAEALAAAAAABAAEAAAIBTAA7</image>

Create new user¶

Using this call you can create a new user. The user information must be supplied in a JSON dictionary:

{
     "login": "jane@example.com",
     "password": "john",
}

The login key is required. Specifying the password is optional: if a password is given the user can login with that password on the Euphorie client directly. If no password is given access is only possible with the authentication token returned by this call.

The response is a JSON dictionary with details for the newly created account:

{
     "token": "e1490672-4015-4572-a036-ba53c45e9509",
     "id": 17,
     "login": "jane@example.com",
     "email": "jane@example.com",
}

If the login is not a valid email address or another account with the same email address already exists an error is returned.

User authentication¶

In order to authenticate you must submit a JSON object with two keys:

• login: the users login (this should be an email address)
• password: the users password

If authentication failed an error response is returned with status code 403. If authentication is succesful a JSON response is returned with an authentication token and a list of existing sessions:

{
    "token": "e1490672-4015-4572-a036-ba53c45e9509",
    "id": 17,
    "login": "jane@example.com",
    "email": "jane@example.com",
    "sessions": [
        {
                "id": 1926,
                "title": "Hoveniers en Groenvoorzieners",
                "created": "2010-09-27T11:35:00Z",
                "modified": "2012-04-23T10:29:13Z",
        },
        {
                "id": 23945,
                "title": "Vlakglas",
                "created": "2010-09-27T11:35:00Z",
                "modified": "2012-04-23T10:29:13Z",
        },
    ],
}

The token should be supplied in an X-Euphorie-Token HTTP header for all requests that require authentication.

User details¶

This will return information about the user, including all known sessions. A user can only request information for his own account: any attempt to request information on another user will result in a HTTP 403 error response.

{
    "id": 17,
    "login": "jane@example.com",
    "email": "jane@example.com",
    "sessions": [
        {
                "id": 1926,
                "title": "Hoveniers en Groenvoorzieners",
                "created": "2010-09-27T11:35:00Z",
                "modified": "2012-04-23T10:29:13Z",
        },
        {
                "id": 23945,
                "title": "Vlakglas",
                "modified": "2011-12-06T15:15:24Z",
        },
    ],

This token should be supplied in an X-Euphorie-Token HTTP header for all requests that require authentication.

Update user¶

This call allows updating the user information. The only key that can be updated is login. Currently the login name and email address are defined to be the same, so updating the login will also update the users email address.

{
    "login": "jane@example.com",
    "password": "bruce",
}

The response is identical to the user details query.

List countries¶

Example response:

{
    "countries": [
        {
                "id": "nl",
                "title": "The Netherlands",
                "type": "eu-member",
        },
        {
                "id": "be",
                "title": "Belgium",
                "type": "eu-member",
        },
}

The possible country types are:

• eu-member: country is a full EU member state
• candidate-eu: candidate member of the EU
• potential-candidate-eu: potentital candidate member of the EU
• efta: member of the European Free Trade Association
• region: generic region, not an individual country

Note that even though a country has a title frontends are encouraged to use use locale-specific name for the country. This can be based on the id, which is guaranteed to be a valid country code.

List sectors¶

Example response:

{
    "id": "nl",
    "title": "The Netherlands",
    "type": "eu-member",
    "sectors": [
        {
                "id": "bovag",
                "title": "BOVAG",
        },
        {
                "id": "bovag",
                "title": "BOVAG",
        },
}

Example detail response:

{
    "id": "nl",
    "title": "The Netherlands",
    "type": "eu-member",
    "sectors": [
        {
                "id": "stigas",
                "title": "STIGAS",
                "surveys": [
                    {
                            "id": "akkerbouw-en-vollegrondsgroenteteelt",
                            "title": "Akkerbouw en vollegrondsgroenteteelt",
                            "language": "nl",
                    },
                    {
                            "id": "bos-en-natuur",
                            "title": "Bos en natuur",
                            "language": "nl",
                    }
                    ,
                ],
        },
        {
                "id": "dierenartsen",
                "title": "Dierenartsen",
                "surveys": [
                    {
                            "id": "dierenartsen",
                            "title": "Dierenartsen",
                            "language": "nl",
                    },
                ],
        },
}

List sector details¶

Example response:

{
        "id": "stigas",
        "title": "STIGAS",
        "surveys": [
                {
                        "id": "nl/akkerbouw-en-vollegrondsgroenteteelt",
                        "title": "Akkerbouw en vollegrondsgroenteteelt",
                        "language": "nl",
                },
                {
                         "id": "nl/bos-en-natuur",
                         "title": "Bos en natuur",
                         "language": "nl",
                 },
        ],
}

Standard response components¶

All responses to API calls involving a survey session follow a standard structure. They include the following keys:

• phase: the current survey phase. This will be one of identification,
• type: an indicator of the response type. This will be one of survey, profile, module, risk, update or error.
• title: the title for the current context. Depending on the context this will be the title of the survey, module or the risk.
• previous-step: a URL pointing to the API location of the previous logical step. If the end start of the survey is reached this key will not be present.
• next-step: a URL pointing to the API location of the next logical step. If the end of the survey is reached this key will not be present.

If a survey was updated since the last interaction of the user with the survey and the structure of the survey has changed a survey-update response is generated. The response type can be identified by type set to update.

{
        "type": "update",
        "confirm-profile": true,
        "next-step": "http://api.instrumenten.rie.nl/users/13/sessions/193714/update",
}

Context menu¶

When looking at a module or risk you can ask for a context menu information to be included in the response by adding a menu parameter to the query string. The parameter does not need to have a value.

The menu information is provided in a menu key and formatted as a nested dictionary reflecting the elements of a navigation tree. Each element in the tree is an object with the following keys:

• type: node type (one of risk or module).
• number: human presentable numbering for the node.
• title: title of the risk or module.
• current: boolean indicating if this is the current node. parent.
• active: boolean indicating if this is a parent node of the current node.
• children: list of child nodes (in the right order).
• url: URL for the API interface to this node..
• status: only present for risks and specifies the risk status. The value is one of postponed, present, not-present or null if the user has not seen the risk yet.

Start a new survey session¶

To start a new survey session a POST request must be send. This must include a JSON body with the following keys:

• survey: path of the survey. This is a combination of the id of the sector id and survey id, separated by a slash.
• title: title of the new session. This should default to the title of the survey itself.

This requires that the user already authenticated and a suitable authentication token is set in the X-Euphorie-Token header.

Here is an example request:

{
        "survey": "nl/stigas/bos-en-natuur",
        "title": "Beheer stadspark oost",
}

The response will be a JSON block:

{
        "id": "193714",
        "survey": "nl/stigas/bos-en-natuur",
        "type": "session",
        "title": "Beheer stadspark oost",
        "introduction": "Introduction text from the survey.",
        "next-step: "http://api.instrumenten.rie.nl/users/13/sessions/193714/profile",
}

If the survey has a configurable profile next-step will either to the profile update API. For surveys without profile questions next-step will point directly to the start of the identification phase.

Survey session information¶

This function returns almost exactly the same response as the survey session creation method. The only difference is the addition of a modified entry.

{
        "id": "193714",
        "survey": "nl/stigas/bos-en-natuur",
        "type": "session",
        "created": "2011-12-06T15:15:24Z",
        "modified": "2012-04-23T10:29:13Z",
        "title": "The title of the survey",
        "introduction": "Introduction text from the survey.",
        "next-step: "http://api.instrumenten.rie.nl/users/13/sessions/193714/profile",
}

Remove survey session¶

This will delete an existing survey session.

View profile information¶

The response will be a JSON block:

{
   "id": 15,
   "type": "profile",
   "title": "The title of the survey",
   "profile": [
       {
            "id": "1",
            "type": "optional",
            "question": "Do you have a storeroom?",
            "value": false,
       },
       {
            "id": "3",
            "type": "repetable",
            "question": "Enter your shop locations",
            "value": [
                "New York",
                "Paris",
            ],
       },
   ],
}

The id is set to the survey id. Please note that not all surveys have a profile, so the profile list might be empty.

Update profile¶

The request body must be a JSON block specifying the new profile:

{
        "1": false,
        "3": [
                "New York",
                "Paris",
        ],
}

It is mandatory that all profile questions are included in the request data. If data for a question is missing or invalid an error will be returned.

The response to a profile update returns the same information as the profile information view. The id of the survey may change as a result of a profile update.

{
        "id": 15,
        "type": "profile",
        "title": "The title of the survey",
}

Acknowledge survey update¶

If a survey was updated since the last user interaction and the survey structure was changed (for example a new risk has been added) the user must acknowledge the change and request that his survey session is updated accordingly.

These calls return the same information as the `profile information<View profile information>`_ and update profile calls. The only difference is that the type got a GET query will be set to update.

Start identification phase¶

This call will return information that is needed to start the identification phase in a survey. A frontend may not need to display any of this information but only use it to find locate the first unanswered question in the survey session, which is given in the next-step key.

{
        "type": "session",
        "phase": "identification",
        "title": "The title of the survey",
        "next-step": "http://api.instrumenten.rie.nl/users/13/sessions/1931714/1",
        "menu": [ ... ],
}

Start evaluation phase¶

This call will return information that is needed to start the evaluation phase in a survey. A frontend may not need to display any of this information but only use it to find locate the first unanswered evaluation question in the survey session, which is given in the next-step key.

{
        "type": "session",
        "phase": "evaluation",
        "title": "The title of the survey",
        "next-step": "http://api.instrumenten.rie.nl/users/13/sessions/1931714/2/5/13",
        "menu": [ ... ],
}

Start action plan phase¶

This call will return information that is needed to start the action plan phase in a survey. A frontend may not need to display any of this information but only use it to find locate the first unanswered action plan question in the survey session, which is given in the next-step key.

{
        "type": "session",
        "phase": "actionplan",
        "title": "The title of the survey",
        "next-step": "http://api.instrumenten.rie.nl/users/13/sessions/1931714/2/5/13",
        "menu": [ ... ],
}

Module information¶

previous-step and next-step can only be returned if the phase is provided. The phase must be one of identification, evaluation or actionplan.

Beyond the standard fields a module will return these extra fields:

Update module identification data¶

This call is only useful for optional modules. For normal (ie mandatory) modules it is an error to use this call.

The request must be a JSON block with an answer for the skip-children flag:

{
        "skip-children": false,
}

Risk information¶

previous-step and next-step can only be returned if the phase is provided. The phase must be one of identification, evaluation or actionplan.

Beyond the standard fields a risk will return these extra fields:

For risks with an evalution option of calculated these extra fields are included:

Update risk identification data¶

The request must be a JSON block with a (new) answer for the present flag. The comment can also be updated by including the comment field.

{
        "present": "no",
        "comment": "Verify with John at the shipping department!",
}

Update risk evaluation data¶

The possbile values depend on the evaluation method used for the risk. For risks that use a direct evaluation the priority field can be set directly. For risks using a calculated evaluation method the frequency, effect and probability information must be provided.

The comment can also be updated by including the comment field.

{
        "frequency": 10,
        "effect": 3,
        "probability": 7,
}

Update risk action plan data¶

This method updates the action plan-specific information for a risk. For top-5 and policy risks only the commend field may be updated. For other risks the priority can be set directly as well (but it may be reset of the user re-evaluates the risk).

The possible values for priority are low, medium and high.

{
        "comment": "We need to take another look at this",
        "priority": "medium",
}

Action plans can be added, updated or deleted through the actionplans container (see below).

List action plans¶

During the action plan phase a user is asked to indicate how he wants to tackle a risk by defining specific actions to be taken. This API call will return a list of all action plans provided by the user.

The response is returned in the form of a JSON object with a action-plans key containing a list of plans.

{
        "action-plans": [
                {
                        "id": 15,
                        "plan": "Clean the workplace",
                        "prevention": "Educate workers to clean daily.",
                        "requirements": "Soap, vacuumcleaner",
                        "responsible": "John Doe",
                        "budget": 1500,
                        "planning-start": "2012-04-15",
                        "planning-end": null,
                        "reference": "2012a16.5",
                },
        ],
}

See the view action plan call for details on the returned information.

View action plan¶

The response is returned in the form of a JSON object containing all known information about an action plan.

{
        "type": "actionplan",
        "id": 15,
        "plan": "Clean the workplace",
        "prevention": "Educate workers to clean daily.",
        "requirements": "Soap, vacuumcleaner",
        "responsible": "John Doe",
        "budget": 1500,
        "planning-start": "2012-04-15",
        "planning-end": null,
        "reference": "2012a16.5",
}

The reference key is not part of the standard Euphorie user interface, but can be used by consumers of this API to link a measure to an external system.

Create new action plan¶

The request must be a JSON object with data for the action plan to be added. The only required field is plan; all either items are optional.

The reference key is not part of the standard Euphorie user interface, but can be used by consumers of this API to link a measure to an external system.

The response is a JSON object with complete information on the newly created action plan. See the view action plan call for details.

Update action plan¶

The request must be a JSON object with all items that must be updated. Items not included in the request will not be changed.

Delete action plan¶

This call will remove an action plan for a risk.

View company details¶

This interface will return information about the company to which this survey session applies. The response is returned in the form of a JSON object containing all known information about the company. The possible fields are:

Update company details¶

This interface will update the company information for a survey session. See the View company details section for the supported fields.

Identifcation report¶

This API call will return the identification report. This is returned as a downloadable RTF file.

Action plan report¶

This API call will return the action plan report. This is returned as a downloadable RTF file.

Action plan timeline report¶

This API call will return the action plan timeline. This is returned as a downloadable OpenXML (xlsx) file.

List countries¶

Example response:

{
    "countries": [
        {
                "id": "nl",
                "title": "The Netherlands",
                "country-type": "eu-member",
        },
        {
                "id": "be",
                "title": "Belgium",
                "country-type": "eu-member",
        },
}

This call will return information on all defined countries.

Country information¶

Example normal response:

{
        "type": "country",
        "id": "nl",
        "title": "The Netherlands",
        "country-type": "eu-member",
}

Example detail response:

{
        "type": "country",
        "id": "nl",
        "title": "The Netherlands",
        "country-type": "eu-member",
        "sectors": [
          ...
        ],
        "managers": [
          ...
        ],
}

The returned fields are:

The possible country types are:

• eu-member: country is a full EU member state
• candidate-eu: candidate member of the EU
• potential-candidate-eu: potentital candidate member of the EU
• efta: member of the European Free Trade Association
• region: generic region, not an individual country

Note that even though a country has a title frontends are encouraged to use use locale-specific name for the country based on the id field.

Add a new country¶

The request body must be a JSON block specifying the new profile:

{
        "id": "nl",
        "title": "The Netherlands",
        "country-type": "eu-member",
}

This will return the country using the same format as the GET call.

Update country information¶

The request body must be a JSON block specifying the changed fields:

{
        "title": "The Netherlands",
        "country-type": "eu-member",
}

Updating the id field is not allowed.

List country managers¶

Example response:

{
        "managers": [
            {
                "id": "steunpunt-rie",
                "title": "Steuntpunt RI&E",
                "email": "steunpunt@example.com",
                "login": "steunpunt",
                "locked": false,
            },
        ],
}

Country manager information¶

Example response:

{
        "type": "countrymanager",
        "id": "steunpunt-rie",
        "title": "Steuntpunt RI&E",
        "email": "steunpunt@example.com",
        "login": "steunpunt",
        "locked": false,
}

The returned fields are:

Add new country manager¶

The request body must be a JSON block with the necessary information:

{
        "title": "Steuntpunt RI&E",
        "email": "steunpunt@example.com",
        "login": "steunpunt",
        "locked": false,
}

Please note that the id field can not be set manually: it will be generated automatically.

This will return the country manager information in the same format as returned by the GET call.

Update country manager information¶

The request body must be a JSON block with the data that should be updated:

{
        "locked": true,
}

Please note that the id and login fields can not be modified.

This will return the country manager information in the same format as returned by the GET call.

Delete country manager¶

List sectors¶

Example response:

{
        "sectors": [
            {
                    "id": "security",
                    "title": "Security",
                    "login": "security",
                    "locked": false,
            },
        ],
}

Sector information¶

Example response:

{
        "type": "sector",
        "id": "security",
        "title": "Security",
        "login": "security",
        "locked": false,
        "contact": {
                "name": "John Smith",
                "email": "smith@example.com",
        },
}

The returned fields are:

Add new sector organisation¶

The request body must be a JSON block with the necessary information:

{
        "title": "Security",
        "login": "security",
        "locked": false,
        "contact": {
                "name": "John Smith",
                "email": "smith@example.com",
        },
}

Please note that the id field can not be set manually: it will be generated automatically.

This will return the sector information in the same format as returned by the GET call.

Update sector information¶

The request body must be a JSON block with the data that should be updated:

{
        "locked": true,
}

Please note that the id and login fields can not be modified.

This will return the country manager information in the same format as returned by the GET call.

Delete sector organisation¶

Feature changes¶

• ...

Bugfixes¶

• ...

Feature changes¶

• More IS translation changes #11552

Bugfixes¶

• When a survey gets imported from XML, make sure that the ‘introduction’ text gets imported too. Fixes #105
• XML export: the node for classification_code of a Survey had a typo that prevented correct import of that value

Bugfixes¶

• More translation changes in IS #11424

Bugfixes¶

• Terms & Conditions: Change location, due to move of servers (OSHA #10858)
• Fix a bug in delete confirmation so that double quotes (which can come from translations) no longer break the Javascript (OSHA #10925)
• Translations changes in Icelandic (OSHA #11294)

Bugfixes¶

• Translation fixes in FI (OSHA #10635)

Upgrade notes¶

This release is dependent on Plone 4.3 and higher.

This release updates the profile version. Please use the upgrade feature in portal_setup to upgrade the euphorie.deployment:default profile.

Feature changes¶

• Add and enforce a password policy (OSHA #10286)
• When a sector our country manager is created, the new user receives an e-mail for setting the password; the admin no longer chooses the password initially
• On existing country and sector manager accounts, an admin can still manually set a new password.
• Lock users out after a certain amount of failed login attempts. Configured with the max_login_attempts setting in euphorie.ini. Set to 0 to disable completely. (OSHA #10286)

Bugfixes¶

• Corrected typo in PT

Feature changes¶

• Differentiate between the CSS classes given to the active node in the navigation tree, and its parent. (OSHA #9953)
• CMS user’s passwords are now hashed. (OSHA #10285)

Bugfixes¶

• Translation corrections in IT (OSHA #10039 #10370)

Feature changes¶

• Add two more questions to the company survey (OSHA #9281)
• Customise the name of “Macedonia” to “F.Y.R. Macedonia” due to political sensitivities (OSHA #10100)
• Translation correntions in SL (OSHA #10059 #9589)

Feature changes¶

• For the left-hand navigation in the OSHA styles, make the current menu item white and bolder (OSHA #8472)

Bugfixes¶

• Translation corrections in SL (OSHA #9584)
• Translation corrections in FI (OSHA #9806)
• Translation corrections in BG (OSHA #9790)

Bugfixes¶

• Added missing i18n statement around “Official OiRA logo” in the settings form
• Translation corrections in IS (OSHA #9345)
• Translation corrections in LT (OSHA #9510)
• Translation corrections in BG (OSHA #9324)
• Fix logo positioning on homepage in mobile view

Feature changes¶

• Track clicks on externals links using an external-link event in Google Analytics.
• Track report downloads as a virtual pageview in Google Analytics.
• Add four new virtual page views for Google Analytics in the client:
  • .../login/success - used after successfull login
  • /<country>/register/success - used after successfully registering a new account.
  • /<country>/<sector>/<survey>/start - used when starting a new survey session.
  • /<country>/<sector>/<survey>/resume - used when resuming a survey session.

Bugfixes¶

• Various styling improvements for the online client on mobile devices.
• Remove default Google Analytics account information.
• Remove the Status button on the help page if the user is not in a survey session.

Bugfixes¶

• Fix display of not-found page when accessing acquisitioned content from outside the client in the client. This fixes issue 99.
• In the client, write the current language as class into the body tag, so that language specific CSS rules can be applied.
• The default_priority field could overwrite the fixed_priority field when saving a Risk from the edit form.
• Improvements for the mobile view
• Re-ran yui-compression for the CSS files, since some changes had not made it in previously

Bugfixes¶

• Restore add buttons for non-survey content in the content editor.
• Fix error in generation of RTF reports for sessions with a depth larger than 4. This fixes `TNO ticket 245 <https://code.simplon.biz/tracker/tno-euphorie/ticket/245`_.
• Move register link up in the frontpage to make it more noticable: too many people missed it in its original position, leading to support requests. This fixes `TNO ticket 247 <https://code.simplon.biz/tracker/tno-euphorie/ticket/247`_.
• New translations in Italian (IT) and Icelandic (IS). OSHA #8434
• New translations in Maltese (MT). OSHA #8435
• Translation fixes in PT. OSHA #9193

Bugfixes¶

• Added missing English text for the “outdated browser” warning. OSHA #9094
• Add missing import statement. This caused a site error when trying to resume an existing session in the client.

Bugfixes¶

• If a survey title was modified through the survey version edit form the title was not updated in the index, which caused the old title to still be shown in the navigation tree.

Bugfixes¶

• Fix a packaging error which broke the 6.1.1 release.

Feature changes¶

• Add a new fixed evaluation method for risks. If this is used the sector organisation can set the risk priority directly, and the risk will be skipped during evaluation.
• Modify handling of profile questions in the client: include the profile question in the survey tree to make the naming more intuitive for users.
• Add a new obsolete flag to survey groups. When a survey with this flag is set is published it will be put into a new group of obsolete surveys in the client. This addresses part of TNO ticket 200.
• Make it possible to edit the survey group title from a survey edit screen. This addresses part of TNO ticket 200.
• Add page number to RTF reports. This fixes TNO ticket 241.
• For OSHA, show the legend only in the identification phase.

Bugfixes¶

• Security fix: modify client to always check if a survey session belongs to the current user.
• Fixed a typo in the client splash page. OSHA ticket #7261.
• Translation updates:
  • Add Bulgarian help headers. OSHA ticket #7317.
  • Add Portuguese translations of the splash page. OSHA ticket #7870.
  • Translate label_keep_logged_in on the client login page. OSHA ticket #7823.
  • Several minor translation fixes and updates. OSHA tickets #7830, #7766, #7810, #7829 and #8369.
  • Kosovo, Montenegro and Republic of Serbia are now translatable, and add bulgarian translations. OSHA ticket #7808.
  • Greek translation fixes. OSHA ticket #7704
  • Portugese translation fixes. OSHA ticket #7934
  • Applied new translations in 15 languages. OSHA tickets #7938, #8190, #8780
  • Added MIT Licensed script to display browser warning so that we can support translations. This addresses part of OSHA ticket 7847 and `OSHA ticket 7929 <https://projects.syslab.com/issues/7929`_.
  • Added missing CA translations in the “ancient browser” warnings. This fixes OSHA ticket 8418.

Bugfixes¶

• Display risk information in the client evaluation page as a message so links are readable. This fixes ticket 93.
• Include modules without a description in the navigation tree. This fixes TNO ticket 236.
• Fix a typo in the Dutch translations. This fixes TNO ticket 237.
• Show titles for profile questions in the right order in the profile form.
• Fixed the wrong translations for the timeline xls export priorities
• Fix header styling in the client. Added a body > in sector style before the h1 so that it is more specific
• Exchanged translation labels for priority names to match the translations in the action plan view. The timeline msgids seem to be fuzzy: the translation for low and high is translated as “default”

Bugfixes¶

• Add translations in fr, el, lv for “Keep me logged in”. Fixes #6846
• Require a newer NuPlone[r] version to fix CMS add and edit forms.
• Correct the navigation tree legend: the description for answered risks was not correct.
• Fixed IE9 navtree rendering bug.
• updated the text for the new login splash screen

Bugfixes¶

• Correctly initialise a newly added measure for a risk. This fixes ticket 86.
• Prevent users from entering non-digits in number input fields. This fixes part of ticket 84.
• Fix display of error messages in the risk action plan form. This fixes part of ticket 84.
• Always order the measures for a risk based on moment of creation. This prevents unexpected ordering changes.
• Renamed a default translation in content/help.py`` that lead to a duplication in the pot file
• Fix bad translations for column headers in the action plan timeline.

Upgrade notes¶

This is a beta release with incomplete translations.

Python 2.7 is now fully supported and the recommended Python version to use. Python 2.6 is still supported.

zc.buildout has been updated to version 2. You will need to re-bootstrap your buildout when upgrading to Euphorie 6.

This release updates the profile version to 13. Please use the upgrade feature in portal_setup to upgrade the euphorie.deployment:default profile to this version.

This release also updates the used Plone version to 4.2.4. You are advised to perform the Plone migrations through the Zope Management Interface (ZMI).

The Euphorie configuration file (etc/euphorie.ini in the standard buildout) no longer needs to include the complete configuration. You now only need to specify details that are specific to your deployment such as the Google Analytics accounts and client URL.

Feature changes¶

• Add a small FAQ to the login page.
• IE 6 is no longer supported. IE 7 is only provisionally supported: it might work, but any bugs will no longer be fixed.
• Add a legend to the client navigation tree to explain the used icons. This fixes ticket 51.
• Optional profile questions have been replaced with option modules. Previous versions supported both, and they did almost exactly the same thing which was a source of consution. All existing optional profile questions will automatically be converted to optional modules as part of the upgrade.
• Added translations for Finnish (FI) and Lithuanian (LT)
• Updated Bulgarian translations.
• Include a default application configuration file.

Bugfixes¶

• Correctly show the high-priority notice for risks in the online view of the action plan report.
• Start using the Patterns library for the client user interface.
• Use consistent styling of form error messages. This fixes tickets 45 and 46.
• Do render bold text as white on a light background in the risk action plan page for the client. This fixes ticket 75.
• Use a custom icon font to display the warning-icon in client reports. This helps for browsers/computers that do not include the unicode warning symbol in their font. This fixes ticket 61.
• Change default font for page titles in the client to a font which does not have problems with Greek characters. This fixes ticket 74.
• Dutch Translation: Fix bad column header in timeline report.
• Correct rendering of strong text in the client to make sure it is easy to read. This fixes ticket 65 and TNO ticket 232.
• Fix several positioning bugs in the client user interface. This fixes tickets 52 and 63
• Make sure pasted content does not violate any internal rules. It used to be possible to do things like mix risks and modules in a single container using copy & paste.
• Upgrade to zc.buildout 2, dexterity 1.2.1 and Plone 4.2.4.
• Registering from within a country would incorrectly skip terms and conditions page.
• Datepicker didn’t appear on newly created measures.
• Fix compatibility with plone.app.search.

Feature changes¶

• Remove country headings and instead show countries alphabetically (with EU at the top).

Bugfixes¶

Upgrade notes¶

This release changes the cookie format used to authenticate users in the client. As a result all currently logged in users will need to login again after upgrading to this version.

Feature changes¶

• Sort sessions on client start screen so most recently modified sessions are listed first.
• Display the survey introduction text on the survey view page in the CMS.
• Add a new API to manage country manager and sector CMS accounts.
• Add option in the client login to remember a user.
• CMS: update survey display to show profile questions and modules in a single list. This makes the display simpler and allows better reordering.

Bugfixes¶

• Remove extra space after risk severity in action plan report. This fixes TNO ticket 215.
• Fix broken translations for risk comments in identification phase. This fixes TNO ticket 230.
• Show our favicon in the client.
• IE8 fix in client. Adding a standard solution to an new/empty solution produces popup alerting user that they are overriding existing values.
• Fix for unicode error when providing non-ascii profile question values.

Feature changes¶

• Update Dutch translations. This fixes TNO ticket 223.
• Add jQueryUI datepicker to the date fields in the risk action plan page [jcbrand]
• Modify all reports to always add a marker for present risks so users can more easily find them. This fixes TNO ticket 206.

Bugfixes¶

• Several fixes for the risk action plan form (client):
  • i18n bugfix. [thomasw]
  • Do not silently ignore start and end dates for action plan measures of no date was provided. This fixes TNO ticket 225.
  • Handle internal error for dates with large years.
• Remove stray double quote in section titles in identification report. This fixes TNO ticket 222.
• Really show the notification that a password reminder has been sent. This fixes TNO ticket 229.
• Added missing i18n statement on conditions page [thomasw]
• Fix bad link in introduction text for action plan report. This fixes TNO ticket 227.

Bugfixes¶

• Client API changes:
  • Return the update-hint as JSON data.
  • Remove invalid next-step hint which was included on the session action-plan response if a survey has no risks present.
  • Use image URLs within the client API so images can be accessed by users who are not logged in on the client site. This reverts a change from 4.1.1.

Bugfixes¶

• Client API changes:
  • return a proper JSON error message if invalid JSON data is received.
  • return a proper JSON error message if an unsupported HTTP method is used.

Upgrade notes¶

This release upgrades Plone from version 4.1.3 to version 4.1.6. This may require to re-bootstrap your buildout if you see an error like this:

While:
  Installing.
  Getting section instance.
  Initializing section instance.
  Installing recipe plone.recipe.zope2instance.
Error: There is a version conflict.
We already have: Zope2 2.13.10

Bugfixes¶

• Client API changes:
  • correct the URL for the original image size. This fixes issue 38.
  • make sure image URLs point to the client instead of the API location.

Upgrade notes¶

This release updates the profile version to 12. Please use the upgrade feature in portal_setup to upgrade the euphorie.deployment:default profile to this version.

Feature changes¶

• Add Flemish (nl_BE), Latvian (lv), Greek and Catalan (ca) translations. [thomasw]
• Client API modifications: - Add module title to the returned risk information. - Expose risk standard solutions.
• Updated privacy policy text. [jcbrand]

Bugfixes¶

• Report styling improvements: correct display of comments to they are readable when printing a report. [cornae]
• Implement missing export of image data for modules and risks in the client API. This also changes the datastructure used for images; this should not break existing clients since image data was never present in earlier versions. [wichert]
• Fix survey XML importer to generate filenames for images if not provided. This solves problems with not being able to see fullsize images for imported images. [wichert]
• Show proper help URL when outside of a survey. [jcbrand]
• Correct display of standard solution titles in the CMS navigation tree. [jcbrand]

Upgrade notes¶

This release updates the profile version to 11. Please use the upgrade feature in portal_setup to upgrade the euphorie.deployment:default profile to this version. For large systems this migration spent a long time in a SQL migration; in that situation it may be useful to run a manual SQL migration step by hand first: connect to the database and issue these SQL statements:

ALTER TABLE action_plan ADD COLUMN reference TEXT;
ALTER TABLE account ALTER COLUMN password DROP NOT NULL;

Feature changes¶

• Expose client functionality with via simple REST API. [wichert]

Bugfixes¶

• Fix a bug in rendering identification reports. [wichert]

Upgrade notes¶

This release updates the profile version to 10. Please use the upgrade feature in portal_setup to upgrade the euphorie.deployment:default profile to this version. For large systems this migration spent a long time in a SQL migration; in that situation it may be useful to run a manual SQL migration step by hand first: connect to the database and issue this SQL statement:

ALTER TABLE tree ADD has_description bool DEFAULT 'f';

Feature changes¶

• Remove warning-icon for risks with a problem description in the action plan report. Since this report only contains present risks the icon was not useful. This fixes TNO ticket 219. [wichert]
• Change default for top5 risks to not be present to work around frequent abuse of top5 risks by sector organisations. They will still always be included in reports even if not present. This fixes TNO ticket 216. [wichert]
• Change default for optional modules to present based on user feedback. This fixes TNO ticket 197. [wichert]
• Make description for modules optional. If a module has no description it is skipped in the client. This fixes TNO ticket 213. [wichert]

Bugfixes¶

• Small grammar fix in Dutch translation for action plan introduction text. This fixes TNO ticket 220. [wichert]
• Add missing introductionary sentence in a direct survey view in the client which explains that a user can create a new survey. This fixes TNO ticket 193. [wichert]
• Fix case handling of email addresses when changing the email address in the client. Previously it was possible to change to an email address with capital, after which login was no longer possible. This fixes a final part of TNO ticket 194.

Upgrade notes¶

No special upgrade steps are needed for this release.

Feature changes¶

• Add a caption field for module image captions. This fixes TNO ticket 210. [wichert]
• Position images for module views on the right side of the page so they do not break running text as badly. This should fix TNO ticket 211. [wichert]
• Use a slightly larger image size for the module views, and enable image zoom (fancybox). This fixes TNO ticket 209. [wichert]

Bugfixes¶

• Fix case handling of email addresses when changing the email address in the client. Previously it was possible to change to an email address with capital, after which login was no longer possible. This fixes a final part of TNO ticket 194. [wichert]

Other changes¶

• Small code restructuring to make it easier for derived sites to change filters for reports. [wichert]

Upgrade notes¶

No special upgrade steps are needed for this release.

Feature changes¶

• Do not open list of all risks (under inventorisation) in a new window or tab. This fixes TNO ticket 205. [wichert]
• Add a new column with the risk number to the Action plan xlsx rendering. This fixes TNO ticket 203. [wichert]
• Update Dutch translations. [wichert]
• Added Bulgarian translations [thomasw]

Bugfixes¶

• Fix handling of text-style tags (strong/b/em/etc.) outside paragraphs when generating an RTF report. This fixes the second part of TNO ticket 208. [wichert]
• Fix colour of bold text in reports. This fixes TNO ticket 208. [wichert]
• The identification report wrongly showed the problem description for unanswered risks. This fixes TNO ticket 207. [wichert]
• Fix broken translations on risk action plan template. This fixes TNO ticket 201. [wichert]
• Use problem description instead of risk title in action timeline. This fixes TNO ticket 202. [wichert]
• No longer rotate the client navigation tree. [jcbrand, wichert]
• Bugfix, unpublishing a survey that’s in an active session raises KeyError. [jcbrand]
• Bugfix. CMS-style accessors must return bytestrings. [jcbrand]
• Removed setuptools_git as a dependency. [jcbrand]
• Fixed 2 typos that caused duplicate default translations [thomasw]

Upgrade notes¶

Development of Euphorie and related projecst has moved to the euphorie organisation on github.

This release updates the profile version to 9. Please use the upgrade feature in portal_setup to upgrade the euphorie.deployment:default profile to this version.

Feature changes¶

• Add a timeline export for the action plan: this generates an xlsx file with all measures for all risks. [wichert]
• Change risk priority terminology in Dutch. [wichert]
• Add an Currently unknown option for risk identification. This can be used to remove an existing answer. [wichert]
• Ignore case when checking the email address for client logins. [wichert]
• Use a better standard solution selector in the client. This fixes github ticket 5. [cornae, wichert]
• Group countries according to EU membership status. This fixes github tickets 1, 2 and 4. [cornae, wichert]
• Add another evaluation algorithm (French) for calculating risk priorities. [wichert]
• Upgrade client to jQuery 1.4.4 and jQuery UI 1.7.3. [wichert]
• Add an extra field ‘workers_participation’ to the Company form (and column to the SQL table). [jcbrand]
• Use z3c.zrtresource (and collective.zrtresource while still Plone < 4.1) to compile screen-ie6.css. This allows Cornelis to use physical paths in his Prototype, while zrtresource will give us the proper browserresource paths in Euphorie. One caveat is that we now have to minify the browserresource file (i.e http://localhost:4080/Plone2/client/++resource++screen-ie6.css) instead of the filesystem file. [jcbrand]
• Add delete validation on a sector to check that it doesn’t contain any published surveys. [jcbrand]
• Update Slovenian translations. [thomas_w]

Bugfixes¶

• Fix positioning of comments in the inventorisation report. This fixes TNO ticket 192. [cornae]
• Fix downloadable reports to correctly show a risks problem description. [wichert]
• Fix HTML->RTF conversion to not duplicate texts of links/bold/italic text in descriptions. [wichert]
• Fix survey tree update code to also rebuild the session for all tree changes instead of only profile changes. This fixes problems KeyErrors that appeared after publishing a survey which removes modules or risks. [wichert]
• Fix check for survey changes in the client: the old code falsely assumed client surveys were cataloged. [wichert]
• Hide hover beautytips on IE6 and clicktips on IE6 and IE7 [jcbrand]
• For extra robustness add extra check in new survey creation logic to make sure a valid survey was passed in. [wichert]
• Effect wasn’t set for French risks when added to the session tree. [jcbrand]
• #15: AttributeError is_region when publishing from a country not yet in the client. [jcbrand]
• For SurveyGroup, hide Evaluation Algorithm field on @@edit. [jcbrand]
• Allow the default sector colours to be customized via the euphorie.ini file [jcbrand]
• Change ordering of countries in the client to match the official EU ordering). This fixes github ticket 3. [wichert]
• Fixed Terms&Conditions page for anonymouse users. [jcbrand]
• During action plan phase, include all measures on request when validation fails. [jcbrand]
• Updated optional modules that are now mandatory must not have their children skipped. [jcbrand]

Upgrade notes¶

This release updates the profile version to 6. Please use the upgrade feature in portal_setup to upgrade the euphorie.deployment:default profile to this version.

Feature changes¶

• Add compatibility with SQLAlchemy 0.6. [wichert]
• Add a new EU region in addition to the existing countries. [wichert]
• Add unpublish feature to the CMS. [cornae, wichert]
• Clearly mark countries without surveys on the client frontpage. [cornae, wichert]
• Add options to change password, change email address or delete your account to the online client. [cornae, wichert]

Bug fixes¶

• Attempt to improve HTML->RTF conversion when generating downloadable reports. [wichert]
• Fix bug in handling of counting risk states for the client survey status screen. This fixes the second part of TNO ticket 155. [wichert]
• Added a euphorie.po for EN, so that we can also use the translation engine for that language, without the need to pass a default value. The file is a copy of euphorie.pot, with the msgstr being filled from the default entry or as a fallback from the msgid [thomasw]

Feature changes¶

• Enable the terms and conditions features introduced in release 2.3, but make it possible to disable it via a settings in the .ini file. This fixes ticket 107. [wichert]
• Replace downloadable action plan report with a RTF version. This solves problems with opening and editing the previous html fake-.doc approach. Downside of this approach is the loss of styling for the report. [wichert]
• Extend client form CSS to support percentage fields. [cornae]
• Added Greek translation provided by external translator for euphorie.pot; the latest additions are not translated yet [thomas]

Bugfixes¶

• Do not loose value of the referer field on the company details form. [wichert]
• The i18n msgid “label_login” was used for 2 different meanings. In content/user.py and content/upload.py, the msgid “label_login_name” is now used for the LoginField [thomas]
• Added msgid “label_preview”, Default “Preview”, as disambiguation from “header_preview” (Preview survey) and “button_preview” (Create preview) [thomas]
• in euphorie/content/risk.py changed Default translation for label_problem_description to “Inversed statement”, as given in euphorie/content/templates/risk_view.pt [thomas]
• in euphorie/content/upload.py added 2 new msgids, since the ones that were used already have a different meaning label_survey_title -> label_upload_survey_title help_surveygroup_title -> help_upload_surveygroup_title [thomas]

Feature changes¶

• Change title of edit form for non-toplevel modules to Edit Submodule. [wichert]
• Allow deletion of content in published surveys. The old behaviour was theoretically better, but turned out to be very confusing for users for little benefit. [wichert]
• Add feature to require users of the client to agree to the terms and conditions of the site. Disabled until the terms and conditions document has been written. [wichert]

Bugfixes¶

• Fix bad workflow configuration for surveys. This is related to the fix for TNO ticket 124. [wichert]
• Correct METAL macro invocation in client templates. [brand]

Feature changes¶

• Change the ordering of the risk types as requested by OSHA ticket 2253. [brand]
• Switch the client to the new OiRA logo. [cornae,pilz,wichert]
• When making a copy of a survey reset its workflow state back to draft. This allows deleting of content in a new survey that is based on a published survey. This is part of TNO ticket 124. [wichert]

Bugfixes¶

• The survey status screen could show module titles that do not match the current session. This fixes TNO ticket 155. [wichert]
• Stop declaring eupphorie to be a namespace package. [wichert]
• Require NuPlone 1.0rc1 or later so formatDate does not raise exceptions for pre-1900 dates. This fixes TNO ticket 150. [wichert]
• Do not accept pre-1900 dates in the action plan, since they break rendering of the report. This prevents TNO ticket 150 from occuring. [wichert]

Feature changes¶

• Update Dutch translations. [wichert]
• Perform basic verification of email addresses in the client registration logic. This fixes TNO ticket 147. [wichert]

Bugfixes¶

• Purge cached scaled logos when publishing a survey and updating the sector logo. This fixes TNO ticket 136. [wichert]
• Translate subject of password reminer email. This fixes TNO ticket 148. [wichert]
• Rewrite client company form to use z3c.form instead of repoze.formapi. [wichert]

Bugfixes¶

• Fix rendering of profile questions in the client. This was caused by a bad fix for TNO ticket 135. [wichert]
• When creating a XML export of a survey use the title of the survey group instead of the survey version. [wichert]
• Fix javascript syntax on the client frontpage which broke IE7. [wichert]
• Added translation for the profile content type description [pilz]

Bugfixes¶

• Fix spelling error in Dutch translation. This fixes TNO ticket 131. [wichert]
• Correct bad image scaling test when displaying a module in the client, which prevented images from being visible in action plan and evaluation phases. This fixes TNO ticket 135. [wichert]

Upgrade notes¶

This release updates the profile version to 4. Please use the upgrade feature in portal_setup to upgrade the euphorie.deployment:default profile to this version.

Feature changes¶

• Update the French translation of the survey creation guide. [pilz]
• Replace the collected company details with more generic information. The previous list is still used in the Dutch RI&E site and is now implemented in tno.euphorie. This fixes ticket 142. [wichert]
• Add missing question field to profile questions, and update the XML export code to export it. The XML import code and format specification already described this field. [wichert]

Bugfixes¶

• Use longer input boxes for title and question fields in the CMS. [pilz]
• Improve various texts. [pilz]
• Fix creation of report downloads for sessions with non-ASCII characters in their title. This fixes ticket 156. [wichert]
• Handle multiple buttons as returned by IE correctly in the company detail form. This could lead to site errors before. [wichert]
• Fix handling of partial date fields in company details forms. [wichert]
• Add publish permission to country managers. This fixes TNO ticket 126 [wichert]
• Declare dependency for question field in the module edit screen: it should only be shown for optional modules. [wichert]
• Fix bug in upgrade step for migration to 2.0rc2 which broke updating of security settings for existing content. [wichert]

Upgrade notes¶

This release updates the profile version to 3. Please use the upgrade feature in portal_setup to upgrade the euphorie.deployment:default profile to this version.

Bugfixes¶

• Add Copy or Move permission information to the published state of the survey workflow. This fixes TNO ticket 124 [wichert]
• Correct link colour in the reports. This fixes TNO ticket 104 [cornae]
• Fix accidental yes/no swap in translations. This fixes TNO ticket 121 [wichert]
• Add french translations [pilz]