EditUserStory

Functional specification

The ops-properties of a person can be modified. A person can become ops-enabled. And an ops-enabled person can be added or removed from projects.

For this Story only the OPS-specific user properties are accessible: associated projects and ops-enabled. User fields like name and address are not visible or mutable from here. Users have to be ops enabled before they can be made project members.

Possible mutations to user are:

• Making a user ops-enabled. (ops-disabling a user is NOT allowed, not for now. decided in progress meeting of 2-Apr)
• Assign an ops-enabled user to a project/remove an Ops-enabled user from a project.

Result: - ops-status of the user is written to persistence layer, either enabling or disabling project assignment. - when a person is added or removed from a project, it enables or disables him to register hours to the project and its tasks and get access to the shared mail-box for this project. -- IvanaCace - 19 Apr 2007

Technical specification

• ops-enable a person means:
  • adding him/her to the OpsProject group (this group is configured in opsproject.properties)

• ops-enabled users are those that belong to the OpsProject group

What is the current procedure for this use case?

Story Layout

Methods:

• StorePerson? (Person p)
• Helper Methods (unique Uid, etc)

FrontEnd? :

• Wicket Form with fields for each Person property
• Filters for correct input
• Exceptions to show bad input

Testing:

• PersonAttributeMapper?
• PersonDirContextMapper?
• Helper methods

Other:

• Discuss restrictions (Which prpoerties can be changed, etcetera)

Discussion

• Optionally, when ops-enabling a user, the application could create entries and ics's for timesheet and calendar, given their webdav addresses. This should be configurable.

Resources

-- RommertDeBruijn - 06 Mar 2007