[FEATURE REQUEST] Change the trust account number on an existing bank record

[dangowans]

What feature are you suggesting?

The ability to open an existing bank record and update the account number associated with it.

Is your feature request related to a problem?

No.

Are there any workarounds? Are there any alternative solutions that would work?

Create a duplicate record with the new bank account number. Delete the records for the old bank account number.

[kirtanlab]

Hello @dangowans
I can work upon it, let me know if its still getting maintained

[dangowans]

@kirtanlab , thanks for reaching out!

The project is definitely still being maintained. There aren't regular changes in the "lottery licensing space, so there hasn't been a need for major, regular updates.

That being said, if you're interested in having a look at this one, feel free! I'm sure our licensing clerk would love to see some movement on it. 😄

[kirtanlab]

Thanks @dangowans for response,
I would like to work upon this feature. Let me review the code, if you can assign to me, it would be helpful.

[kirtanlab]

Issue: Login credentials from documentation not working

I followed the steps outlined in Admin Login Documentation to set up a default admin account.

Steps taken:

npm run dev:live

Added default admin credentials in config.js as instructed.

config.admin = {
defaultPassword: "password"
};

On the login page, entered:

Username: admin

Password: password (matching the value set in config.js)

Result:
Login fails — the application does not authenticate with these credentials.

Expected behavior:
The application should allow login when default credentials are configured in config.js according to the documentation.

Could you confirm if there have been changes to the authentication process, or if additional configuration steps are required?

[dangowans]

Looks like that documentation isn't current anymore. My apologies. I'll create an issue to remind me to update it.

All users are now configured in the users object. Testing users can be log in without the use of Active Directory. They must start with an asterisk.

// in config.js
config.users = {
	testing: ['*admin'],
	canLogin: ['*admin'],
	canCreate: ['*admin'],
	canUpdate: ['*admin'],
	isAdmin: ['*admin']
}

Testing users can only authenticate when using the test databases, so start the application with:

npm run dev:test

The passwords for testing users are the same as their user names. So, if the testing user's user name is *admin, the password is also *admin.

[kirtanlab]

It works,
Thanks for update.

[kirtanlab]

So I've been thinking about it and came up with couple of solutions, I've wrote down what i think about it
Please have look and tell me your opinion it.

I see three potential approaches to resolve this issue:

Option 1: As you suggest

Approach: Add functionality to directly update bank account numbers through a dialog
Implementation: Allow users to select from existing account numbers within the organization

Pros: Straightforward implementation, immediate solution
Cons: No audit trail, potential data integrity concerns

Option 2: Record Duplication with Status Tracking (Better) - Your alternative one

Approach: Duplicate records and mark old ones as inactive
Benefits:

• Maintains traceability through record dates
• Can search historical data when needed
• Option to fully delete if no tracking required

Pros: Good balance of functionality and data preservation
Cons: Potential data bloat over time

Option 3: Schema Redesign with Full Traceability (Best)

Approach: Restructure database schema for better normalization and audit capabilities

Proposed Schema Changes:
Current: org_bankrecords (account_number, record_date, ...)

Proposed:
├── Bank_ACCs (connected to Org_ID)
├── Record_Dates (connected to Org_ID)
└── ACC_Record_Date (linking table with active/inactive status)

Benefits:

Traceability: Full audit trail of all changes
Efficiency: Search by Org_ID through ACC_Record_Date with active status
Data Integrity: Reduces redundancy in primary tables
Scalability: Centralizes redundant entries in dedicated tables

Let me know if you have any doubt on it.

[dangowans]

@kirtanlab I appreciate your thoughts. Very thorough.

At this point, for our needs, option 1 is sufficient. It's mostly to correct a "typo" issue.

[kirtanlab]

@dangowans Thanks for your decision,
Soon, i will submit a pull request on it.