Bug #10979

[Merchant Application] Save Function

Added by Chuah Kar Yan about 4 years ago. Updated over 2 years ago.

Status:Closed - End of life cycleStart date:July 01, 2020
Priority:NormalDue date:
Assignee:Kok Ken Wong% Done:

100%

Category:-Spent time:8.00 hours
Target version:-

Description

Query from Ming Kit
1. Why every save for the form will create a new record in DB?

2. For the application that was saved for 3 times
1st save … Key in primary email .
2nd save … Nothing change, click save again
3rd save … change primary email to
From the link to retrieve old record, I am using to retrieve and success. Is this the correct flow?

History

#1 Updated by Ngoh Chee Ping about 4 years ago

  • Assignee changed from Ngoh Chee Ping to Kok Ken Wong

#2 Updated by Chuah Kar Yan about 4 years ago

  • Status changed from New - Begin Life Cycle to Closed - End of life cycle

As per system design, the application form does not carry any unique identifier to tie back to the previous version.
Each save will be treated as an individual record.

#3 Updated by Chuah Kar Yan about 4 years ago

  • Status changed from Closed - End of life cycle to New - Begin Life Cycle
  • Assignee changed from Kok Ken Wong to Ngoh Chee Ping

Ming Kit request to relook on design, only to store 1 time & update the same record, use BRN as key.
Need to check BRN when save/submit, not allowed to have a duplicate.

Also, for the db table design, Merchant_Form & Merchant_Form_Draft,
Ming Kit request to have only 1 table for both draft & submit. This for easier housekeeping & archiving.

Take Note
1. Before new merchant is saved to DB, need to make sure the merchant does not have an active application or not already is a Merchant. If have record or already merchant, reject.
2. Only have 1 active record per Merchant, to use the BRN as key
3. Have a cronjob to do record archiving for the merchant _form

#4 Updated by Ngoh Chee Ping about 4 years ago

  • Status changed from New - Begin Life Cycle to Development / Work In Progress

My answer as below

1) only to store 1 time & update the same record, use BRN as key.
Work in Progress

2) to have only 1 table for both draft & submit. This for easier housekeeping & archiving.
This is not recommend, because both table is to store different type of data, 1 is just for temporary use, another one is confirmed data. Will have different condition to housekeep these 2 table.

#5 Updated by Ngoh Chee Ping about 4 years ago

  • % Done changed from 0 to 80

Updated the save as draft only keep 1 record for 1 brn. Need to build another cronjob for house keeping.

#6 Updated by Ngoh Chee Ping about 4 years ago

  • Status changed from Development / Work In Progress to Finished Development
  • Assignee changed from Ngoh Chee Ping to Chuah Kar Yan
  • % Done changed from 80 to 100

Added cronjob to housekeep the merchant form draft table.

#7 Updated by Chuah Kar Yan about 4 years ago

  • Status changed from Finished Development to Internal Testing
  • Assignee changed from Chuah Kar Yan to Kok Ken Wong

Ken,

Please help deploy and test the cronjob.

#8 Updated by Tan Lee Yong over 2 years ago

  • Status changed from Internal Testing to Closed - End of life cycle

Old record

Also available in: Atom PDF