Open Bryce13Reid opened 4 years ago
UI work will build on the work from the previous sprint and (1) add the 8000 limit with UI feedback. Note that this component will not appear on the FS until until #649 is complete
Just to help provide clarity.
When a user first arrives to the Collateral section these are the two buttons they are shown.
They are required to have one entry of serial collateral or one general collateral text area, to create a valid registration.
After clicking "add general collateral" once the button to add General Collateral is removed unless they remove the GC field entirely. (Then the button returns allowing them to add the GC text field again)
But there is only ever ONE General collateral text area with the 8k character limit.
As GC is entered when there are 1000 characters remaining a validation message will dynamically show the remaining character limit. If users paste or enter more characters than the limit, the "Confirm & Submit" will be blocked, and a negative character limit will be shown until they reduce the entered text to 8k characters, or remove the GC text area.
To clarify my expectations:
Re: Bryan's ask for the initial state wireframe for a FS when first opened please see the attached wireframe.
This would be the view a user see's when they first go to start a new registration before they have selected anything (assuming we opt for a security agreement to be selected by default)
Summary of proposed solution
The basic principal is that once general collateral is submitted (wether on a new registration or amendment) it cannot be modified. Rather, changes to general collateral will be considered additive. To this point, a user can only submit one general collateral at a time (up to 8000 characters). So when updating a financing-statement, there may be multiple read-only general collateral existing on the statement, but the user may only add a single new value.
On historical data, the approach was different, where users could submit multiple line, and on occasion could remove lines. This data will need to be appropriately migrated.
Here's a technical overview of the approach: API Interface:
POST
s will remain as it is today (generalCollateral
is a list of objects, each with a description
property)
generalCollateral
can not contain more than 1 item in the listdescription
cannot exceed 8000 characters and cannot be empty or null
financing-statement
will include a timestamp on the general collateralAPI Internals:
IMS Data Migration:
So no long
for the description? It's 2GB max, you can still enforce the 8000 chars limit. Saves you from having to split up the submitted string.
"Gentlemen, we have the technology!" Bonus points for naming where this quote came from.
So no
long
for the description? It's 2GB max, you can still enforce the 8000 chars limit. Saves you from having to split up the submitted string. "Gentlemen, we have the technology!" Bonus points for naming where this quote came from.
Certainly a good option, as long as the frame work supports it in a database agnostic way. Overall, the solution remains the same, it would just avoid us having to spit incoming data.
Looks good. What is the API structure when there is a timestamp?
User Story
Acceptance Criteria
User Experience
Business Rules
Kevin recommended the character limit as a way to help users be more concise in their collateral description. For example, if they are listing all the items of an estate down to each pair of socks, they may not understand what's needed. But, we also don't want to be prescriptive.Constraints
Reviews