novucs / esd Goto Github PK

A JSP page/servlet that allows for listing all the users who are registered on the system; to be displayed in a table. Administrators should be able to edit users (#134) from here and be able "View" a user (as described in #72!).

Tied to #71. This is an additional servlet that allows you to list details, claims and payments about a user.

As a user I need to be able to:

• Make a claim
• View my current claims in process
• Remove a claim

Use a table which allows us to use a Checkbox to multiselect claims for the administrator to approve (or deny).

As per the spec:

An administrator is expected to process outstanding operations raised by the full members including confirmation of the payments, charge the members based on annual lumpsum and membership fee, and assess the eligibility of the members for the outstanding claims.

The improvement on this is allowing for bulk processing, instead of 1 by 1 approval / denials.

Implement Database using tech spec

@novucs Implement ORM (Object Relational Mapping)

1. Clear database and create 3 test users.
2. Set 2 test user’s balance to an outstanding value.
3. Login to Admin account.
4. Navigate to Admin dashboard.
5. Select view outstanding balances.
6. Verify 2 outstanding balances are displayed.

A potential implementation for a PayPal sandbox gateway; unsure as to whether this works on a localhost development platform, and may have to be tested on https://esd.novucs.net:8080/latest/ for example.

1. Login to an admin account with an active membership.
2. Click switch to Member view.
3. Verify that website is now in member’s context with member dashboard option.
4. Click switch to Admin view.
5. Verify that website is now in admin context with admin dashboard option.

• List of deliverables completed, with members in charge (TDF)
• List of tasks yet to be completed with the members in charge (TDF)
• Delivery schedule for the rest of the project (Gantt Chart updated)
• Any change in members original roles and responsibilities

A powerpoint presentation can be used to demonstrate the sprint.

Passwords stored in the database should be irreversibly hashed

Implement different account statuses; we currently have a User status column that could be used to mark if the account is valid (1) or suspended (0). We can check account membership statuses by looking up that data via the Membership table.

Implement "Account Settings", available to both Users and Administrators.

A workflow for this could be:
Login -> Click user icon at the top right -> Account Settings

As a developer, I would like to publish the services using Docker, so that deployment environments are the same for everybody locally and in production

Docker Images:

• Derby*
• GlassFish*
• J2EE App with GlassFish base

* Must be built manually to match version shipped with NetBeans

Since we are frequently editing the database models while testing and redeploying, our local development environments databases are becoming increasingly difficult to test against. To remedy this, all tables should be cleared in the database if an environment variable DEVELOPMENT_MODE is set to true.

You may assume the system will accept cookies. No threading/concurrency considerations are required. All data must be stored and retrieved from Java DB database.

Ensure all data is retrieved from Derby (Java DB).

• Wrap up project
• Zipped NetBeans project
• In-class demonstration

Test Plan:

1. Login to user with membership.
2. Go to member's dashboard (expect Member's dashboard to load)
3. Check user's balance (Expect to be able to view user's balance)
4. Navigate to make a payment portal. (Expect to view make a payment portal)
5. Make a payment of X amount (Expect payment to process successfully)
6. Navigate to members dashboard and view outstanding balance. (Expect outstanding balance to be updated to reflect payment processed)

As per the spec, after registering "for [a] membership":

Once this information is submitted, the system should record it and confirm a provisional membership returning a user name and automatically generated password as well as charging him/her with annual membership fee.

Is this optional, or will we have to refactor in order to generate their password?

As per the spec:

Once the membership fee is paid and been confirmed by the office (admin), the person is upgraded to full membership level. Members are suspended if they did not pay annual fee and charges, and will be allowed to resume their membership once they cleared outstanding balances.

I guess we should handle this when we instantiate the User class? Potential workflows to consider:

