Read-only viewers are in the roadmap definitely and development started. Arrival terms (not a promise) - 2-3 months
If this is a must for you now and you don’t want to pay for them - you can ping us in the intercom and we will find a workaround
Also, is it possible to embed a specific View into an iframe somewhere else, which would actually be a live view (i.g. with collaborative editing, showing real-time updates, etc)?
That request is pretty common, so we have that in the backlog although not sure about ETA
Hello, just bumping up this thread to see if this feature is still on the roadmap
For Product Management teams, it is likely that there will be a few editors that manage the backlog, roadmaps etc on a day to day basis ; and a lot of stakeholders that might need to look at the roadmap or release plan (or even the entity details !) on a read-only basis.
As a Product Consultant i still hesitate to recommand Fibery to my bigger customers as to share the roadmap broadly (which is a good thing in any org) you need to create accounts for everyone which is a. too costly and b. messy in terms of permissions.
Now that we have entity-sharing and document-sharing, it seems to me the missing piece is either :
view sharing (with a read-only link, same thing as documents and entities)
guest accounts, with the ability to restrict which view they get access to.
Are you waiting for the Blocks idea to be done (in which case views might be embedded into entities and it will solve the problem) or planning to add view sharing before then ?
This is in nearest future plans. There is no dependency on blocks. However before this we are going to implement better Views permissions to start “My Space” section in Fibery. Then we’ll get back to Free Read-only users.
I agree. We have been waiting in limbo since may or so without being able to move forward on any real adoption because of it. Fibery is still a toy we play around with sometimes because we can’t share everything from it within our organization and there is no way we could afford a full account for everyone.
One thing to note is the whole read-only thing isn’t the best approach to begin with. I really prefer Coda’s pricing compared to the other options for an organization like ours. They have Creators that can setup and modify the docs and tables within the docs, which go up in price as you need more enterprisey features/packs. The people that are just consuming or using the apps/docs that exist are all free, which means that it is easier to get adoption from a full org.
To be honest I don’t think Coda pricing model is sustainable in the long run. I expect they will rise prices in the near future.
As for read-only users, we are finalizing the whole permission model concept now and start implementation next week. It was an EXTREMELY difficult problem, since with all this flexibility there are many cases that we wanted to cover. I still can’t give any ETA, but on a positive side a team of 2 will be working on this full time now.
I agree, this could be huge. The pricing of tools like Productboard and Canny is insane to me for what they do, at least as compared to something like Fibery. Once Fibery is able to do public roadmaps, feature voting, and change logs, it could open up a whole new market.
I agree on coda’s pricing. It feels very very generous, bordering on unsustainable (even if good for users). I’m also not sure the distinction between a maker and a user is immediately understandable to everyone. I know when they announced their pricing I had to read the thing two or three times juste to grasp it : so i can add data to this table, but not change the text that is above it nor create a new one?
Coda’s model also does seem ill-fitted to fibery. There’s no “document as app” to speak off, unless you’re saying only the person configuring the app should pay and everyone else in the org getting to use the app for free? Would be nice for me, not so for fibery’s bottom line with only one or two pair accounts per customer ^^
Essentially having either open shareable link to a view, Google docs-like (bonus if can be protected with a password) or free guest users with limited permissions would fit the bill for me, and probably others?
Personally, I see both the need for fine-grained control over permissions (entity-based and view-based), AND the need for flexible pricing based on different roles.
All 200 of our employees need limited access based on their roles - some just need read-only access plus commenting/messaging.
20 employees need “editor” level access to different specific areas (create new entities and edit existing).
4 employees need admin-level access to everything.
200 outside clients need very limited access to specific entities and views. Ideally, these users can be given read-only access to some views and entities, and additionally have the ability to create and collaboratively edit certain specific entities/fields (e.g., create/edit/view specific fields in trouble-ticket entities, add text to a RichText field in Meeting Notes entities and participate in Commenting/notifications).
This is important for Pricing because:
we would not be able to afford paying the “full” seat price for all of these users.
we would gladly pay a lower price for a large number limited users, because of the value that it would add.
Because per-field permissions seems insane to me (how about you? ), I wonder if the idea of multiple layouts/views/tabs per-Type could solve your needs if those layouts could themselves be permissioned. So you could then just create a view specific to customers that showed only the data they should see and be able to edit.
If you wanted to show values without making them editable by everyone who can otherwise edit data in that layout, then perhaps the existing concept of a “Lookup from” field could be used, but looking up from the Type you are editing (and the value thus being transcluded or instantiated in read-only mode).
Or I guess it could just be its own type of simple permissions per-field that just specifies read or read/write globally, not per-user or based on any permissions lookup. In other words you instantiate a field shown on another layout of that Type, and you get to choose if it’s read/write or read-only on that layout. Thus anyone who has access to that layout can only read that field on that layout, if you so choose. Anyone who needs to edit that field could use a different layout where the field itself is read/write.
I’m curious if this makes sense to you, or if you have a better solution in mind.
When we introduce free read-only users (with commenting option as well), it will solve some of these problems.
The next step can be to introduce cheap, but limited access users. For example, limit an access to just 1 App and charge $5/user/month. We will never restrict fields access, it will be extremely hard to implement.
I agree that there is no single, best solution for everyone, as everyone has different needs and different ideals. And it does not make sense for you to spend lots of effort and complicate the product unless there is real benefit.
One extreme would be to charge for actual metered usage (CPU & storage).
At the other extreme is just one single plan with no flexibility - certainly that would disappoint many customers, but is simpler to understand and easier to implement.
That will work for many cases, if these free users are still subject to permissions that can restrict their views, and the notification system also works for them.
A user with access to only a single app is not ideal, because it really changes how I have to think about designing my Workspace. But it is a good direction. I would prefer a different structure, perhaps a user with write access to just one or two views.
The ideal for my own case would probably be metered usage some limited users, since I expect that mostly they will use very little. But I know that is problematic and hard to sell.
I don’t think it will be possible to implement easily. View in Fibery is just a window to the data and it can be very dynamic. Imagine you change one filter and instead of 5 entities a user now sees 1000. It is possible to implement, but so far we are hesitant to move into this direction. We want to rely on more stable structures (app, type, entity).
I’m sure this can also work well for my needs, when coupled with per-entity permissions.
So I will create an App just for my “external client” users, with specific Types in this app which are their sole access to our system, consisting of Relations to any fields in other apps that they need write access to, and Lookups to other fields that they should only have read-access to.
With per-entity permissions, this is a workable solution; but without it, every client user is able to see every entity exposed through this app - e.g., they can see our other clients’ entities as well as their own.
I do need per-entity permissions to limit these “client users” to only have access to their specific entities. Otherwise I would need to create a separate app for every such user, and that quickly becomes unwieldy.