July 25, 2024 / Entity access explained, markdown import, hidden Fields section

Understand who has what access to Entity and why

entity-access-explained

There are numerous ways how someone might receive access to a Feature, Task, or Client:

All of these sources combine and merge, making it hard to tell the final access for a given person. Does everyone who should have access have it? Is there someone who shouldn’t have permissions but does?

To make the access audit easier, we’ve introduced a drill-down to individual users and capabilities. Expand a particular user to see where a certain capability has come from.

Automatically share Entities with those who create them

Previously, Created By has been excluded from the automatic sharing via user relations — now it joins the party.

Author access will become truly useful with the upcoming Database access but there is one use case that already makes sense: enable the automatic access for Entity creators to ensure they won’t lose access to their creations in case their access to the parent Space is downgraded or revoked.

Unlike other relations, access via Created By doesn’t support custom access templates or extending access. On the bright side, the author access can be revoked per Entity without clearing the Field value.

Import markdown and plain text files into a database

You can import a markdown file or a zipped markdown file structure directly into an existing or new Fibery database instead of importing them into a document. Databases over documents have many advantages, so we encourage our users to use this method.

Paste markdown into Fibery’s editor

paste-md-into-fibery

In addition to a full-scale import of markdown files, we now also support simple copy-paste of markdown from another tool.

Paste a markdown doc into Fibery’s editor — and it will automatically be formatted. If you don’t want the automatic formatting, paste using the Cmd+Shift+V keyboard shortcut or use the code block.

Hide empty Fields from Entity View

hide-when-empty-entity-view

The Hide when empty Field setting is now available on the Entity View. Selectively hide Fields in Compact sections when their value is empty to streamline the UI.

As usual, this option is available under the Manage Fields & Layout menu and works for both 1-column and 2-column layouts. When some Fields are hidden, a collapsible section appears so you can access those Fields.

:butterfly: One-liner improvements

  • Automations: we’ve replaced GPT 3.5 with GPT-4o-mini as the default model.
  • Integrations: when editing integration settings, if you click away from the window, a popup will appear, asking if you want to discard changes or continue editing. This prevents accidental loss of unsaved settings.
  • Integrations: we’ve added Edit Fields to the Sync menu item to the DB’s context menu to quickly access the integration Field mapping. With this change, you will save at least four unnecessary clicks.

:shrimp: Fixed Bugs

  • Whiteboard: child entity doesn’t get linked to the parent if you draw relation line from parent and add child via search
  • Don’t show No value placeholder in edit mode for numbers
  • Mentions: setup units button is available for users who don’t have permissions to edit it
  • Self-Relations Unlink All doesn’t unlink all and Relations popup doesn’t show every relation
8 Likes

Thank you for this.

Somewhat related in terms of hiding things to streamline UI - are there plans to allow to hiding of the “No Entity” rows in smart folders that have multiple levels? I really don’t understand why it doesn’t get hidden automatically if there’s no orphan entities found.

testsite-ca-—-Site-Fibery

2 Likes

Nice work!
Hope that allows me to troubleshoot why entities I created today were not visible to my teammate who was assigned. :slightly_smiling_face:

1 Like

Really like this one! :heart_eyes::heart_eyes:

However: I just noticed that for all formulas the setting ‘hide when empty’ has been turned on.
image

This really ruins our workspace :sweat_smile: We have very detailed wikis per entity which explains how fields are working, when to use what etc.

We always start with ‘fields on top of the screen’ and explain from top to bottom each field. Currently all formulas are hidden by default, which is very confusing since the screen doesn’t match with the wiki anymore.

We already had big problems after the release of ‘total rows’. Since the total rows were turned on for each view although it wasn’t applicable.

(We’ve needed to change/check more than 500 context/relation views and we still find total rows in places (like embedded views) that don’t make any sense. Plus the settings are not part of the template so we need to change it for each client that we onboard (as a partner). Which is not doable and therefor we are postponing to onboard them).

Please don’t let us need to check all (hundreds) formulas in the workspace to manually undo the ‘hide when empty’ setting :sweat_smile:

And more overall: please don’t release changes that impact current views/settings/behavior that suddenly changes the whole workspace after a release. That’s the recipe for a panic attack (both for admins as for users) :see_no_evil:

4 Likes

Happy to see new Improvements on entity access that can be configured through many ways.
However it seems to me we are still missing the obvious « database level » permission feature.
When do you expect to implement it ?

All of the features introduced in this release are pretty powerful, thank you!. They solve a number of my standing issues. :hugs:

1 Like

Hooray for much better Markdown import/overall support! :raised_hands:

1 Like

Finally, thank you for fixing this

Before this update, we always hid read-only Fields with empty values, including formulas, irrespective of your Show empty values View setting. Now they are hidden when empty by default but you can change that.

So nothing should have changed on your Views with the update. If it has, please ping us via Intercom and let’s troubleshoot.

We understand that every breaking change has its cost and usually we manage to avoid those.

Can we guarantee that breaking changes won’t ever happen? Certainly not. Sometimes we believe the majority of users benefit from an update and we roll it out en masse. Sometimes the cost of a seamless migration is so high, that we decide to ignore some edge cases.

If we had never released a breaking change, Fibery would have been a much worse product now.

1 Like

Unless something goes terribly wrong, in the next couple of months. The development has already started.

1 Like

Not for 1 column views.

What I mean is:

“When you release settings; don’t just turn things on when that wasn’t the case”.

That I understand since I have an IT background. So it’s just about the settings :heart:

I’ve send you guys a message via Intercom!

Hey! We will push a hotfix to disable this setting by default (including read-only Fields) for Entity View :pray:

5 Likes

Awesome, thank you so much! :heart_eyes:

Re: Sharing… has anyone asked for the ability to share items on a per item basis, but still see underlying data?

For example: we would like to share specific roadmaps and views with our leadership. But to do so, they (seem to) have to have access to the underlying data (products, components, features, feedback), meaning that they see more than we’d like to them to.

Thanks!

1 Like

Views sharing is one of the last item in our permissions scope. So far it is not possible to do that easily. One workaround is to create a separate entity like Public Feature and copy SOME data from Feature via automation rules. Then you can give access to this Space and Features data will be hidden.

We don’t mind that people would have access to data… it’s other Spaces that we’d like to hide. For example, we want to put these roadmaps and views in a separate Space and only allow leadership to see things in that Space; not the Space where the data actually resides. I’m not sure if this would help you narrow the scope of your permissions update.