• feature

Acceptance criteria:

features

implement course management to allow course-subject in the system

Acceptance criteria

• CRUD on Courses
• Link Courses to subject

features

seed a system admin when application start for the first time

Acceptance criteria

• system user username is admin
• system user password is admin

feature

add functionality of a tutor in the system

Acceptance criteria

• management service for tutor

features

implement student enrolment of courses in the system

Acceptance criteria

• enrol a student on a course

features

• display Basic Info
• display Address
• display Contact person

NB

Database info

Table

name = es_preadmission

Columns

Start

date

Deadline

date

[x] feature
add admission functionality
student profile

use case

use below information to create admission service

// student information
field: [title]
field: [first name]
field: [last name]
field: [middle name]
field: [current session]
field: [gender]
field: [dob]
field: [religion]
field: [nationality]
field: [avatar url]
field: [classId]

//account
field: [username]
field: [password]
field: [email]

field: [prevSchoolDate]
field: [admission type]

// address
field: [address]
field: [city]
field: [residential address]

// sms message number
field: [sms number]

field: [contact]

// parent information
field: [father name]
field: [mother name]
field: [father occupation]
field: [mother occuapation]

feature

• SMS support
• push notification
• email support

• feature

Acceptance criteria:

features

• display personal info
• authorization required

Database info

Table

name = es_staff

Acceptance criteria

• should be authorize to get profile

Feature

“Role-Based Access Control” is an approach to restricting system access to authorized users.

• User Roles
• Roles Permissions

features

implement a service to allow subject to be assign to tutors

Acceptance criteria

• A tutor can teach one or many subject
• A subject can be taught by one or many tutors
• Tutor can view all his assigned subjects

Describe the bug
Refactor authentication logic.

The current authentication logic is not ideal and hard to maintain in the future

Feature

Provide service to create a new student into the system

features

During user registration, send confirmation token as mail to continue the process

Acceptance criteria

• send token as email

features

• Implement authentication for user types [admin, staff, student]

Database

Columns

name	admin	staff	student
username	adminUsername	stUsername	pre_student_username
password	adminPassword	stPassword	pre_student_password
other		status, selstatus, tcstatus	status
table	es_dmin	es_staff	es_preadmission

Acceptance criteria

• should return access and refresh token after login
• should check invalid params

features

Add Thread model
Add Post model
Add Votes model
Add Groups model
Add Category model

features

create the notice board functionality

Acceptance criteria

• view all notice

Authorization required

• Only Student or staff can be allowed

• feature
  show attendance for user type[student]

Acceptance criteria:

• authorization required
• display attendance information

• feature

Acceptance criteria:

features

notice messages service deliver messages to target recipients on the system.

Acceptance criteria

• should be able to send notice message to target
• should be able to read sent messages
• should be able to receive other messages
• authorization is required here

Describe the bug
If program encounters an error, the fees payment are still kept in the db till the encountered
execution which doesn't insert the it's data. This can be problematic in the long run

To Reproduce
Steps to reproduce the behavior:

1. Throw an error in one of the saga event in module/fees
2. Start the server
3. Make a post request to pay fees
4. The throw error is shown at console
5. All the fees request are still the db without roll back

Expected behavior
A roll back is required if a transaction fails

features

fee service to handle fee payment for academic year, student and other
student wise transactions

Use case:

Fee payment walkthrough

• field: [amount]

• field: [fine]

• select [es_voucher] to get voucherId

• field: [es_voucherid]

• select [es_ledger] to get es_ledgerid
  field: [es_ledgerid]

• select payment mode [cash,cheque]
  field: [payment_type]

if [payment_type] == cheque:
bankInfo()

bankInfo = {

• field: [bank name]
• field: [account number]
• field: [cheque number]
• field: [teller number]
• field: [pin]
• field: [note/narration]
  }

Acceptance criteria

• authorization is required. user type[admin] only
• should able to add fee for an academic
• should able to display any student fee detail
• should able to display fee information for every class
• should able to display grand total of fees for all academic year