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!