SelectProjectStory

Functional specification

User selects an existing project or creates a new one. Since the pool of projects may be very large, there is some filtering to reduce the results size, pagination and sorting.

Th filtering is done by active/closed projects and by name: part of the name can be entered (or left blank to bring everything). By default, the filter is set to bring active projects.

The selected project can be viewed, modified or removed.

Result: for an existing project the user can edit (EditProjectStory) or delete it (DeleteProjectStory). Or the user can choose to create a new project and edit it (EditProjectStory).

What is the current procedure for this use case?

The projects are explored using phpLDAPAmin (ldap.func.nl).

Technical specification

Screen

• List of projects (fine-tuneable)
• Links to Create, Edit and Delete project

The user either selects a project, and then clicks on Edit or Delete. Or (s)he clicks on Create.

With Edit and Create, the EditProjectStory is executed (another screen). In case of Delete, the DeleteProjectStory is executed.

Access to the backend

The list of projects has to be fetched from LDAP.

Discussion

• Maybe give the possibility of filtering the list of projects by other criteria, such as date of creation, date closed, 'activity' (amount of tasks), etc. might be useful.

• Export a project as text file?

Old Discussion

• When user selects a project, should the project information be shown (as a sort of view function)? Or should there be a dedicated 'viewProject' function? If so, where? Or does selecting the project immediately lead to the edit-screen?

• SelectProjectStory as it is now does its job in two steps: first the user makes a selection of projects - i.e. a list of projects is returned from the DAO fitting the user constraints or holding only the active projects if no constraints were specified. Then, from this list the user selects one project - for editing, deleting or viewing. Should the SelectProjectStory be split up in two stories representing these two steps?

This question is also tied in with implementation. We have our bean objects representing domain entities, but would it not be quicker to have some scrap-objects that move information between DAO and managers in lists (lists of project ID's for example)?

Rommert says: yes, create two stories. First story (ListProjectsStory? ) should be easy to implement for now (with dummy constraint/filter functionality). Second story (SelectProjectStory) should select 1 project from a list of projects.

Estimates

subtask	hrs. est.
Read SpringLDAP? docs	2
POC: talk to LDAP	8
Add test data in LDAP	2
Write test classes for ProductDAO? interface	2
Implement classes for ProductDAO? interface	4

task	hrs est.	hrs	status
screen	4; 8	20	100%
access to backend	4; 20	0	0%
Test Classes	4	4	75%
Wicket setup	4	16	100%
Spring setup	4	0	75%
Total		40	70%

Resources

-- RommertDeBruijn - 06 Mar 2007