URL--Text to Display Feature

You bring up a great point here! I totally agree with you that they could be treading down a slippery slope by mixing data with schema, and by misunderstanding the difference between data and structure.

Especially in light of setting field permissions or future product upgrades.

For the time being, it looks like the screenshot below is how they have solved the field permissions issue for button fields.

Oh, I wasn’t envisioning anything — I am totally fine with how the button field is currently implemented. I was just partaking in the conversation. I don’t think we need buttons attached to other fields, as I rarely use that feature in FileMaker. My buttons are usually standalone buttons in FileMaker, so I like buttons being separate entities.

Certainly, mixing data with schema is a really bad idea, but button fields are about mixing actions (and business logic) with schema, not quite as onerous an idea as mixing data and schema. This is akin to stored procedures (in Oracle for example), the difference being that stored procedures are actually data values in fields that are interpreted at run-time. This makes it very easy to treat stored procedures like any other field and like any other data and thus, it doesn’t require complex recognition in the security model or any other aspect of handling schema operations.

And I don’t want anyone to get the sense that we [collectively] have a basis for second-guessing the Airtable team; they’re under a lot of pressure to make it different, make it competitive, and all while not breaking it. :wink:

However… this is a topic that is certainly worth considering and being aware of because I’m pretty sure the team is fully aware of the nature of data, structure, and actions. But they may be forced to make some difficult choices and as users, we have to be careful about that which we politely “force” them to do, right?

Recall that for many years, the team has been pressured across many dozens of feature suggestions to add various types of string parsers that were all fundamentally based on the inability to split strings into arrays. I don’t think they caved to all these self-interests and I applaud them for that. I cannot be as kind to them for not implementing Split(). :slight_smile:

To be a bit more precise about my assertions …

More clarity is needed concerning the vernacular (which is where my commentary began). This is not about “buttons”; it’s about actions. A button is simply (in my view) a poor implementation strategy for field and record-level actions. @kuovonne made this distinction earlier as well.

And yet, we already have many “buttons” (i.e., actions) attached to many of the fields - select lists, dates, links, long text fields, etc. Actions exist everywhere - why not make arbitrary “actions” possible as well?

Can you imagine an action configured for a specific field that would do things like this?

  • Right-click, search the web for the value in the field.
  • Right-click, search the current table for the value in the field.
  • Right-click, search the base for the value in the field.
  • Right-click, replace the value in the field with the title-case version of the string.
  • Right-click, take the value in the field and pass it to an external web service returning a more complete value for that field.
  • Right-click, transform the value of a long text field to summarize the content.
  • Click and pass the value of the field to a function or a script block.

This approach would probably achieve all that you’d ever want a “button field” to do without conflating the fundamental aspect of your schema design with hybrid “field” elements.

With this commentary [nudge], I am simply suggesting that Airtable resist adding hybrid field elements and instead follow a consistent and platform-wide approach that expands the opportunity to add new actions and event handlers for all objects starting at the most granular levels (a word in a text field), the field value itself, the record, etc.

I’m a bit late to this fascinating conversation, and at first I was totally on board with the points you’re making, @Bill.French. However, I saw this:

…and then later this:

Aren’t both formulas and buttons in this same vein as Oracle’s stored procedures? A formula outputs data at run-time. Change the data in the fields used by the formula, and the formula outputs new data. The URL tied to a button is driven by a formula, so it’s in the same category as I see it.

I get what you’re saying re: adding the ability to tie actions to other field types, rather than making a field type that appears on the surface to be all action. However, the way I look at it, buttons do contain both data and action. Without the data—the URL created by the button’s formula—the action can’t act.

1 Like

It’s a good question, but I think the implementation may actually be quite different. Unfortunately, I cannot perform any tests because I have not been given access to the beta.

One test that would be interesting and quite telling about the underlying implementation – can we filter based on the action content of a button? If yes, then your assertion is a good one, and I would be a little calmer about this hybrid field direction. This of course is notwithstanding the idea that – unlike stored procedures - there is an overt UI component coupled with the action “data” and I’m guessing you can’t not have a UI control appear in a button field.

Another test that would useful is to understand how buttons are exposed (if at all) in API results? If they are hidden, they’re not likely data fields.

To be clear - my suggestion that button fields are “akin” to stored procedures was the closest parallel I could think of in a true database environment. They are certainly similar because each approach creates the ability for late binding logic. But given the test I outlined above, that should tell us if your proven hypothesis would have a calming affect on old developers like me. :wink:

Ooops! I forgot to address this observation.

Indeed, and I have no beef per-se with formulas except that they are “fields”. :slight_smile:

As implemented, each formula can generate field data, but an existing field can’t use a formula. That’s my long-standing complaint about this design and I believe it’s all related to these hybrid fields. If you need a field that is based on a formula, why not make it an attribute of a real field? This exposes the field to the schema, allows you to manage it like any other field within the schema, and provides an opportunity to create very succinct database structures.

@Bill.French, for me personally, I just don’t see most of the things that you mentioned as a problem. I’m really sorry, but I don’t.

Why? Because these seem like tiny issues that are subjective, whereas I feel like we have MUCH bigger objective fish to fry, such as this GLARING & GIGANTIC security hole in Airtable, which allows ANY COLLABORATOR (including read-only collaborators) to steal 100% of a company’s proprietary data with one click of a button:

I mean, now this is a REAL issue that we have right now, and it’s a major SECURITY issue. If you could chime in on that other thread about that other issue, I would greatly appreciate it! :blush:

1 Like

LOL! I agree 100%. We often get into the weeds about [seemingly] obscure and meaningless debates. Security is a big fat Grouper in fry pan. In that sense, you are clearly a voice of reason - the adult in the room. I promise to spend a few cycles pushing that requirement.

However… like security - certain design choices can impact the ability of a platform to achieve the security required. Just sayin’ … I think you actually caused me to think about security in the context of hybrid field types.

1 Like

This is such a good point. Design choices do affect security, and I do believe that we will be seeing future security issues based on today’s poor design choices.

Absolutely, I can envision a user interface where developers can attach any action to any field/control. However, I feel that this sort of functionality needs to be implemented carefully.

  • Have a special view for fields/controls with these actions. Do not implement these customized actions in the grid view.
  • Make sure that editing of these actions is limited to people with creator permissions (not just editor permissions).

This beta for the button field is very new and subject to change. I don’t think that we can tell much based on how buttons interact with filtering or the API at this point. Maybe the implementation is incomplete or maybe there is functionality there that will be removed or changed.

Also, the support page with info on the beta only shows one action type–open url. Currently this action doesn’t really add new functionality–it just makes it prettier. One can already open urls by clicking on them.

@Bill.French p.s. If you can voice your concerns in that other security thread I linked to, I would greatly appreciate it! :slight_smile: I’ve realized that this huge security hole applies to 3 different areas of the product:

  1. Copying all of the records out of an entire table with one click.
  2. Exporting an entire table with one click
  3. 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.

2 Likes

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.)

1 Like

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).

2 Likes

Okay, now it’s finally clicking (no pun inten–…well, okay, maybe partially intended. :wink: ) 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.

Or am I still missing something?

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. :slight_smile:

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. :slight_smile:

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.

FileMaker has always had a formula field, and it has been working amazingly well for them for 35+ years. What is the problem you see with formula fields?