LinkedIn
Twitter
- What do I do if I need to move a bunch of records to the same parent reference - but not all at once?
- What if I want to copy a bunch of rows to the same place, but do them one by one as I tap on them?
- How can I use actions to move records?
- How can I dynamically set the reference of a collection of records to the same parent asynchronistically? (^_^)
--------------------------------------------------------------------------------
- You first "turn on the system" by flagging a parent record as the "destination" - making it a global variable
- Then you navigate to any of the records you want to move/copy to the destination, and tap an action to move/copy them
- When you've moved/copied everything you want, you return to the parent and "turn off the system"
In the GIF to the left, the following scenario is taking place:
- We have a new department (AppSheet Apps) and we need to move some people to this department from several different depts.
--------------------------------------------------------------------------------
This is one of those essential skills that I eventually use in each of my builds.
It's technically not just one skill, but a collection of AppSheet skills - that when put together, it creates this really intuitive and smooth interaction method for moving things around inside your database.
--------------------------------------------------------------------------------
The Bits & Pieces
- For the Parent/Destination
- Column: [Temp_Var]
- If you've got The Standard Starting Template, this would be the [Form_Type] or [Automation_Trigger] columns - Action: Set | [Temp_Var] (Destination)
- Action: Clear | [Temp_Var]
- Slice: Destination_TABLE
- Formatting Rule: Destination TABLE
- Column: [Temp_Var]
- For MOVING A Child
- Action: Set | [TABLE_REF_CLUMN] (Destination)
- Action: View | This TABLE
- Action: Tapped | This TABLE
- For COPYING A Child
- Action: Ref New | TABLE to Destination
- Action: View | This TABLE
- Action: Tapped | This TABLE
--------------------------------------------------------------------------------
For the setup specifics of each element, see the sample app
See how it was built in the video below
@dbaum wrote:Theoretically could be combined with the import preview technique we discussed a couple months ago. Import a bunch of unassigned children records and then designate the parent for each.
Ooooooo.... THAT's good!
- Like..... reeeaaaalllly good
@MultiTech Thank you very much for that. I have some questions.
Why do you click on save in Google Table?
In the action's condition you refer to the slice.
Instead of creating a slice, you could use:
COUNT(SELECT(Destination_Depts[Department],[Temp_Var]="Destination"))=0
Would you always prefer a slice, or just in that case because you use that slice also for other stuff?
You recreate the Row selected **auto** action to open the detail view when clicking on a record.
The problem I saw is that Slideshow mode is then no more usable.
Imagine you click on a record in an inline table. With the Row selected **auto** action it will open the record and with Slideshow Mode you can jump forward and backward inside the [Related Children].
With the LINKTOROW() action it will open the record, but it will loose the relation. Slideshow Mode will bring you to the next row, which may not be part of the [Related Children].
Have you found a solution for that?
@Fabian_Weller wrote:Why do you click on save in Google Table?
Not sure what you mean...
-------------------------------------------------------------------------------------------------------
@Fabian_Weller wrote:Instead of creating a slice, you could use:
COUNT(SELECT(Destination_Depts[Department],[Temp_Var]="Destination"))=0Would you always prefer a slice, or just in that case because you use that slice also for other stuff?
Creating the slice holds the item that I've flagged as a global variable; this way if I need anything else out of that, it's right there waiting.
- But the real point behind the slice is the following:
- If I didn't have that, then every time I clicked on an item to move it - the system would have to brute force that select() to get the answer.
- Every time
With the slice, that answer is computed and held - ready for me to use without any computation power (or at least, not a SELECT()'s worth of power).
-------------------------------------------------------------------------------------------------------
@Fabian_Weller wrote:You recreate the Row selected **auto** action to open the detail view when clicking on a record.
The problem I saw is that Slideshow mode is then no more usable.
Imagine you click on a record in an inline table. With the Row selected **auto** action it will open the record and with Slideshow Mode you can jump forward and backward inside the [Related Children].
With the LINKTOROW() action it will open the record, but it will loose the relation. Slideshow Mode will bring you to the next row, which may not be part of the [Related Children].Have you found a solution for that?
No - honestly I've never noticed, nor have any of my clients pointed it out. I can see how that could get in the way for some workflows... but I've never had a case where it would cause a problem like that.
Generally I'm moving up and down the hierarchies, not sideways
