Discussions

 View Only

  • 1.  Save and Keep Working behavior in a Custom button

    Posted 11-17-2022 17:39
    The native behavior of Save & Keep Working will save Both the edit made to embedded child records and whatever changes made in the form to the parent record. The code below Does Not do that. I found the below at: Alternatives to common JavaScript Insertion techniques

    var text rid = If([Record ID#]>0, ToText([Record ID#]), "%%rid%%"); 

    var text url = URLRoot() & "db/" & Dbid() & "?a=er&rid=" & $rid; 

     "<a class=\"Vibrant Primary SaveBeforeNavigating\" data-replaceRid=\"true\" href=\"" & $url & "\">Save & Keep Working - Rich Text</a>" 

    My endeavor is to have a Custom Button behave the same way as the Native "Save & Keep Working" button. Save both parent and child record edits, redisplay in edit mode. Why a custom button? you may ask. Because the other options "Save & Close" and "Save & Next" I do not want to be available to the end user. Any assistance is appreciated. 
    Thank you,
    CGreene



    ------------------------------
    Christopher Greene
    ------------------------------


  • 2.  RE: Save and Keep Working behavior in a Custom button

    Posted 11-17-2022 18:38
    Is the problem that the button fails if the only changes to the record are in the grid edit?

    ------------------------------
    Mark Shnier (Your Quickbase Coach)
    mark.shnier@gmail.com
    ------------------------------

    Original Message


  • 3.  RE: Save and Keep Working behavior in a Custom button

    Posted 11-18-2022 09:14
    Not the only change, but one of the changes - either, or. If I were to make an edit to the main parent record only, then the custom button works. If I make an edit to the embedded child records, regardless of whether I make an edit to the parent, then click my custom button, QB behaves as if I'm navigating away before the save with the message, "Leave site? changes you made may not be saved".

    ------------------------------
    Christopher Greene
    ------------------------------

    Original Message


  • 4.  RE: Save and Keep Working behavior in a Custom button

    Posted 11-18-2022 09:10
    Edited by Brian Seymour 11-18-2022 09:17
      |   view attached
    I'm not totally tracking the issue, but your button is just opening a record in edit mode vs. displaying the record (the url query string contains a=er vs. a=dr), so it seems like the record is just reloading without saving changes, right?

    Have you reviewed the Table Advanced Settings to ensure the "Auto save when redirected away from the page" box is checked?

    Also, it sounds like you are aware, but on the Form level (not Table level) we can control button visibility via the "Show Save & close and Cancel buttons at the end of this form" and "Show save & keep working choice" boxes. So an alternative solution may be to create a separate form and assign this form as the default for Users in certain Roles. You can point the Users in a given form using the dfid=[YourFormID] query string parameter and in the Form UI to use the native QB controls. I'm not sure that's a feasible option in your use case, but wanted to throw it out there!

    See attached screenshots.

    ------------------------------
    Brian
    ------------------------------

    Original Message


  • 5.  RE: Save and Keep Working behavior in a Custom button

    Posted 11-18-2022 09:35
    @Christopher Greene

    The SaveBeforeNavigating syntax is known to fail i.e. (causing that pop up) if the only change to the record was In Grid Edit. I have found that it works reliably if the Parent record is changed. What I finally settled on which works perfectly is to make to helper fields on the form. One is called [Dirty the record] and the other one is called [Dirty the record plus 1].  The latter is a formula field obviously equal to

    [Dirty the record] +1`

    I then have a form rule set to fire all the time where if those two fields are not equal I change [Dirty the record] to be equal to the value in the field [dirty the record plus 1].  

    In your post above you are claiming that save before navigating fails even if both the parent and the child have been modified. In my experience that is not how it behaves. Try putting in that form rule and see if it solves the problem.   ​

    ------------------------------
    Mark Shnier (Your Quickbase Coach)
    mark.shnier@gmail.com
    ------------------------------

    Original Message


  • 6.  RE: Save and Keep Working behavior in a Custom button

    Posted 11-18-2022 10:02
    Mark,
    Your provided solution works great when only the embedded child records themselves are edited when the main parent record is not necessarily changed. 
    Thank you for the helpful tip. Much appreciated.
    CGreene

    ------------------------------
    Christopher Greene
    ------------------------------

    Original Message


  • 7.  RE: Save and Keep Working behavior in a Custom button

    Posted 11-18-2022 10:21
    .... But, if I click the table button or any other button, since those two helper fields are constantly changing, then I'll have to respond to the popup that warns of unsaved fields, specifically the two helper fields. The Save & Close button takes me out, but that is an option that I would hide from the end user with &ifv=1 in the query string. Anyway, I'm further along with the solution than I was yesterday.
    Thanks again,
    CGreene

    ------------------------------
    Christopher Greene
    ------------------------------

    Original Message


  • 8.  RE: Save and Keep Working behavior in a Custom button

    Posted 11-18-2022 10:23
    Yes, I have no way to stop that pop up when you navigate away, as the record is now dirty.  You would think because the table is set to auto save before navigating away that it would not do that though.

    ------------------------------
    Mark Shnier (Your Quickbase Coach)
    mark.shnier@gmail.com
    ------------------------------

    Original Message


  • 9.  RE: Save and Keep Working behavior in a Custom button

    Posted 11-18-2022 10:37
    Yes, and I do have that set in the table properties. In fact I think tables default to that. 
    CGreene

    ------------------------------
    Christopher Greene
    ------------------------------

    Original Message