Saving multiple files to a location defined by a single item relation

For me it’s a bug.

When using a ‘Multiple files’ picker component it’s not possible to define the destination column to save the files using a single item relation. I believe this should be allowed…

I have to do a workaround which involves adding a custom collection with a filter to ensure it has only 1 row ( the target destination row) then add the multiple files picker to the collection.

Maybe I’m not fully understanding. How is this any different than using a text entry component? You can’t configure any type of entry component to write to a destination through a single relation. You can use a Set Column action to set values through a relation, but not configure components to write directly through a relation. I believe the only exception is that components can write directly to the user profile.

True. So why couldn’t all entry components write to a destination that uses a single relation?

I would agree with that. Probably just never something that’s been considered before. Would be a good feature request.

3 Likes

I’d love this feature.

Moving this to Feature Requests so folks can pile on :slight_smile:

How do you envision this working?

1 Like

Being able to have access to the user profile row from absolutely anywhere is incredibly useful. The biggest downfall though is when you have situations where a user is not signed in. In that case, being able to utilize the user profile is not possible. One other problem with using the user profile table is that the user table can become heavy with things that are not necessarily related to user data, become redundant with multiple rows holding the same values in multiple rows, and extra processing overhead of computed columns within all of those extra rows.

User profiles cover 90% of all use cases, but not all of them. I’ve always thought it would be useful to have some kind global table. Something that works exactly like the user profile, but where the row isn’t tied to a specific user and can be accessible regardless if a user is signed in or not.

What I would envision is a special type of Glide Table. Let’s call it a ‘Global Table’. It would only allow one single row, but columns could be set up just like any other table. I also think there should be no limit to the number of Global Tables that exist within an app because each one could serve a specific purpose. The biggest advantage of these types of tables is that you could access them from anywhere, just like the user profile. You could read or update the row from anywhere. I think they could make custom forms a heck of lot easier to build and use. They could be used within native forms to write to, perform computations, and read from, all before a native form is submitted. They could hold dynamic values or static values, such as canned text, logos, color palettes, or anything else that could be used in multiple places.

Ultimately I’m thinking the exact same thing as what user profiles are today, but without the user dependency, along with the ability to have multiple global tables.

1 Like

Yes, local variables are something which is currently being deployed with the user table workaround.

Instead, variables should be based on a session.

Here’s a scenario;
A user is utilizing custom filters in one chrome tab, but since they’re utilizing their glide application to multi-task, they have a couple more tabs open to view/act on other data.

Since the filters are tied to the user rather than the tab/session, it’s quite an issue.

1 Like

@Eden Yeah, I think I’m going to reopen the Session Variable column request. The more I think about it, the more I realize we still need variables specific to a session rather than a user.

1 Like

:pray:
Ideally it would be more intuitive than Glide tables at the moment, since session/local variables are sorta like a canvas to perform calculations and stuff- think retool.

But not utilizing glide tables would involve too much, not worth the headache at the moment.

So yeah,

  • some kinda local variable/session column,
  • another checkbox for the text column, not even a table.

And then you simply tie the rollups and other columns to this, and Viola

1 Like

welp, running into user column limitations :sweat_smile:

I have an app which is public.
I am creating custom filters but since no user is logged in, I’m unable to filter my collection.
Since no user is logged in- I can’t utilize the columns in the users table to filter values from my collection.

Any suggestions?

Custom filters don’t have to require that a user be signed in.
If you want them to work for those that don’t sign in, you just need to avoid using the User Profiles table. Other than that, they should work perfectly fine.