BrianSeymour
Qrew Assistant Captain
Joined 5 years ago
User Profile
User Widgets
Contributions
Re: New Forms - Mobile support
RickPutnamor QuickBaseJunkie do you know if the "new Forms" work on mobile yet? We have an existing table with a legacy Form and I was hoping to build out a new Form and roll it out to mobile users via the Set how different roles use these forms via the View/Edit/Add Form (Mobile) on the Forms of the table properties. I know by their nature the new Forms are responsive and should play nicer across viewports, however, the new style Form I created isn't available as an option the dropdown list of Forms. So what is the best practice to actually roll them out?!142Views0likes1CommentRe: delete field attachments
I was thinking about taking a similar approach, however, with an intermediate step to rename the file based on QB data and then Integrate Quickbase with Google Drive to move the file (to Google) prior to Quickbase deletion. We'd incur Pipeline step runs, but save storage. It's interesting we face these storage limits … it seems like there'd be more file storage features as QB has matured over the years. ------------------------------ Brian Seymour ------------------------------64Views0likes1CommentRe: Color row in calendar based on two user fields
What's up Ann? It's been a minute. In a Quickbase Calendar system I've build, we leverage a plain ol' text field to give end users the ability to specify their Calendar color. Then, we use formula fields to convert that color into a "swatch" for table reports and reuse that same color in Calendar reports. In your case, I'd suggest considering building a Color Code Formula Text field, then updating the Color-Coding section in your Calendar Report to "Use a formula" that points to [Color Code] field. That way you can reuse the color logic across multiple reports without duplication and makes future maintenance easier, as you can any necessary color revisions in one place to update everything! Here are some snippets and a screenshot for ideas. Also, check out Mozilla's docs for color reference. // Calendars::Color Available (Text) // This field expects a hex value or CSS "named color" option. Check Mozilla's docs for reference. // https://developer.mozilla.org/en-US/docs/Web/CSS/named-color#css_level_3_values // Calendar Events::Color Code (Formula - Text) // For use on Calendar Reports If ( // [Has Validation Error] = true, "tomato", [Is Booked] = true, [Calendar - Color Booked], [Is Tentative] = true, [Calendar - Color Tentative], [Is Available] = true, [Calendar - Color Available], // Default [Calendar - Color Unavailable] ) // Calendars::Color Available Swatch (Formula - Rich Text) // For use on Forms and Table Reports var Text base = "height: 12px; width: 12px; border-radius: 50%; border: 1px solid; border-color: #f7f7f7;"; var Text fill = "background-color: " & [Color Available]; "<div style=\"" & $base & $fill & "\"></div>" ------------------------------ Brian Seymour ------------------------------10Views0likes1CommentRe: Do unused tables related to currently used tables cause functionality problems?
I'd agree with Chayce from my experience. Any performance concerns are likely negligible, but that entirely depends on the complexity of your specific app and record volume. If you do want to remove them to clean up after your future-self and others, you could open a Support Ticket to request a copy of the app to have as an "archive" prior to removing the tables from the live app. Then, restrict access to the archive as necessary to avoid confusion. Alternatively, you could go into table settings and hide from the table bar to give the appearance of a slimmer app that may be a bit easier to navigate. And make the deprecated tables not searchable for the most part. Also be mindful of any cross-app relationships to your 25 table app. Those relationships require the linked apps to boot up too. Brian Cafferelli has written several performance related blog posts that may be worth your time. It'd be interesting if you used the Performance Optimizer several times to benchmark your app's current state, then remove the tables and re-run the Performance Optimizer to compare results. But, my guess is that you won't really notice a difference. ------------------------------ Brian Seymour ------------------------------11Views0likes1CommentRe: QuickBase reports taking too long to process
Are there any Formula Queries included in the report by chance? If the Performance Analyzer isn't shedding any light, then I'd consider opening a Quickbase Support Ticket, as this one may be kinda tricky to debug without access to your app. General advice is filtering out the most records first in your Report's Filters section, limiting the number of searchable field, avoiding complex Report formulas when possible and consider caching. Check out Brian Cafferelli's Give Your Apps a Tune-Up using the Performance Optimizer blog post for more details! ------------------------------ Brian Seymour ------------------------------53Views0likes0CommentsRe: URL Add Record then Save
It sounds like perhaps what you are describing is when creating a new record, the embedded report of related records, is not displaying as you're expecting. This is because the new record (in the process of being created) hasn't saved, thus doesn't have an ID under the hood. The related records can't be displayed until their parent record is saved linking their IDs together. Here are some things worth considering: You may check a box in your formula url by setting the field to 1 (true) e.g. &_fid_999=1 (where 999 is the ID of the checkbox) In Table Settings -> Forms -> Properties tab check "Show save & keep working choice" as Mark eluded Use Form Rules instead, to check the box when appropriate Consider a formula checkbox instead (that self checks when conditions are met)? Look into Pipelines to perform checking a box after the record is saved The latter seems like overkill for this situation For me, it's unclear which table stores the checkbox data from your example. And what specifically it represents. Anyway, hope that helps! ------------------------------ Brian Seymour ------------------------------22Views0likes0CommentsRe: Bring field "forward" to related table
In your screenshot with the question "Which Department or Division did you contact?" where you've selected "Airport" (in the top-right), what field is that on your form? I don't have much experience with the newer form builder (which you are using), but if you right-click on that field is that the Related Department field or the proxy you've set? Then, in your report screenshot, can you temporarily add Related Department to make sure that value (ID) is set as expected? Otherwise, are you sure that you've stored a Director's Email for the "Airport" Department? ------------------------------ Brian Seymour ------------------------------0Views0likes2CommentsRe: Bring field "forward" to related table
In your relationship screenshot, click the "Add Lookup Fields" button in the bottom-right. Then, add the Department's "Name" field (assuming that's what you are tracking in the Department's table and how a Surveyed User would intuitively select a Department). Then, once the Department - Name field is available on the Survey's table, I'd update your Related Department proxy to use the Department - Name. Next, include the Department - Name on your form, so when User's are completing the Survey, their actually selecting the Related Department's ID by visually selecting the Name (the proxy) when completing the Survey. Then, once the Survey record is saved, trigger your email to the Department's Director. Note, it looks like in one of your latest screenshots, you have a Department (Text - Multiple Choice) field in your Surveys schema. Is that necessary and is that what is creating the confusion? It's seems like that field should be removed? ------------------------------ Brian Seymour ------------------------------1View0likes0CommentsRe: Bring field "forward" to related table
In your screenshot of the Related Department field props, click the "Edit the Relationship" link near the top. Then, you'll be able to add "lookup fields" from the Departments table into your Customer Satisfaction Surveys table. Presumably, you'd look up the Department Name and the Director's Email fields so they'd be available in the Customer Satisfaction Surveys table. Then, change your Related Department's Proxy in your screenshot to Department - Name (or whatever makes sense for your User's to select the appropriate Department). Then, you could email the Department - Director Email when a new record is created. That all assumes there is a relationship already in place between where Departments have many Customer Satisfaction Surveys. If that's not the case, then you'd have to explore other workarounds such as creating a "Departments" Text - Multiple Choice dropdown where you'd pick a value that not related to anything and then use Pipelines to search through your Departments table to find the selected Department (to get the Director's Email). I'm reluctant to mention this last point! One thing at a time! Did the first few paragraphs make sense and are your two tables already related? ------------------------------ Brian Seymour ------------------------------0Views0likes2Comments