This website uses Cookies. Click Accept to agree to our website's cookie use as described in our Privacy Policy. Click Preferences to customize your cookie settings.
I think it would be nice to have the option to hyperlink with different text showing, like any basic HTML hyperlinking. Like I can even do in this forum if I needed to.
Visually, having the url just there isn’t appealing.
@Bill.French p.s. If you can voice your concerns in that other security thread I linked to, I would greatly appreciate it! :slightly_smiling_face: I’ve realized that this huge security hole applies to 3 different areas of the product:
Copying all of the records out of an entire table with one click.
Exporting an entire table with one click
Copying an entire base with one click.
All 3 things are available to all collaborators, even read-only collaborators.
Could you imagine me working with some of my huge corporate clients — like Yamaha Corporation of America — and telling them, “Oh, no worries, all of your employees can just steal all of your data with one click!” Lol. Wow.
A quick test shows that a filter cannot see the action content of a button. However, to me that makes perfect sense. I wouldn’t expect to be given the ability to do anything with the formula output driving the button because that’s not the purpose of the button. Under the current design, the button field isn’t meant to share data outside of itself. The data is only used by the button action. Maybe I just haven’t taken enough time on this, but I can’t think of a situation when I would want to extract the button data (i.e. the URL driving the button action) to use anywhere else. Perhaps later when other button actions are opened up, that feeling might change.
Right, I agree with this assessment. Buttons shouldn’t be searchable or filterable, since they’re not data. They’re really just a new interface element that provides clickable actions, which I think is great.
Of course, this leads into @Bill.French’s initial point, which is that buttons aren’t fields, so they shouldn’t be called fields nor be part of the field listing nor even show up as fields in a view.
My guess is that this was the simplest & quickest way for the Airtable engineers to add this flexible new functionality into the product, and it doesn’t seem to be problematic for now.
Although Bill is warning us that “simple & quick” additions often prove to cause problems in the future. This is absolutely true of so many “simple & quick” additions! :stuck_out_tongue_winking_eye: I don’t personally see this as a problem right now, but time will tell.
Buttons have an underlying formula for the url. They also have some computed properties (e.g. they can be enabled or disabled, depending on if the formula produces a result). So it could potentially make sense to filter for records based on the the output of the formula for the button. For example, show only records with buttons that are disabled. Now, that exact same formula could be stored in a formula field and filtered on that way, but that would require an additional field. Now, whether or not filtering on buttons actually works that way in this beta is a different matter.
(Does anyone have a link to a Airtable’s policy on discussing beta features on this community? I feel like discussion of beta features should be separate from other discussions due to the fluid nature of betas.)
I think as @ScottWorld has noted, you’re missing the point of the test. The purpose of this test was to simply understand - is a “button field” an actual field (like a stored procedure), or is it some sort of hybrid like formula fields? Apparently, it is the latter.
Indeed, but you might want access and control over the button input.
If you had an Airtable system with hundreds of buttons - like we often have with databases that contain hundreds of stored procedures - maintaining all of that business logic is far easier if the business logic can be managed like any other data. You can search, replace, document, debug, and a host of other activities if the actionable code is represented as data. The API can access it and treat it as data and the security model can block (or grant) access. This is not the case with Airtable formulas or apparently button fields.
On this dimension alone, I fear (for my clients) that we are creating a complexity of intertwined code and business logic inside hybrid fields that cannot be programmatically inspected, reviewed, searched, or easily debugged – and that seems like a dangerous path. If the integrated configuration of these fields cannot be managed except manually with human clicks and keystrokes, I think Airtable is setting a future of difficult to maintain and modify business and applications rules. The advent of the button field – however needed or well-perceived – seems to deepen an already present dysfunction of the platform.
Even deeper…
We’ve seen in this forum many cases where developers wanted desperately to export formulas for documentation or backup purposes. And many have wanted to automate the creation of complex apps where formula logic could be scripted and built dynamically. Hybrid fields make this almost impossible because they are not really fields. Button fields simply move the platform down that slippery slope a little further and those developers typically flee the platform as soon as they realize the architecture - while perhaps perfect for SMBs - is not so ideal for certain use cases.
I dunno - the more I ponder the implications of burying logic in places that only humans can access while forcing solution designers to expand the number of “fields” in every solution, I see a lot of paint and a very tight corner.
I agree. I think that saying that a button is a field type was probably a design decision based on convenience and ease (both from a design/development point of view, and from a user point of view).
Okay, now it’s finally clicking (no pun inten–…well, okay, maybe partially intended. :winking_face: ) You’re talking about the data stored at the field definition level, not the record level. Is that right? Granted, I’ve not yet used the Airtable API, but I can understand the desire to have access to a field’s definition at that level. However, if I remember some other discussions correctly, this is the issue with all Airtable fields, is it not? The current API can’t access any field-definition-level data for any field type, which makes this a higher-level problem, and not just one tied to this new field type.
Agree - and it’s likely based on some precedent - the “formula field”, a concept that I pretty much hated from the beginning and the forum shows plenty of evidence I’m not alone. :slightly_smiling_face:
Not entirely true. Various APIs are able to access schema information but for true fields, not hybrid fields. Ergo, hybrid fields bad; actual fields (with attributes) good. :slightly_smiling_face:
Sorry - UPDATE…
My original commentary was intended to question the higher-level aspects of this latest implementation approach by pointing out the many issues with this pattern, not this single feature. It’s a pattern that Airtable has followed before and is simply continuing with the advent of the new Button field which I think comes with some risks as noted.
You may be thinking of only the Standard REST API, which does not have access to any field definition data.
The Scripting API provides quite a bit of metadata, and even read-only access to some field definition data. For example, you can see the colors associated with select fields and the symbol for currency fields. It does not tell you the actual formula in a formula field, but it does tell you if the formula is valid.
The custom blocks beta looks like it offers even more access to metadata. However, I need to finish a few projects before I’ll have the time to take the deep dive into custom blocks.
