org.squashtest.tm.service.internal.deletion

Class RequirementDeletionHandlerImpl

java.lang.Object

org.squashtest.tm.service.internal.deletion.AbstractNodeDeletionHandler<org.squashtest.tm.domain.requirement.RequirementLibraryNode,org.squashtest.tm.domain.requirement.RequirementFolder>

org.squashtest.tm.service.internal.deletion.RequirementDeletionHandlerImpl

All Implemented Interfaces:

NodeDeletionHandler<org.squashtest.tm.domain.requirement.RequirementLibraryNode,org.squashtest.tm.domain.requirement.RequirementFolder>, RequirementNodeDeletionHandler

@Component(value="squashtest.tm.service.deletion.RequirementNodeDeletionHandler")
public class RequirementDeletionHandlerImpl
extends AbstractNodeDeletionHandler<org.squashtest.tm.domain.requirement.RequirementLibraryNode,org.squashtest.tm.domain.requirement.RequirementFolder>
implements RequirementNodeDeletionHandler

Constructor Summary

Constructors

Constructor and Description
RequirementDeletionHandlerImpl()

Method Summary

Methods

Modifier and Type	Method and Description
protected OperationReport	batchDeleteFolders(List<Long> folderIds)
protected OperationReport	batchDeleteNodes(List<Long> ids) Removing a list of RequirementLibraryNodes means : - find all the attachment lists, - remove them, - remove the nodes themselves NOOP notice This method is deprecated because it is no longer called by the super class : the method #deleteNodes has been overridden in the present subclass, that now calls more specific methods.
protected OperationReport	batchDeleteRequirement(List<Long> ids)
protected OperationReport	batchRemoveMilestoneVersion(List<Long> requirementIds, Long milestoneId)
protected OperationReport	batchUnbindFromMilestone(List<Long> requirementIds) Will unbind the given nodes from the given milestone.
OperationReport	deleteNodes(List<Long> targetIds) The following method is overridden from the abstract class because the business rule is special : for each node selected by the user : a/ if it is a folder : proceed as usual, b/ if it is a requirement : delete it and bind its children to its parent.
protected List<Long>	detectLockedNodes(List<Long> nodeIds) Given a list of node ids, returns a sublist corresponding to the ids of the nodes which cannot be deleted according to the specs.
protected List<SuppressionPreviewReport>	diagnoseSuppression(List<Long> nodeIds) Given their ids, that method should check the nodes and actually report the informations as specified in NodeDeletionHandler.simulateDeletion(List).
protected FolderDao<org.squashtest.tm.domain.requirement.RequirementFolder,org.squashtest.tm.domain.requirement.RequirementLibraryNode>	getFolderDao() The implemention should return which FolderDao to use depending on the end domain object.
protected boolean	isMilestoneMode()
protected void	reportLocksByMilestone(List<Long> nodeIds, List<SuppressionPreviewReport> preview)
protected void	reportMultipleMilestoneBinding(List<Long> targetVersionIds, List<SuppressionPreviewReport> preview)
protected void	reportNoFoldersAllowed(List<Long> folderIds, List<SuppressionPreviewReport> preview)
protected void	reportVersionLocksByMilestone(List<Long> versionIds, List<SuppressionPreviewReport> preview)
protected org.squashtest.tm.service.internal.deletion.RequirementDeletionHandlerImpl.TargetsSortedByAppropriatePunishment	sortThatMess(List<Long> nodeIds) Because nowaday deleting requirements is highly toxic for brain cells here is a method that will help out with deciding if a node should : be deleted as a folder (which is simpler) be deleted totally as a requirement (with all its versions).

Methods inherited from class org.squashtest.tm.service.internal.deletion.AbstractNodeDeletionHandler

createLockedFileInferenceTree, findNodeHierarchy, findPairedNodeHierarchy, simulateDeletion

Methods inherited from class java.lang.Object

clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

Methods inherited from interface org.squashtest.tm.service.internal.library.NodeDeletionHandler

simulateDeletion

Constructor Detail

RequirementDeletionHandlerImpl

public RequirementDeletionHandlerImpl()

Method Detail

getFolderDao

protected FolderDao<org.squashtest.tm.domain.requirement.RequirementFolder,org.squashtest.tm.domain.requirement.RequirementLibraryNode> getFolderDao()

Description copied from class: AbstractNodeDeletionHandler

The implemention should return which FolderDao to use depending on the end domain object.

Specified by:

getFolderDao in class AbstractNodeDeletionHandler<org.squashtest.tm.domain.requirement.RequirementLibraryNode,org.squashtest.tm.domain.requirement.RequirementFolder>

Returns:

an appropriate FolderDao.

diagnoseSuppression

protected List<SuppressionPreviewReport> diagnoseSuppression(List<Long> nodeIds)

Description copied from class: AbstractNodeDeletionHandler

Given their ids, that method should check the nodes and actually report the informations as specified in NodeDeletionHandler.simulateDeletion(List). See AbstractNodeDeletionHandler.detectLockedNodes(List) for details regarding the input list.

Specified by:

diagnoseSuppression in class AbstractNodeDeletionHandler<org.squashtest.tm.domain.requirement.RequirementLibraryNode,org.squashtest.tm.domain.requirement.RequirementFolder>

Parameters:

nodeIds - the complete list of the nodes involved in that report.

Returns:

a list of reports summarizing in human readable format what will happen.

reportMultipleMilestoneBinding

protected void reportMultipleMilestoneBinding(List<Long> targetVersionIds,
                                  List<SuppressionPreviewReport> preview)

