How to Lock columns so other users can't access/download attachments

Hi folks,

Question for you: Can the lock function to used on a column with the “field type” as attachment?

What I would like to do is be able to upload the attachment, but not have others be able to download the attachment i have uploaded.

Is there a way to do this?

1 Like

@Colleen_Carter,

Welcome to the Airtable Community!

I don’t think there’s a way to lock an individual field. Airtable’s management of user privileges is still pretty basic. But if I’m reading between the lines correctly, you may still be able to accomplish what you want. Try the following…

PLEASE NOTE: There’s a bit of a lie involved here. I’ll explain at the end of the post…

.

CREATOR VIEW for you

Create a view for yourself – call it “Creator View” or something – and include the Attachments field on this view. Then make it a personal view just for you.

You will use this view to upload your attachments (or otherwise edit that field).

.

LOCKED VIEW for your users

Now create another view that doesn’t show the attachments field. And make that a locked view.

Users with “editor” (read/write) access to the base will be able to edit data in the fields in that view that they can see, but they will not be able to change the configuration. As I said, you didn’t place Attachments on that view, and if it’s locked, editor-level users won’t be able to modify which fields are visible and which are hidden. And since they can’t see the attachments field, they can’t download attachments.

.

“Editor” privileges

Finally, make sure that the users with whom you share the database have only “Editor” privileges. Editors can modify data (so long as they can see it) but they can’t edit the structure of the base itself or its views.

.

Bonus points: View/download attachments but NOT delete or add to

Not what you asked about but perhaps worth mentioning. There is a way that you can display the attachment (so people can see it) but prevent users from modifying the contents of the Attachments field. To do this, do everything I suggested above, with one exception. Above, I said to design your locked view (the one normal users can access) so that it doesn’t show the Attachments field. The change you would make if you want them to see attachments but not change them (or that field) would be to make a formula field with a simple formula:

Attachments

And make that field visible on the locked view. Users will now be able to click links that will display the attachments. But because it’s a formula field, they won’t be able to delete the attachments or add any new attachments to the real Attachments field.

.

The lie?

Okay, the approach above is based on the assumption that your users aren’t very good at Airtable, or at least that they are not going to try to hack your base. If you worry that your users might actually try to hack the base, then the approach I outlined above might not work–more than that, Airtable might not work for you.

Why not? Because if your users do try to edit the configuration of the locked view, although they won’t be able to change that view, they will be offered the opportunity to create a personal view for themselves. And that view is completely editable. They can change the filters, show/hide different fields, change the sorts, etc.

This feels like a mistake in Airtable to me. I’m not sure what the point of locking a view is, if any user can simply duplicate it and then reconfigure it in their copy. But Airtable’s explanation of the four levels of access privilege does say that editors can “edit records and views (but cannot configure tables and fields)”. So I guess it’s not a bug.

Personally I think one of Airtable’s largest weaknesses right now is that it gives creators very limited control over what users can and cannot access or do in the base. What we really need is a more restrictive view than editor, perhaps called “End User”. It would like “end users” to be like editors but without the ability to create personal views where they can configure filters, visibility of fields etc.

.

Anyway, notwithstanding the “lie”, does my earlier explanation make sense? Would that work?

William

1 Like

Thanks William! Much appreciated!