• A user account could be suspended by an Administrator whilst that User is logged in, we will have to ensure that the User is then notified for this and lock down and additional
• A users membership could expire, ensure that the User is then notified about this. Maybe we should have a warning message to say 'Your membership expires in X days' on the dashboard (#62)

At the minute, to get the database access objects, a lot of static abuse is required. This is bad code practice and should instead be accessed via J2EE's CDI dependency injection helpers.

• Current Outstanding Claims
  • Running total of claims that haven't yet been set to APPROVED
• Total Payments Made
  • Running total of payments made by UID X, i.e. £1250.00
• Account Status
  • APPLIED / APPROVED / SUSPENDED

• Documentation for SASS Compiling
• Node compiling approach?

As registered user
I need a login form
In order to login to the website

1. Create a test member eligible to make a claim.
2. Login test member.
3. Navigate to member’s dashboard.
4. Submit a claim.
5. Verify claim has been submitted.

• Project plan, including the list of tasks with allocated members. Task Delivery Form (TDF) can be used for this purpose.
• Delivery schedule, a Gantt Chart
• Login functions completed, interacting with the database

A powerpoint presentation can be used to demonstrate the sprint.

Login as typical member user (e.g. user = “member1”, password = ”member1”) and create a session lasting for 20 mins. If not a user yet, register as an applicant for membership.

Implement the home page with Menu feature.

Setup a good base repository structure that is compatible with both IntelliJ and NetBeans IDEs for a J2EE web application

#22 currently takes an Address however the specification (Case Study) says that we should only ask for additional information when signing up for a membership:

Registrations for membership require personal information including name, address, date of birth, and date of registration of the applicants. (A web service may/should be used for address lookup purposes).

@G-Pex has already made work on the registration via #59. Is this Address in the correct place?

See Admin’s (management) Dashboard consisting of:-

• List all members
• List all outstanding balances
• List all claims
• List all provisional member applications
• Process individual claims
• Process membership applications and upgrade if payment is made
• Suspend/Resume membership
• Report annual turnover including total income and total pay-outs

Implement a Dashboard Interface, accessible for members.

• Check outstanding balance
• Make a payment
• Submit a claim
• List all claims and payments to date
• Logout button (Header?)

Implement an Administration Dashboard for administrators.

• Members applications
• Members list
• Outstanding balance list
• Claims list
• Process member applications
• Process member claims
• Manage membership status
• Report annual membership

1. Login to a members account.
2. Navigate to members dashboard.
3. Make a note of member’s outstanding balance.
4. Proceed to make a payment.
5. Pay X amount.
6. Navigate to member’s dashboard.
7. Verify that member’s outstanding balance has been updated accordingly.

1. Clear database and create 3 test users.
2. Login to Admin account.
3. Navigate to Admin dashboard.
4. Select view members with no filters active.
5. Verify all members are 3 displayed in results.

Navigate back-to main page to let change user (e.g. change to admin).

Be able to handle and maintain user sessions.

• These should expire after 20 minutes (unless the user is currently active)
  • These are handled via the user_sessions table
• Verify theses sessions via the Java app
• Write tests

Implement a User lookup, as per the spec:

Search for members based on provided particular information.

Produce a gantt chart to give a high level oversight of our project delivery plan.

As a developer, I would like an ORM implemented, so that future database interactions are simple and less error prone

Note: This ORM must be created with plain Java as Mehmet told us to not use third party libraries for "fairness"

As user
I need a registration form
In order to create an account on the site

1. Create a test member eligible to make a claim.
2. Create a selection of past claims and payments for the test member.
3. Login to test member.
4. Navigate to member’s dashboard.
5. Select view all claims. (TBC - Claims/Payments may be aggregated to one display)
6. Verify all expected claims are present.
7. Select view all payments. (TBC - Claims/Payments may be aggregated to one display)
8. Verify all expected payments are present.

1. Clear database and create 5 test users.
2. Upgrade 2 test users to members.
3. Login to Admin account.
4. Navigate to Admin dashboard.
5. Select view member applications.
6. Verify 3 member applications are displayed.

1. Clear database and create 3 test users.
2. Create 2 claims for one user,1 claim a second user and no claims for a third.
3. Login to Admin account.
4. Navigate to Admin dashboard.
5. Select view claims.
6. Verify 3 test claims are displayed.

Implement Logout functionality

We need to be able to handle permissions correctly on member dependent pages vs. admin dependent pages.

As far as I'm aware:

• Anonymous
  • Homepage
  • Login
  • Register
• Member Dependent
  • User Dashboard
  • Account Settings
  • Submit a claim
  • Submit a payment
  • Renew Membership
• Admin Dashboard
  • Administer / Manage Users
  • Approve / Deny Claims
  • TBC

See member’s dashboard, which consists of:

• Check for outstanding balance
• Make a payment
• Submit a claim
• List all claims and payments to date

As a developer, I would like to add a CI/CD (continuous integration/continuous deployment) pipeline for the project, so that the codebase is kept to a good standard

Design:

• Jenkins - Build, Lint, PMD, Test, Coverage
• Add gradle for handling dependency management, and checks

It is expected that the system uses "Filtering" for authentication purposes, especially for authenticating admin user - a clear example of this would also be favourably considered (“Filtering” is discussed in Chapter 13 of HF book).

Available here:

• https://docs.google.com/presentation/d/1YE8q5Ss_eXeBY88T_o1lAt124U194z2HVEm3Ye2s6Zc/edit#slide=id.g65affc0ea7_0_26

User with membership should be able to login, access the member dashboard and view outstanding balance.