reportVersionLocksByMilestone

protected void reportVersionLocksByMilestone(List<Long> versionIds,
                                 List<SuppressionPreviewReport> preview)

reportNoFoldersAllowed

protected void reportNoFoldersAllowed(List<Long> folderIds,
                          List<SuppressionPreviewReport> preview)

reportLocksByMilestone

protected void reportLocksByMilestone(List<Long> nodeIds,
                          List<SuppressionPreviewReport> preview)

detectLockedNodes

protected List<Long> detectLockedNodes(List<Long> nodeIds)

Description copied from class: AbstractNodeDeletionHandler

Given a list of node ids, returns a sublist corresponding to the ids of the nodes which cannot be deleted according to the specs. The input list includes all the nodes and their children in the directory structure. The implementation is responsible to fetch any other dependencies needed for the completion of its task. The implementation is not required to resolve which folders are locked : this abstract class will handle that on the basis of the returned value.

Specified by:

detectLockedNodes in class AbstractNodeDeletionHandler<org.squashtest.tm.domain.requirement.RequirementLibraryNode,org.squashtest.tm.domain.requirement.RequirementFolder>

Parameters:

nodeIds - all the node ids.

Returns:

the sublist of node ids that should NOT be deleted.

sortThatMess

protected org.squashtest.tm.service.internal.deletion.RequirementDeletionHandlerImpl.TargetsSortedByAppropriatePunishment sortThatMess(List<Long> nodeIds)

Because nowaday deleting requirements is highly toxic for brain cells here is a method that will help out with deciding if a node should :

1. be deleted as a folder (which is simpler)
2. be deleted totally as a requirement (with all its versions). Note : a requirement that wont be deleted is said to be locked
3. rebind its subrequirements to its parent (usually because it has to be deleted)
4. delete only a version which happen to belong to a given milestone
5. unbind only a version from a given milestone

The generic name for those different situations is contextual-deletion. Nodes that fall under one of those situations are thus referred to as contextually-deleted.

Another concern now : the fate of the selected nodes depend on what the user specifically picked. For each node picked by the user :

rule D1 : if it is a folder : contextual-delete the whole subtree

rule D2 : if it is a requirement : contextual-delete that requirement alone

Then, we can safely proceed with peace in mind knowing which node requires which treatment.

(non-Javadoc)

See Also:

AbstractNodeDeletionHandler.deleteNodes(java.util.List)

deleteNodes

public OperationReport deleteNodes(List<Long> targetIds)

The following method is overridden from the abstract class because the business rule is special : for each node selected by the user :

• a/ if it is a folder : proceed as usual,
• b/ if it is a requirement : delete it and bind its children to its parent.

Another concern is the milestone mode. When regular entities such as test cases are deleted, they are either deleted, either spared because of business or sec rules. For requirements the problem is a bit more complex because of their versions. A version can be deleted, and also if that deleted version was the only one in a requirement then only that requirement can be deleted.

All of this is is handled for a good part by the logic in #sortThatMess(List, Long)

(non-Javadoc)

Specified by:

deleteNodes in interface NodeDeletionHandler<org.squashtest.tm.domain.requirement.RequirementLibraryNode,org.squashtest.tm.domain.requirement.RequirementFolder>

Overrides:

deleteNodes in class AbstractNodeDeletionHandler<org.squashtest.tm.domain.requirement.RequirementLibraryNode,org.squashtest.tm.domain.requirement.RequirementFolder>

Parameters:

targetIds - the list of node ids selected by the user.

Returns:

an OperationReport saying what happened.

See Also:

AbstractNodeDeletionHandler.deleteNodes(java.util.List)

batchDeleteFolders

protected OperationReport batchDeleteFolders(List<Long> folderIds)

batchDeleteRequirement

protected OperationReport batchDeleteRequirement(List<Long> ids)

batchRemoveMilestoneVersion

protected OperationReport batchRemoveMilestoneVersion(List<Long> requirementIds,
                                          Long milestoneId)

batchUnbindFromMilestone

protected OperationReport batchUnbindFromMilestone(List<Long> requirementIds)

Description copied from class: AbstractNodeDeletionHandler

Will unbind the given nodes from the given milestone. The operation report must report such nodes as 'deleted', in order to notify the tree not to display them anymore.

Specified by:

batchUnbindFromMilestone in class AbstractNodeDeletionHandler<org.squashtest.tm.domain.requirement.RequirementLibraryNode,org.squashtest.tm.domain.requirement.RequirementFolder>

Returns:

batchDeleteNodes

protected OperationReport batchDeleteNodes(List<Long> ids)

Removing a list of RequirementLibraryNodes means : - find all the attachment lists, - remove them, - remove the nodes themselves NOOP notice This method is deprecated because it is no longer called by the super class : the method #deleteNodes has been overridden in the present subclass, that now calls more specific methods. However the class must still provide an implementation. So we leave this code as history, but marked as deprecated. Note that it doesn't support the milestone mode nor some other specific rules regarding requirement rewiring etc.

Specified by:

batchDeleteNodes in class AbstractNodeDeletionHandler<org.squashtest.tm.domain.requirement.RequirementLibraryNode,org.squashtest.tm.domain.requirement.RequirementFolder>

Parameters:

ids - the doomed node ids.

Returns:

isMilestoneMode

protected boolean isMilestoneMode()

Specified by:

isMilestoneMode in class AbstractNodeDeletionHandler<org.squashtest.tm.domain.requirement.RequirementLibraryNode,org.squashtest.tm.domain.requirement.RequirementFolder>