Soyvolon
commented
2 years ago I think this type of system can be configured to handle all types of form submissions. Some ideas for managing that are as follows:
Form Layout Components
- The layout component holds the data for a form. It needs to be mapped to a series of input controls that are saved in the database so the data can then be properly checked against when previewing the data in a submitted form.
A key thing to note with the above is statically saving the form parts. Any changes to the form configuration would propagate in any further use, such as handling submissions. The best way to handle this would be to configure the form with a series of options without allowing the user to build a fully custom component (like the edit forms are). Fully custom forms could be done if there is some alternate method of updating the form configuration when a component is added or deleted.
Submission Pools
- The submission pools would hold all form submissions for a specific form. If a form is scoped to a specific roster tree, so would the submission pool (see: promotions and/or transfers where paperwork is only passed to the person who needs to see it)
- There would be multiple types of submission pools. Some for just reading the results of a submission, which can also act as change tracking, and others that would allow approval/denial of submissions, which can then filter data to its relevant location on the pool. All submissions are viewable in an unchangeable version of the Layout above.
Because the submissions require the layout, any changes to the layout could invalidate old data. There would need to be an effective way of displaying values within one of these forms so that any fields that are removed can still be displayed if old submissions are accessed.
- A submission pool would also be able to be configured to handle different actions depending on what types of values are submitted. If a value within the form meets a check, then the end action is opened for that check and the default action is ignored (promotions passing up a board).
The use of configuration options from the roster import component (with its boolean logical configuration) can be used here to create conditional values that are evaluated when a form is approved and/or submitted. Because form submissions can also run this event, these are configurable on both the form itself and on the pool that approves a submission.
Other Notes
Further configuration with these forms and pools could allow a single type of component to handle a lot of the paperwork side of roster management. Promotions, Transfers, Applications, Reports, Documentation, Value Grants, etc. can be filed, value assignments automated, and most importantly tracked using this type of system. It could replace the standard edit forms as a more flexible and reliable tool for making changes on the website.
Scopes would be a big part of these forms. Roster placement controls who and what values you are allowed to edit, all would have to be configured in the component. The relative position would also have to be taken into account.
@hobnob11 tagging you here for your thoughts on using a system like this when making and using pages. it would draw out the release and testing times, but we could ship with promotions and even more from the get-go (while also giving you better tools for roster clerks and change tracking).
Description
A reporting system that allows for dynamic creation and displaying of forms using the existing assignable value service. Did some pre-planning on this with class outlines.
Details
TODO
Notes