centreon · loiclau · Dec 1, 2017 · Nov 16, 2017 · Nov 17, 2017 · Nov 17, 2017
diff --git a/features/Acknowledgement.feature b/features/Acknowledgement.feature
@@ -6,7 +6,6 @@ Feature: Meta-services acknowledgement
     Background:
         Given I am logged in a Centreon server
 
-    @critical
     Scenario: Acknowlegde normal services
         Given a non-OK service
         When I acknowledge the service

diff --git a/features/Clapi.feature b/features/Clapi.feature
@@ -6,7 +6,6 @@ Feature: Clapi
   Background:
     Given a freshly installed Centreon server
 
-  @critical
   Scenario: import/export
     Given a Clapi configuration file
     And it was imported

diff --git a/features/CommandConfiguration.feature b/features/CommandConfiguration.feature
@@ -7,7 +7,6 @@ Feature: Edit a command
         Given I am logged in a Centreon server
         And a command is configured
 
-    @critical
     Scenario: Change the properties of a command
         When I change the properties of a command
         Then the properties are updated

diff --git a/features/ContactConfiguration.feature b/features/ContactConfiguration.feature
@@ -7,7 +7,6 @@ Feature: ContactConfiguration
         Given I am logged in a Centreon server
         And a contact is configured
 
-    @critical
     Scenario: Change the properties of a contact
         When I update contact properties
         Then the contact properties are updated

diff --git a/features/DowntimeDST.feature b/features/DowntimeDST.feature
@@ -10,55 +10,46 @@ Feature: Downtime DST
 
 # summer changing time
 
-  @critical
   Scenario: realtime downtime starting on summer changing time
     Given a downtime starting on summer changing time
     When realtime downtime is applied
     Then the downtime is properly scheduled
 
-  @critical
   Scenario: recurrent downtime starting on summer changing time
     Given a downtime starting on summer changing time
     When recurrent downtime is applied
     Then the downtime is properly scheduled
 
-  @critical
   Scenario: recurrent downtime ending on summer changing time
     Given a downtime ending on summer changing time
     When recurrent downtime is applied
     Then the downtime is properly scheduled
 
-  @critical
   Scenario: realtime downtime ending on summer changing time
     Given a downtime ending on summer changing time
     When realtime downtime is applied
     Then the downtime is properly scheduled
 
-  @critical
   Scenario: recurrent downtime starting and ending on summer changing time
     Given a downtime starting and ending on summer changing time
     When recurrent downtime is applied
     Then the downtime is not scheduled
 
-  @critical
   Scenario: realtime downtime starting and ending on summer changing time
     Given a downtime starting and ending on summer changing time
     When realtime downtime is applied
     Then the downtime is not scheduled
 
-  @critical
   Scenario: recurrent downtime during all day on summer changing date
     Given a downtime during all day on summer changing date
     When recurrent downtime is applied
     Then the downtime is properly scheduled
 
-  @critical
   Scenario: realtime downtime during all day on summer changing date
     Given a downtime during all day on summer changing date
     When realtime downtime is applied
     Then the downtime is properly scheduled
 
-  @critical
   Scenario: recurrent downtime of next day of summer changing date
     Given a downtime during all day on summer changing date is scheduled
     And a downtime of next day of summer changing date
@@ -69,62 +60,52 @@ Feature: Downtime DST
 
 # winter changing time
 
-  @critical
   Scenario: recurrent downtime starting on winter changing time
     Given a downtime starting on winter changing time
     When recurrent downtime is applied
     Then the downtime is properly scheduled
 
-  @critical
   Scenario: realtime downtime starting on winter changing time
     Given a downtime starting on winter changing time
     When realtime downtime is applied
     Then the downtime is properly scheduled
 
-  @critical
   Scenario: recurrent downtime ending on winter changing time
     Given a downtime ending on winter changing time
     When recurrent downtime is applied
     Then the downtime is properly scheduled
 
