all data is live and searchable
|
Basic Assignments
|
Options & Settings
|
Main Time Information
|
||||||||||||||||||||||||
|
|
|
Green
|
|
|
Sorry, no photos available for this element of time.
|
|
|
|
Notes:
|
|
On the new flex grid fields that Will Hudson did... I think we will have a problem if they get edited. If yes (edited), we will overwrite them with the normal defaults. So, basically, Will's code uses things like: corp 2, main id 2, sub id, sub id 2, table name, table name 2, external alternate id, and special JSON storage (a bunch of new fields for cross corp stuff). That is great, but when you edit the flex grid, the old defaults are pass to the update method on the add_edit_flex_grid_action.cfm page. This will end up overwriting the real values that should be stored there. Small oversight. We'll need to go in and fix this. This could be done by passing those new values in hidden fields between the add/edit page and the action page. While we are in on the add_edit_flex_grid_action.cfm page... I would recommend that we put the new fields (method arguments) into alphabetical order. Currently the new fields are just listed at the bottom of the different method calls. It would help standardize things if they were alphabetic. If we really wanted to make these new features more dynamic, we could also create FORM params for the main add/edit page. We could then pass them through just like normal FORM params. The key there is to set the defaults on the top of the page, then validate as if they are real (which they will be once we start using them), and then making them dynamic in both the add and update methods. That would be really cool. |