I’m wondering if the below scenario is possible
We have entity of Project, which has Tasks. Those Tasks can have children Tasks as well.
I’d love a field or view on my Project entity screen that lets me see all Files or Documents that have been attached to all of the Project’s Tasks (sub Tasks or otherwise)
I can do a Lookup field on the Project, Look up from > Tasks, for other related entities (like Users, and so on), but I don’t see a way to Lookup related Files or Documents.
Any ideas?
Could try creating a calculated text field in the task: Files.Join(Name, ",")
Thanks for the response! I had considered something like that, however the downside is you lose the hotlinking to the files.
I’d love if a field could hold all subtask files and/or documents and still maintain the ability to click through to the linked resource.
My biggest gripe with Clickup (and there are a lot of gripes) is that it’s SO easy to lose a file in the multiple nested levels of lists, tasks, projects, etc. And their search is terrible too, so there’s that.
I’m hoping we might be able to “bubble up” all files and documents at the top “project” level, so that it almost doesn’t matter if a file gets attached to a task, a project, a subtask, whatever. It’s always visible at the top level.
Maybe there’s another way around this concern, but a roll-up field was my first thought.
Thanks for any ideas!
Yah it does seem like its not possible to interact with the files collection via a formula. Fibery currently seems prevent pretty much anything related to combining collections.
In terms of the idea I proposed, you can still get a nice list of files in your top level project entity. Just create a new view within Tasks relation panel that shows the filenames and filter out anything that doesn’t have one. Afraid that’s the limit of my skills!
Yeah, you know this is actually a decent solution – at least then you can click through to the Task if you know the file is there, and prevents it from getting totally lost.
I do wish Fibery would treat the Files and Documents of an Entity almost as another Database relationship you can pull from. It just feels like it “should” work that way.
I’m also toying around with making a “Resources” database, wherein an entity could contain an external link, a file upload, a Document, or whatever else. I think it might end up being a little clunky, but that’s the beauty of Fibery – you can pretty much make anything you want 
Hey @Karlitooo – I’m actually having trouble sorting out exactly how you did the above demo – Is the “Filename” field on the Task? And then are you looking it up from the Project (or whatever the Entity is in your case?)
You’ve already helped plenty, but if you have a few minutes to explain what you did there, that would amazing 
Happy to explain!
So two tables: Projects 1-to-Many Tasks
Tasks table
Files.Join(Name, ", ")Projects Entity
No specific fields, just scroll down to the list of related Tasks and where the “list” dropdown is, click to add another view which is a table.
Then add the filename field, and filter the table based on Filename is not empty.
You could also do some cute stuff around counting the number of files on a task and using an automation to set a date field “files updated” if the count increases.
Oh!! I get it now, I was thinking it was a calculated field on the Project for some reason – that makes total sense, and I love how this works.
While I’d still think it makes sense for Fibery to (eventually) treat Files and Documents as “just another database” that you can interact with in similar ways, this at least gives us some more visibility into those Tasks’ files for now.
Thank you @Karlitooo for the extra time explaining 
I actually love this idea and I think it should probably be turned into a proper Feature Request that can be voted on. I can move it over there for you if you agree.
More thoughts on this: ClickUp has (or is supposed to have) a whole file management area, which can be a very helpful thing. Fibery probably doesn’t want to have a full-featured file storage and management system like GDrive, etc., of course. But nonetheless file storage is an important aspect of many workflows. So files should ultimately be “first class objects” in the sense that they should be individually searchable, filterable, and otherwise addressable in some way (within reasonable limits). They should be attachable to objects, but also have their own identity to some degree. If this were the case you could then do all kinds of things, like making Smart Folders that effectively treat entities and sub-entities like folders and sub-folders of file storage, but ones that have all the rich context and functionality of Fibery entities of course.
Further to that, if you think about the recent Thread View feature, and this feature request: 1 Idea for threads: Thread that pulls comments from multiple entities you could easily imagine a similar feature that operates on Files. And perhaps there are even other types of “objects” that could be operated on in similar ways, with a View type that essentially can collate and display X data from referenced/filtered Entities in a particular way that is most useful to that object type. That’s basically what Thread View is and it’s kind of a brilliant adaptation of existing Fibery features and data. Seeing that concept extended to other things like Files would be excellent, i.e. a Files View that likewise has design, features, and functionality focused on the needs of files - list vs. gallery views (with thumbnails), collapsible folder-subfolder navigation, etc. Perhaps Ability to have all References to an entity and its children in one area could also be implemented in a similar way (depending on the original intent of that feature request, i.e. if it’s supposed to be in an entity or a stand-alone View).
YES! The way you’ve explained the possibilities that this would open up, I’m convinced it would be extremely powerful. If you wouldn’t mind creating a feature request, that would be amazing!
I have a dedicated ‘Resource’ database that functions as the only database with file attachments and URL fields to external resources such as Google Docs. (and Documents but I don’t use Fibery Documents because there is no need for it, simply use entities, I hope Documents get phased out soon.)
This means that in my Project entity I can have a field ‘Resources’ that lists all attached files from child entities.
It only works if you remove all file fields from databases, except from the Resources database.
It works best if you work with templates, rules and forms that automatically fill in the Resource Type and other metadata so that the UX is fluent.
This approach sounds like what I was considering doing, but it sounds like yours is far more robust than what I was planning. How do you handle the potential for multiple resource “types”, meaning a resource could be a URL, a Google Doc, an uploaded PDF, etc?
I love the native File implementation in that it provides a thumbnail of the asset to make browsing easier, but image some sort of view on the Resources within a Project (or whatever Entity) could accomplish something similar.
I also wonder… Would automations allow for the following:
When a file is uploaded to an Entity, then create a new Resources entity with the file as the new Resource?
That way you could still use the drag-n-drop interface to dump a bunch of files into a task, but then those would be converted over to “Resources” navigable on the Project level… may have to experiment with this…
By the way, I for one would love to see a webinar of your Fibery setup – I see all the ideas and feature requests you share on the board, and I’d bet we could all learn a lot from watching you discuss your workspace!
A Resource can have multiple fields, each dedicated to a resource type. A Resource has a relation field to the database Resource Type, which can contain entities named URL, Google Doc, PDF. Whenever a resource field is updated to contain something, an automation can link to corresponding Resource Type entity to the Resource.
If your use case is mainly about a limited set of resource types, for example only PDF attached and Google Docs, then having dedicated databases for each resource type can be more userfriendly.
Yes thats possible. I’ll give an example this week.
Maybe a video, in the future. Thanks for the compliments!