ContributionsMost RecentMost LikesSolutionsAPI_PurgeRecords on a Connected Table?Is there a way to delete all the records in a connected table with Webhooks? I am trying to use API_PurgeRecords to accomplish this, however I keep getting Error Code 3 saying: <action>API_PurgeRecords</action> <errcode>3</errcode> <errtext>Insufficient permissions</errtext> <errdetail>Oops. You don't have permission to access that page</errdetail> I am assuming QuickBase doesn't allow this call on Connected Tables, as the only way I see to delete the data is to use the App Management section... but I really need to be able to delete this records automatically via a webhook instead of manually.Re: URL Parameter ""rl"" Prohibits RedirectURL from OccurringEdit: The Pastebin has been updated so that we only remove the_rl=_ urlparameter only when we are editing a record. If you want this behavior to happen on all record view types, just remove the_&& isEditing_ part of the last conditional.Re: URL Parameter ""rl"" Prohibits RedirectURL from OccurringThanks for the reply, Dan, helped me remove the thought that I could handlerlthe same way I handlez. We did come up with two solutions, which are laid out below. Both listed with their Pros/Cons for anyone that may need to overcome this "feature" in the future. --- Solution #1: Simply create a newFormula - URLfield that creates an edit (a=er) link to the record, this way you can moderate which URL Parameters are added. Then you will need to add this new field/link/button (I'll refer to it as the "Edit Button" here out), to all the reports you know a user could access the record(s) from. In addition, you need to edit the reportstonot show the native "View" and "Edit" links. Now your users will use the new "Edit Button" you created to edit these records and therlparameter will not be present so theRedirectURLwill be respected. Pros:A user can go directly to a record from the forms we updated and not have any extra page refreshes, as well as the RedirectURL will work every time when coming from those new "Edit" buttons. Also, this is a "no-code" solution, that only requires aFormula - URLfield. Cons:You have to know, and moderate, all the places a user may come from to view/edit a record. If a user finds or creates a report, that was not updated, therl=parameter will still exist and yourRedirectURLwill not be respected. --- Solution #2: Using the Image Onload technique, load a code page.jsfile to the form via aFormula - Rich Textfield(The code for the imageonloadtechnique and the code page are included at the bottom). In the.jscode page, I have a function that will take the page's URL, remove therl=parameter and then refresh the page without it. When the page refreshes without therl=parameter the RedirectURL will be respected. Pros:Removes the necessity to know where your users may come from, eliminating any unknown edge cases. All that is needed is to include the Formula - Rich Text field on any reports you need theRedirectURLto be respected on. Cons:This solution does require the user to experience an automatic page refresh as the form loads if therl=parameter is present. However, if the parameter is not present, there will be no refresh. This solution also requires some custom coding but should be as easy as copying and pasting the values provided as no changes are required. --- Solution #2 Formula - Rich Text Value: "<img qbu=\"module\" src=\"/i/clear2x2.gif\" " & "onload=\"javascript:if(typeof QBU=='undefined'){QBU={};$.getScript('" & URLRoot() & "db/" & Dbid() & "?a=dbpage&pagename=removeRLParameter.js&rand='+Math.random())}\">" Solution #2 .js Code Page: https://pastebin.com/2rWgEzjkURL Parameter ""rl"" Prohibits RedirectURL from OccurringI have a form that when the status is set to "approved" I update theRedirectURL input to point to a code page I have created that takes care of automatically creating records. However, whenever a user comes from a Report Link to this form theurlparameterrl=is added and this seems to override the RedirectURL... How can I tell the form to ignore therl= so that way I can make sure the form goes to my code page wheneverRedirectURLis set.Re: Redirecting After Hidden ""RID"" Input Changes on New RecordsSo I do already have the newly created [Record ID#]_at the point I do the_window.location.replace()_. Right before Quick Base redirects you,_<input type="hidden" name="rid" />_updates it's value to the new entries_[Record ID#]._ Really my main question is, at this point, since the record has obviously been created at this point - because I have the_[Record ID#]_- would I be skipping a Quick Base process, other than its native redirect, by doing a manual_window.location.replace()_? No worries if you don't have the time, I really appreciate your help today. I might try to by pass this issue by just making my own AJAX call to my code page and allowing Quick Base to do it's native redirect.Redirecting After Hidden ""RID"" Input Changes on New RecordsSo the task I have been trying to accomplish entails that after a new record is added, we need to use_API_CloneMasterDetail_to copy a template record's report link. The main issue I ran into with this was obtaining the new record's_Record ID#_ before the form redirected to my_RedirectURL_. I found though that there is a_<input type="hidden" name="rid" value"" />_where the value is a long integer (no idea what it represents), when adding a new record and is the_Record ID#_ when messing with an existing record. For new records, the hidden input changes_right_ before the redirect takes place. So, I wired up an event handler to track when the hidden input changes to the new_Record ID#_ and then I_window.location.replace()_to my code page with the new_Record ID#_as a URL Parameter. While this allows me to run the_API_CopyMasterDetail_ request as desired, and the new record is created with the new copied report link, I wanted to check if anyone knew if redirecting this way at this stage after the hidden input changes would break/not run an important Quick Base task? Or, is redirecting manually at this stage pretty much the same as letting the_RedirectURL_ do its thing? The reason I can't use_RedirectURL_at this point, is updating the_RedirectURL__after_ the hidden input is updated doesn't seem to get respected when Quick Base decides to redirect - it uses the old value before the hidden input was updated.Re: What Does This Hidden Input Do, and Is It Safe to Remove for a Specific Use Case?Awesome, I appreciate the quick response! Thank you for the insight.What Does This Hidden Input Do, and Is It Safe to Remove for a Specific Use Case?I am adding some functionality to a form that has a field that quietly updates the RedirectURL to a code page we have created. To get to this form, a user comes in from an "Add Entry" button on a record view. When we save the form, the RedirectURL is not respected and instead, we are taken back to the record view. I was troubleshooting as to why, and came across this hidden input that, when present, stops the RedirectURL from being respected. However, when I remove said hidden input, the RedirectURL value is respected and I'm taking to my code page. The hidden input is: input type="hidden" name="z" value="ddbm" I assume based on the tests that this just tells Quick Base to return the user to the record view the request originated from. Is there anything else special about this hidden input? Or can I safely delete this input dynamically when I need the RedirectURL to be respected even when the request originates from a record view? Couldn't find any documentation on it from searching Google, so I would feel a lot more comfortable if I just got confirmation that removing this element won't break anything.