DeleteProjectStory

Functional specification

Remove a selected project and associated tasks from the persistence layer. Members assigned to this project will persist, and can be assigned to other projects and so on. This is the inverse operation to creating a project.

This use case is designed to be used when a project is added by mistake and it has to be undone.

For this reason there is a precondition: the project is only deleted if there are no emails associated to it, and no hours have been registered to it. Otherwise nothing is done and the user is told that the project could not be deleted explaining the reasons.

Technical specification

DAO behaviour:

• check that the project doesn't have emails associated to it (check that the IMAP folder of the project is empty)
• check that none of the members of the project has hours associated to the project*
• if any of those conditions are not met, throw corresponding exception
• if the conditions are met:
  • remove the IMAP folder of the project,
  • remove the project entry in ldap and remove its tasks

* if older project members have them it would be a problem. But it's unlikely that none of the current members have task associated in their timesheets if the project is really in use (in which case it should not be deleted). Also it's possible that all the hours have been archived. At this point we have to trust the criteria of the user (and give a warning before deleting).

What is the current procedure for this use case?

Story Layout

A crude description of the Story and its implementation:

Methods

• DeleteProject(Project p)
• ImapAccess.DeleteImapFolder(Project p)

FrontEnd?

• WicketLink? to delete project
• Confirmation before actual Delete?

Testing

• WicketConfirmation?
• DeleteProject (with mockDao?)

Other

• UserInterface? : do we make seperate SelectProject pages for Edit and Delete? Or do we make just one SelectProject-interface, with several options (edit, delete) for each Project?

Discussion

• Should the delete project function remove the project altogether? Or maybe just hide it from view but keep the data? In this case we will be removing it altogheter, but only if it's empty. Archiving in practice is already done, because all projects that are not active (they are closed) are not considered. -- FlaviaPaganelli - 22 Mar 2007

Resources

-- RommertDeBruijn - 06 Mar 2007