-  @critical
   Scenario: realtime downtime ending on winter changing time
     Given a downtime ending on winter changing time
     When realtime downtime is applied
     Then the downtime is properly scheduled
 
-  @critical
   Scenario: recurrent downtime starting and ending on winter changing time
     Given a downtime starting and ending on winter changing time
     When recurrent downtime is applied
     Then the downtime is properly scheduled
 
-  @critical
   Scenario: realtime downtime starting and ending on winter changing time
     Given a downtime starting and ending on winter changing time
     When realtime downtime is applied
     Then the downtime is properly scheduled
 
-  @critical
   Scenario: recurrent downtime during all day on winter changing date
     Given a downtime during all day on winter changing date
     When recurrent downtime is applied
     Then the downtime is properly scheduled
 
-  @critical
   Scenario: realtime downtime during all day on winter changing date
     Given a downtime during all day on winter changing date
     When realtime downtime is applied
     Then the downtime is properly scheduled
 
-  @critical
   Scenario: recurrent downtime of next day of winter changing date
     Given a downtime during all day on winter changing date is scheduled
     And a downtime of next day of winter changing date
     When recurrent downtime is applied
     Then the downtime is properly scheduled
 
-  @critical
   Scenario: realtime downtime of next day of winter changing date
     Given a downtime during all day on winter changing date is scheduled
     And a downtime of next day of winter changing date

diff --git a/features/DowntimeStartAndStop.feature b/features/DowntimeStartAndStop.feature
@@ -12,27 +12,23 @@ Feature: Downtime start and stop
     When I save a downtime
     Then the downtime start and end uses host timezone
 
-  @critical
   Scenario: Start of fixed downtime
     Given a fixed downtime on a monitored element
     When the downtime period is started
     Then the downtime is started
 
-  @critical
   Scenario: End of fixed downtime
     Given a fixed downtime on a monitored element
     And the downtime is started
     When the end date of the downtime happens
     Then the downtime is stopped
 
-  @critical
   Scenario: Start of flexible downtime
     Given a flexible downtime on a monitored element
     And the downtime period is started
     When the monitored element is not OK
     Then the downtime is started
 
-  @critical
   Scenario: End of flexible downtime
     Given a flexible downtime on a monitored element
     And the flexible downtime is started

diff --git a/features/GeneratePoller.feature b/features/GeneratePoller.feature
@@ -13,7 +13,6 @@ Feature: Generate poller configuration
         Then I am redirected to generate page
         And the pollers are already selected
 
-    @critical
     Scenario: Generate poller configuration
         Given a Centreon platform with multiple pollers
         And multiple pollers are selected

diff --git a/features/HostConfiguration.feature b/features/HostConfiguration.feature
@@ -7,7 +7,6 @@ Feature: HostConfiguration
         Given I am logged in a Centreon server
         And an host is configured
 
-    @critical
     Scenario: Edit the name of an host
         When I change the properties of a host
         Then its properties are updated

diff --git a/features/HostGroupConfiguration.feature b/features/HostGroupConfiguration.feature
@@ -7,7 +7,6 @@ Feature: HostGroupConfiguration
         Given I am logged in a Centreon server
         And an host group is configured
 
-    @critical
     Scenario: Edit the properties of an host group
         When I change the properties of a host group
         Then its properties are updated

diff --git a/features/HostTemplateBasicsOperations.feature b/features/HostTemplateBasicsOperations.feature
@@ -7,7 +7,6 @@ Feature: HostTemplateBasicsOperations
         Given I am logged in a Centreon server
         And a host template is configured
 
-    @critical
     Scenario: I test the modification of a host template properties
         When I change the properties of a host template
         Then the properties are updated

diff --git a/features/MassiveChangeHosts.feature b/features/MassiveChangeHosts.feature
@@ -7,7 +7,6 @@ Feature: Massive Change on Hosts
         Given I am logged in a Centreon server
         And several hosts have been created with mandatory properties
 
-    @critical
     Scenario: Configure by massive change several hosts with same properties
         When I have applied Massive Change operation to several hosts
         Then all selected hosts are updated with the same values
