Delete Node

Description

Delete a node version and everything that depends on it. If this is the only version, delete the node.

The service also calculates the impacts of deletion. The impacts may be "impact errors" which prevent the deletion taking place (for example, deleting a package that contains frozen nodes), or may be "impact warnings" of what will automatically happen if the deletion goes ahead.

The service takes one of two actions: impact or force.

With an action of impact, the service lists the impacts. If there are impact errors, it lists impact errors but not warning. If there are no impact errors, it lists impact warnings (it does not list both).

With an action of force, the service performs the deletion provided that there are no impact errors.

If you delete the only version of a node, all nodes that use that as a type are deleted, all members that use it as a member type or target are deleted, and, if it is a package, all its contents are deleted.

If you delete a later version of a node, then nodes that use it as a type, member type or target are downgraded, i.e. modified to point to the previous version. If it is a package its contents are not altered.

Input

<DeleteNode>
<userLogonReference>userid</userLogonReference>
<password>password</password> <nodeVersionIdentifier/> <nodeVersionReference/> <action>impact|force</action>
</DeleteNode>

The node to delete can be identified by the nodeVersionIdentifier or nodeVersionReference. The identifier takes precedence.

Output

After an impact action if there are no impacts, the service returns:

<DeleteNode>
<errorNumber>0</errorNumber>
<nodeVersionIdentifier/> <nodeVersionReference/> <nodeName/> <nodeIdentifier/> <nodeReference/> <nodeVersionNumber/> <warningLevel>paranoid|high|medium|low</warningLevel> </DeleteNode>

The warning level indicates what type of warning should be shown the user before the delete.

  • low - no warning, user just needs to click on delete to continue with the delete
  • medium - as low, plus user needs to click a confirmation box to indicate that they understand this is a permanent delete
  • high - as medium, but user is told that there will be impacts and will have the opportunity to review them
  • paranoid - as high, but with greater emphasis and alarm to discourage accidental deletion

The warning level is controlled by a tag on the node type. system.DELETE_WARNING_PARANOID_TAG, system.DELETE_WARNING_HIGH_TAG, system.DELETE_WARNING_MEDIUM_TAG and system.DELETE_WARNING_LOW_TAG specify paranoid, high, medium and low respectively. The default is high.

After a force action if there are no errors, the service returns.

<DeleteNode>
<errorNumber>0</errorNumber> <mayReadParent>true|false</mayReadParent> <nodeReferenceParent/> </DeleteNode>

mayReadParent indicates whether the user can read the parent package of the deleted node. If this is true, then the reference of the parent node is returned. This can help clients decide where to navigate to next.

The default is "impacts".

There are two types of impact:

  • Error 108 - impact warning. This means that the delete is possible but will cause the deletion or modification of other nodes or members.
  • Error 109 - impact error. This means that the delete is not possible because it requires the deletion or modification of other nodes, but this user does not have the required authority. This is returned on either action.

An impact is returned as follows:

<DeleteNode>
  <errorNumber>108|109</errorNumber>
  <errorDescription/>
  <nodeVersionIdentifier/>
  <nodeVersionReference/>
  <nodeName/>
  <nodeIdentifier/>
  <nodeReference/>
  <nodeVersionNumber/>
  <warningLevel/>
  <ImpactList>
    <Impact>

      <impactType>delete|modify|error</impactType>

      <nodeVersionIdentifier/>
      <nodeVersionReference/>
      <nodeName/>

    </Impact>
  </ImpactList>
</DeleteNode>

impactType describes the impact on the node:

  • delete - the impacted node will be deleted if the node is deleted
  • modify - the impacted node will be modified if the node is deleted
  • error - the node prevents the deletion (it would need to be deleted or modified, but the user is not authorised).

The deletion errors will be shown before the modify errors. The impacts are then returned in name sequence.

If the node is not in development, error 106 is returned.

With error 109, the service does not necessarily return all impact errors (it does not look beyond errors it finds for consequential errors).

Errors

101 - Not authorised

102 - Not found

103 - Parameter error

106 - State error

108 - Impact warning

109 - Impact error

Class

com.metrici.xerula.DeleteNodeService