ContributionsMost RecentMost LikesSolutionsRe: Using arguments with "Call Another Pipeline" functionSo in a complete turnaround, I was later told by Quickbase support the exact opposite of what I was told in my first two inquires: Passing arguments between Pipelines does in fact work, and it works perfectly for my use case. I only wish it hadn't taken me an entire week of pulling teeth out of multiple support reps to get a correct answer. I now have a multiple pipelines chained together by passing the target record ID (and more) to the subsequent pipelines. The nicest advantage I have realized from this is the ability to have multiple variations of my "Step 1" pipelines, with various triggers, and have them all continue to one unified "Step 2" pipeline that has the same chain of actions for all cases. That means you can easily augment the trigger and initial actions without have to rebuild/duplicate the long chain of following actions that result. I will attempt to upload the screencast that was shared with me that shows how to do it. ------------------------------ Josh Weeman ------------------------------ Re: Pipeline triggerIt turns out there is a way around it, albeit a messy one. You have to use the Import/Export feature from the "My pipelines" screen to manually edit the YAML code for the alternate pipeline. Basic steps: 1) Configure your original pipeline as desired. 2) Configure a new blank pipeline with the desired alternate trigger only, don't bother creating any actions. 3) Exit the editor and go into the Import/Export screen for this alternate pipeline, and copy its YAML code out to a text editor. 4) Exit and then go into the Import/Export screen for the original completed pipeline. 5) Edit the YAML code you see by replacing ONLY the trigger section with the corresponding trigger code block from the alternate trigger pipeline that you copied to your text editor. Then click the "Import as new" button. This will create a third pipeline that is a duplicate of the original pipeline, but with the alternative trigger of the second pipeline. WARNING: In the few times I have done this, some things have gotten a bit wonky in the resulting pipeline, meaning some attributes of certain action steps have not copied over 100% correctly. So you may have some cleaning up to do after this process. Inspect the resulting pipeline very carefully and do multiple tests before running on important data. QUICKBASE: Please give us an easier, cleaner, less error prone way to achieve this! ------------------------------ Josh Weeman ------------------------------ Re: Using arguments with "Call Another Pipeline" functionGreat suggestion Mark, thanks. Pretty sure I can come up with work around based on that, but you're right, would be troublesome in a scenario where we might have multiple instances of the pipeline being fired off around the same time. Got an update from QB tech support: According to the pipeline developers, the ability to pass an argument between pipelines doesn't exist, despite the instruction text below the "Call another pipeline" object that attempts to explain how to do it. Surprising that they jumped the gun and published a reference to a feature that hasn't even been developed yet. ------------------------------ Josh Weeman ------------------------------ Using arguments with "Call Another Pipeline" functionI have been working with QB tech support to no avail on this one. I have created a pipeline to create a series of nested folders on Box.com. The list of folders to create has grown to over 30 in number. This is a problem since the maximum number of steps a pipeline can have is 30. So the only viable workaround that has been suggested so far is to call a second pipeline at the end of the first pipeline, and finish my routine in the second pipeline. In theory that would work, except that QB tech support now tells me there is no way for me to pass the record ID of the target QB record to the second pipeline, even though the (extremely limited) instruction that accompanies the"Call Another Pipeline" function clearly states you can pass arguments. If you can't pass something as fundamental as a record ID as an argument to the second pipeline, how can it perform any sort of targeted action? Any if the arguments won't allow for passing a QB record ID, what WILL they allow and why do they even exist? Has anyone successfully used this function with arguments? TIA. ------------------------------ Josh Weeman ------------------------------ SolvedRe: QuickBase really needs to build EXIF image orientation awareness into its image handling...I was basing my workflow comments off of what you've seemingly already built, not off of what's possible. I think we can all assume this functionality is possible. Having something built, tested, and demo-able is a different story.Re: QuickBase really needs to build EXIF image orientation awareness into its image handling...Seems like you have a small piece of a potential solution there. If I understand you correctly, you are uploading a stock PNG to a file attachment field, manipulating it via transform instructions that are hard-coded into your script (pre-determined rotate & flip), rendering the transformed image to a new PNG file, then automatically initiating a download of the new PNG to the client. In order to be a working solution to the EXIF problem I�ve detailed in my posts, this would have to be taken further. After a user uploads a JPG directly from mobile device�s camera app or camera roll, the solution would have to: Read the image�s EXIF transform data Rotate image according to EXIF rotate parameter, to correct for portrait, landscape left, upside down (0, 90, 180, or 270 degrees) Discard EXIF data, rewriting rotated image file with no EXIF Re-save rotated EXIF-stripped image to original file attachment field The last step is as a deal-breaker IMO. Having to upload the image to one file attachment field, download the image back to the device, then re-upload it to its final destination attachment field is kludgy at best. Frankly that's a even less sellable solution than the current scenario of QB natively uploading mobile photos to the database that appear to non-mobile users in the wrong orientation. (Which in itself is already unsellable.) Re: QuickBase really needs to build EXIF image orientation awareness into its image handling...If you haven't actually built it and shown it to work, then isn't it theoretical by definition? Moot point though. QB has assured me that this in on their radar and will be addressed soon. Makes little sense to put a scripted solution in place for something they plan on fixing in the near future.Re: QuickBase really needs to build EXIF image orientation awareness into its image handling...Agreed, the basic methodology behind a fix for this issue is very simple...all the more reason QB should have taken care of this years ago. However offering a theoretical user-scripted solution to the issue very much misses the point that QB needs to step up to the plate and address some very fundamental mobile usability issues if they are going to live up to the promise of providing a more seamless mobile-to-desktop experience. I'm all for employing script when it comes to enhancing or creating special functionality within QB, but I draw the line at spending my own time fixing basic functionality, like image uploads. Re: Quick Base Mobile is here!Good to hear, thanks Chris. Glad it's on the radar.Re: Quick Base Mobile is here!Exciting to see some forward progress on mobile. Unfortunately image rotation is still very broken from iOS-to-Desktop. Isn't the point of a native mobile app to be able to more tightly control the user experience and make things like this more seamless? Still a major deal breaker for any mobile app involving photo upload. https://community.quickbase.com/quickbase/topics/quickbase-really-needs-to-build-exif-rotation-aware... https://quickbase.uservoice.com/forums/111823-quick-base-product-feedback/suggestions/35235568-fix-i...