diff --git a/features/RestApi.feature b/features/RestApi.feature
@@ -3,7 +3,6 @@ Feature: REST API
   I want REST API in Centreon Web
   So that I can develop software interfacing with Centreon Web
 
-  @critical
   Scenario: Configuration REST API tests
     Given a Centreon server with REST API testing data
     When REST API are called

diff --git a/features/RestartCentreonEngine.feature b/features/RestartCentreonEngine.feature
@@ -6,7 +6,6 @@ Feature: Centreon Engine Restart
     Background:
         Given I am logged in a Centreon server
 
-    @critical
     Scenario: Check Centreon Engine Restart
         Given I am on the poller configuration export page
         And I check Restart Monitoring Engine

diff --git a/features/ServiceConfiguration.feature b/features/ServiceConfiguration.feature
@@ -7,7 +7,6 @@ Feature: Edit a service
         Given I am logged in a Centreon server
         And a service is configured
 
-    @critical
     Scenario: Change the properties of a service
         When I change the properties of a service
         Then the properties are updated

diff --git a/features/ServiceGroupConfiguration.feature b/features/ServiceGroupConfiguration.feature
@@ -7,7 +7,6 @@ Feature: ServiceGroupConfiguration
         Given I am logged in a Centreon server
         And a service group is configured
 
-    @critical
     Scenario: Change the properties of a service group
         When I change the properties of a service group
         Then the properties are updated

diff --git a/features/ServiceTemplateConfiguration.feature b/features/ServiceTemplateConfiguration.feature
@@ -7,7 +7,6 @@ Feature: Edit a service
         Given I am logged in a Centreon server
         And a service template is configured
 
-    @critical
     Scenario: Change the properties of a service template
         When I change the properties of a service template
         Then the properties are updated

diff --git a/features/TestProxyConfiguration.feature b/features/TestProxyConfiguration.feature
@@ -3,13 +3,11 @@ Feature: Testing A Configuration Proxy
     I want to test my proxy configuration
     So that to verify it
 
-    @critical
     Scenario: Proxy settings with a correct connection
         Given I am logged in a Centreon server with a configured proxy
         When I test the proxy configuration in the interface
         Then a popin displays a successful connexion
 
-    @critical
     Scenario: Proxy settings with a wrong connection
         Given I am logged in a Centreon server with a wrongly configured proxy
         When I test the proxy configuration in the interface 

diff --git a/features/TrapsSNMPConfiguration.feature b/features/TrapsSNMPConfiguration.feature
@@ -6,22 +6,18 @@ Feature: TrapsSNMPConfiguration
     Background:
         Given I am logged in a Centreon server
 
-    @critical
     Scenario: Creating SNMP trap with advanced matching rule
         When I add a new SNMP trap definition with an advanced matching rule
         Then the trap definition is saved with its properties, especially the content of Regexp field
 
-    @critical
     Scenario: Modify SNMP trap definition
         When I modify some properties of an existing SNMP trap definition
         Then all changes are saved
 
-    @critical
     Scenario: Duplicate SNMP trap definition
         When I have duplicated one existing SNMP trap definition
         Then all SNMP trap properties are updated
 
-    @critical
     Scenario: Delete SNMP trap definition
         When I have deleted one existing SNMP trap definition
         Then this definition disappears from the SNMP trap list
diff --git a/features/TrapsSNMPGroupConfiguration.feature b/features/TrapsSNMPGroupConfiguration.feature
@@ -7,17 +7,14 @@ Feature: Edit a trap group
         Given I am logged in a Centreon server
         And a trap group is configured
 
-    @critical
     Scenario: Change the properties of a trap group
         When I change the properties of a trap group
         Then the properties are updated
 
-    @critical
     Scenario: Duplicate one existing trap group
         When I duplicate a trap group
         Then the new object has the same properties
 
-    @critical
     Scenario: Delete one existing trap group
         When I delete a trap group
         Then the deleted object is not displayed in the list