1 2 3 Previous Next 63 Replies Latest reply on Mar 7, 2017 12:08 PM by llamaassemblies

    Modifying Portal Records


      When the user attempts to modify a Portal Record, it would be nice if a confirmation box came up to confirm this action. If they chose yes the record is changed, otherwise it is reverted. The problem with this of course is that the dialog would need to trigger on an OnObject Modify, where the record data has already been altered. Revert Record does nothing because it affects the main record, not the portal, and Undo does not seem to help the situation. If the situation is textual, it makes sense to simply have a OnObject Enter that captures the older information. However, many of my fields are drag/drop based with the focus being on inserting files into various portals. This means OnObject Enters are not detected. The only assumption I can make is that I will need a calculation field storing the data from the first record, but I can see this becoming bloated over time as you are essentially having twice the amount of data for this situation. Is there a more efficient manner to tackle this problem?

        • 1. Re: Modifying Portal Records

          "Revert Record does nothing because it affects the main record, not the portal,"


          Revert record should revert both main and portal records if they are currently open for editing.


          You could put a popover in the portal row with global fields into which data from the portal row is copied when the portal opens. A "save" button could copy the data back into the portal fields before closing the popover.


          OnObjectModify can capture the previous value of the field if you pass the value to the script via the script parameter. This would work for drag and drop, but not so well for typing data directly into the field.


          Maybe you use onObjectEnter to open the popover and OnObjectModify to handle drag and drop.

          • 2. Re: Modifying Portal Records

            Revert record should revert both main and portal records if they are currently open for editing.

            I wonder why I am unable just to revert the record with a script. Nothing is being committed and the script runs on an OnObjectModify, so I don't really understand what is preventing it from functioning.


            Part of the problem seems to be that the record is only seeing the first record of a relationship and not the portal row, pretty much what normally occurs when you try to modify a record without entering a portal first. The drag/drop issue seems to be a problem because the user is not technically entering the portal.



            You could put a popover in the portal row with global fields into which data from the portal row is copied when the portal opens. A "save" button could copy the data back into the portal fields before closing the popover.

            I think I lost you. Why would a popover be needed in this instance? I am describing a large number of portals that function in one of two ways. Either they allow for textual input or they allow a drag/drop container. There are no portals where both exist at one time.


            I should also mention I am trying to apply this to a third type of portal that acts as a horizontal gallery. This "gallery" is made of multiple instances of the same portal but have different starting points and are singular records.

            • 3. Re: Modifying Portal Records

              Hmmm, as I recall now, drag and drop does not put the focus on the portal row into which you are dragging data. That makes it difficult to determine which portal row was just modified.


              If you have a field that auto-enters the modification time stamp, you could have your script locate the row with the most recent time stamp. I haven't done this recently, but if memory serves, this can work here.


              If I were using my computer rather than my phone, I'd also check to see if the portal record's primary key can be captured in the the trigger's script parameter.

              1 of 1 people found this helpful
              • 4. Re: Modifying Portal Records

                Indeed, trying to find the portal row that was just modified does serve as half the problem. The other half is that the only way I see it possible to restore old data at this point is to use a second container for every portal, which I assume will easily get quite bloated.


                I have attempted to get the primary key captured, but it seems it just sees the first record regardless. Maybe I am looking for the wrong thing.


                The modification timestamp method seems to work a bit better. I am able to get the dialog box to recognize which record it is modifying and alter it appropriately.


                Basically the script sorts all related records by modification date, allowing me to select the top record which will always be the newest. It then goes back to the original layout, refreshes the window to show the new record being added, and asks for confirmation. Cancel reverts those changes by seeing the original image and putting it back, while confirming changes the "original image" to the newly confirmed image.


                As it stands, the setup works relatively well, though as I have stated I am a bit concerned about bloat with dual containers.

                • 5. Re: Modifying Portal Records

                  Yep, my tests just confirmed that my prior idea of capturing the value in the script parameter don't work.


                  It does look like you need two fields if you want to support drag and drop directly into portal rows.

                  1 of 1 people found this helpful
                  • 6. Re: Modifying Portal Records

                    Indeed, a bit of a shame as it means you can't create some sort of relation from this.


                    I was questioning it, I just didn't like the idea of Filemaker becoming so bloated. Regardless, it seems like in this case it is necessary for the user case to function properly, it is impossible to "revert" data that has already been committed if it does not exist somewhere else in the database. While I wish it was a bit more streamlined, it does definitely work as intended and potentially cannot be cut down without losing functionality.

                    • 7. Re: Modifying Portal Records

                      For what it's worth, once the user either confirms or cancels the change, you no longer need to store both values. For container fields at least, the user can drag and drop into an empty field placed on top of the original field. After confirmation, the data is copied into the second field and the first field is cleared.


                      But you still have to use that modification timestamp to find the correct record.

                      1 of 1 people found this helpful
                      • 8. Re: Modifying Portal Records



                        I just ran a test where I used this script with OnObjectModify:


                        Show Custom Dialog [ "Keep this change?" ]

                        If [ Get ( LastMessageChoice ) = 2 // Cancel was clicked ]

                           Revert Records [ Show Dialog: off ]
                        End If


                        and it worked for me, Clicking cancel correctly reverted the change to the portal record. It also reverted any uncommitted changes to the parent and any other portal records at the same time so you might want to commit records as an "else" to the above If.

                        • 9. Re: Modifying Portal Records

                          Odd... I just ran this script with OnObjectModify:


                          Show Custom Dialog ["test"]

                          If [Get (LastMessageChoice ) = 2

                               Revert Record/Request [With dialog:Off]


                               Commit Record/Requests [With dialog:Off]

                          End If

                          Halt Script


                          and it didn't work for me. I tried changing the custom dialog to commit/not commit my data, but neither altered anything in the script. In either event, what occurred was that when the script step would go to Revert Record, it would not revert the file to the previous version or indeed anything in the database. No other scripts ran during the length of this script and yet the only commit was an "else" statement that was never tripped. I don't understand why my version of Filemaker 15.0.3 seems to not recognize this sort of revert as valid.


                          Hmm, I seem to be a bit confused with the invisible field method. I need the data to be able to be interacted with, meaning another field on top seems to cause conflicts. You need two fields when the data is switching, but wouldn't you also need it preemptively at all times due to the lack of detection of a drag/drop? Removing the data of one of the two implies either removing the current data, which is illogical, or the backup that becomes necessary during the revisions.

                          • 10. Re: Modifying Portal Records

                            I am using FileMaker 15.03 in window and since it reverts, I see no reason to use the extra field.


                            The invisible field captures the drop while keeping the original data. Once the change is confirmed, the script transfers the data to the normal container field and clears the invisible field placed on top. But as I said, I see no reason to do this given the revert option.


                            There is no need for Halt Script in your script by the way and it's not good practice to end a script with the Halt Script step as it "kills" any other scripts--including a different script that might in the future call this script as a sub script.


                            Compare your file to mine and maybe you'll spot something different--such as a script trigger present in your file that is not found in mine.

                            1 of 1 people found this helpful
                            • 11. Re: Modifying Portal Records

                              I generally don't include Halt Scripts, this was only for testing purposes. My "Halt Script" is generally a script I have designated to halt under certain conditions whilst resetting various things the user can do in the database (mostly regarding which buttons in the button bar were selected). The only reason I included it in my example was to ensure that no script was running after the end of this one for testing purposes. I do appreciate you warning me about its over usage.


                              The problem is that the revert option doesn't appear to be viable. I am unsure the logic of how or why, but the file you gave me acts identical to the situation I described above. My own database does not need to have been loaded for this issue to occur. I see the dialog box, I hit "Cancel". The script recognizes it needs to revert, but it doesn't revert the image and instead keeps the one I dragged/dropped. This is peculiar, now I wonder why my specific copy of Filemaker is apparently disregarding this type of revert.

                              • 12. Re: Modifying Portal Records

                                I'm using Windows. What OS are you using?


                                Here's the exact steps that I'm using:


                                a) I drag from the upper container field into the portal's container field. This is what I see before I drag and drop


                                b) drag and drop opens the portal row for editing and the dropped file appears in the container and I get the custom dialog asking confirmation:



                                I click cancel and the contents of the portal row revert:



                                I have tested this by dropping files into any one of the visible portal records. I also tested dragging and dropping data into the number field and got identical results.

                                1 of 1 people found this helpful
                                • 13. Re: Modifying Portal Records

                                  I am using Windows 7 64 bit Professional.


                                  The difference is that you are dragging and dropping information that exists in Filemaker. My end users like to drag and drop various files from their computer, such as a PDF file from the desktop. I click "Cancel", the image still is the new image due to there being no data that could be reverted.

                                  • 14. Re: Modifying Portal Records

                                    Yes that's the difference. It's an odd difference in behavior. "nothing to revert to" doesn't really make sense as an explanation. Reverting to "nothing" is an acceptable and expected result. You can even create an entire set of brand new records and make them all disappear with a single revert as long as none of them have been committed. It seems as though the data is committed without ever tripping the commit records trigger when you drop a file from outside of FileMaker.


                                    But the other idea, a transparent "drop target" field does work so long as you have a way to modify the correct record in your script. I used a special sorted relationship that references the record with the most recent modification timestamp as a way to do that in the attached file. And note that two copies of a given container field do not need to store data. One is kept empty except during the confirmation process. So you get an extra field, but not extra data.


                                    (and there's a global field in this file that I started to test in this file that I didn't actually use or test since modifying it would not update the ModTS field as needed to identify the row that's the target of the drop action.)

                                    1 of 1 people found this helpful
                                    1 2 3 Previous Next