As the complexity of apps grows, the need to know βwhat record the user is looking atβ becomes a very important thing.
- But in order to get this information right now we have to build a whole system of columns/slices/actions/views to manage keeping track of this info.
Imagine the following scenario:
-
Youβre creating a system of check-list items that need to be completed each day
-
Say youβve created a βMaster_Checklist_Itemsβ table - holding 1 record for each βthingβ that needs to be recorded
-
Now say youβve got a βRemaining_Checklist_Itemsβ column, that takes the master list and subtracts everything that has been completed already.
-
Letβs say all this lives inside a daily report, where each day every item needs to be completed - so that βRemaining_Itemsβ list is a virtual column for the βDaily Reportβ parent table.
That remaining items VC will be a list from the βMaster_Checklist_Itemsβ table - literally showing those records in a list.
Screenshots
- So if you were to click on one of them, youβd be directed to the detail view for that βMaster Itemβ
What I really want to happen is when you tap on the item, it launches you into a form to complete that itemβ¦ for the report youβre looking at.
- But that βRemaining Itemβ list is actually from the context of the βBase Master Checklist Tableβ - and in no way connected to the specific record, and itβs details, that the user is currently looking at.
- So even if I were to take over the Event Action for that inline table, and instead direct someone to a specific FORM - I have no way of βpushingβ the record ID that the user is looking at into that form.
- I can push the specific checklist item the user clicked on into the form - because the user clicked on that record - but I canβt get the parent reference.
In order for me to get the specific record the user is looking at into the form, I have to create a setting system that allows the user to literally input what record theyβre βworking onβ - that the system can then call.
- This means Iβm either using
-
UserSettings - which requires a sync after each change, making it slow the flow of work.
-
Current_User (slice) - which requires a bunch of overhead, not to mention a bunch of superfluous record changes (from users changing a setting from one thing to another, clearing it, changing it back, etc. etc. - hundreds of βextraβ data changes that donβt need to be recorded/transferred).
-
Flag System - which again requires me to create a bunch of overhead: a system of temporary variables, actions, possibly slices, formatting rules, etc. all to point out and isolate the βcurrent record.β
If I could make use of context to pull the record ID from what the user is looking at, then I wouldnβt have to create a system to manage all this.
- This action would run from the context of the βBase Master Checklistβ table, but with the CONTEXT() part it would pull the ID of the record the user is currently looking at (pulled from the top level view).
As always, thanks for considering!