Allow any entity to be used as a comment

Big collaboration and scalability issue in fibery is that the comments are not like entities that can be listed or filtered across the workspace. The comments system is something we therefore do not use. I tried workarounds with scripts, but essentially thats not really working. I actually tried to prevent the built-it comments by creating a Comment database, but that has multiple limitations related to what comments should be able to do.

I think fibery needs ANY entity to be able to be used as comment and that a new dedicated comment thread view that supports the regular databases in fibery is added.

I wonder whether you saw anything like this in any other system.

Linked:

I think that the comments UX is lovely, and would love to see this as well. I haven’t seen it done in another system, but Fibery isn’t like any other system :wink:

Then imagine the Quick Add ui as the comment (with the extra fields you can add at the bottom of the comment).

Also for access templates comments can not be hidden / not given access to. They have a lot of limitations atm.

All in all, this could be a game changer and be great when it comes data entry as well.

I would love Fibery to be as “pure” as possible. Giving as much power to the admin to build and create based on their need. I think, @mdubakov, you notice this as well when (soon) depreciating documents. I see a future with depreciated comments (changed to thread view) and whiteboards as fields (just like a document, RTF, is a field), as well as a graph view (similar to the multi-entity relation in whiteboard now).

NOTE: I’m not sure about in-line comments and whiteboard though. You could bring back references and you could highlight then create a comment entity. Idk. And you could set any database as “comments” in a whiteboard and it will just then create the comment and be related to the entity. I’m less bothered about these, not sure about you Yuri?

1 Like

Its actually hard to find a tool that does not have a scalable comment system.

These tools offer built-in, seamless comment aggregation across teams, projects, or spaces:

  • Commented io: Yes, via workspaces and projects (though search scope is less explicit).

  • Jira: Yes, via JQL across projects.

  • Confluence: Yes, site-wide across spaces.

  • Slack: Yes, workspace-wide across channels/DMs.

  • Trello: Yes, org-wide across boards.

  • Asana: Yes, workspace-wide with Conversations tab.

  • Microsoft Teams: Yes, org-wide across teams.

  • Viafoura: Yes, community-wide (less team-focused).

  • Drupal Core Comment: Yes, site-wide via Views.

  • Comments Entity: Yes, site-wide via Views.

  • Comment Mover: Yes, site-wide post-conversion via Views.

  • Notion: Yes, workspace-wide search.

  • Airtable: Yes, base-wide (not org-wide, a slight limitation).

  • ClickUp: Yes, workspace-wide with Chat view.

  • Coda: Yes, workspace-wide via shared docs.

  • Smartsheet: Yes, workspace-wide search.

  • Monday com: Yes, workspace-wide search.

Tools with Custom Aggregation

These require scripting, API work, or custom setups to achieve aggregation, offering flexibility but not the native ease of top picks:

  • Commento: Yes, via custom API (not native).

  • Baserow: Yes, via custom dev/API (not built-in).

  • Grist: Yes, via Python scripting/API (powerful but manual).

  • Rowy: Yes, via custom scripts/API (Firestore-based).

Have you actually tried these tools, or is this list just what ChatGPT has told you?

I have used Jira, Confluence, Trello, Coda, Airtable and am not aware of a way to get aggregated views of comments across the whole space (which seems to be what you are asking for)

I am not going to explore all these tools to check whether what is stated is correct, but if you can show some example screenshots that represent what you are looking for, it would sure help

I understand your concern around AI based postings. Well, its co-created with me, and I’m discerning in how I use it.

I will wait for others to see if they need better comments here, otherwise leave it. To me, it is as clear as it can be that comments = team scaling = collaboration.
I will spend time on deeper research if more users chime in.

I used all tools listed (30 years of systems development). I cannot remember having the issues with comments that I have with fibery.

1 Like

There is no doubt that Fibery comments can be improved, and others will surely agree with you (I do too!)

but with respect to the specific critique

it would be useful to point to some example implementations from other tools that

If nothing else, it gives ideas that can be plagiarised! :wink:

Could you enumerate use cases where comments do not work? I have hard time connecting original request with this.

1 Like

I don’t really know what Yuri is getting at, but it reminds me of something I’ve done for my own system on Fibery.

I have a database I call “historic updates” and the title of each entity in the database is simply my update to the team. I date stamp it as well. So an entity may look like this: 2025.02.24 Commented on Yuri_BC’s post on Fibery’s community page.

That entity can then be link to any other task in my “Task” database. This works well for me partly because I can link an update across a whole bunch of related tasks if necessary. That’s a thing that bogged me down in many of the tools Yuri describes above - I comment on one task, but then need to make similar updates across related tasks. Because it’s annoyed, it just didn’t get done.

But with Fibery, I can actually be in the “Historic Update” and do a search for which tasks (or even other entities, like Projects) that I want to associate with the update. It’s really neat!

I’ve been trying to “weigh in” here but I’m quite lost. @Yuri_BC could you share what you mean by “scalable?” This post is hard to understand because both the terms and examples are so broad.

What problems and specific situations did the native comments fail? What benefits did the comments database have for you?

I don’t know what seamless comment aggregation means. But you gave ClickUp as an example and I’m familiar with that!
ClickUp allows tasks, lists, and dashboards (via a widget) to have their own comments sections. The chat view can live on any layer of the view hierarchy, which allows for chats to live outside of any one entity.
A few follow up questions

  1. Would a simple chat view in Fibery be enough to overcome the gap you’re identifying. That is a 1:1 comparison to the CU feature.
  2. Which part of that overlaps with Notion’s (or other tools) workspace-wide search? I don’t think it’s clear what search has to do with comments in this context.

I think the need this feature request is trying to solve for is the ability to comment in a shared space with multiple team members, and without being tied to an entity. But I could be totally off here.

That said, I also think a comment/thread like view of entities is awesome but a completely separate feature request.

If so, it sounds like something more related to async communication, no?
How close does the existing thread view functionality come?

I was perplexed by the creation of the thread view because I felt like it missed the point or at least, its a feature that and didn’t completely understand the user story.
From what I can tell, it bookmarks an existing comment section to the sidebar navigation. But a view is supposed to exist above entities in the hierarchy, so “thread view” is not a view at all. It’ a stylized bookmark.

That said, it looks like a work around would be the creation of a new database or using a “tags” database that already exists as a global reference in a workspace. Example entities:

  • Marketing Team
  • Watercooler
  • Announcements

Then use the comments section on each entity as channels. Each entity that is of interest/need to a team member can have its comments section bookmarked as a threads view.
I would recommend a separate database that is private to all users, this way access can be controlled on a per entity basis.

@Chr1sG what do you think?

You could say that.
Another way of looking at it is that, if Comments were stored as a normal database, a thread view is a bit like a feed view of Comments, filtered to only those comments that relate to a specific entity.

That is pretty much how it is intended to work, not merely a ‘workaround’(!)

Yep. Given that comments are tied to an entity, and a thread is a collection of comments related to a specific entity, you can decide who gets to see any given thread (and who can add comments to the thread) based on who can see (or comment on) the entity.