October 2, 2025 / 🥗 Bunch of usability improvements

Thanks. Yes, it works for the time being as is. If a future improvement allowed the relation to be filtered and sorted on the relation field definition level, the modelling/architecture UX would be better. :crossed_fingers:

I see your point, but admins generally are more cautious about causing data fragmentation and integrity violations, than non-admins. :slight_smile:

I see the point here, thing is we have project managers who are allowed to create new “teams” as we call them. However, we had several encounters where these project managers accidentally made new teams while they tried to link an existing one to their projects.

This is the same with projects, we had it happen that a project was created by accident, this immediately triggered a bunch of rules (like creating teams and sprints), and undoing that mistake was quite annoying.

Coming back to @Chr1sG option of permissions. Is it possible for people to view all data but not create new ones? I could not find this option, because even the lowest (submitter) access level can still create entities. If not then how would we block users from creating new entities?

One of our examples:

We have a database with Equipment, and a database with Bookings
If people create a new booking, then they should only be allowed to link entities that already exist. Ideally creating equipment would only be done by users with specific rights (like me as an admin), but i still want all users to see all the available equipment and be able to use all equipment in a new booking.

At the moment, when creating a booking or editing the equipment field it happens quite regularly that users accidentally create a new piece of equipment that does not exist because the Create option cannot be disabled.

2 Likes

At the database level, you can make someone a Viewer (or Commenter) and they will not be able to create new entities of that type.

Right, i forgot about that.
The access rights can be pretty confusing, as they stack, but not in this case (where submitters can submit, but the level above that cannot submit. My mistake.

For the equipment that would indeed solve the issue

Conditionally hiding entity-level views seems to be the go here (e.g., hide a view unless the user is in group A, or hide views if the entity is in a particular workflow stage)

I also think changing default view depending on who is entering, where from, or what stage it is in, would go a long way to making true workflow systems. I could see it being used as a multi-stage form, where each stage is only editable to a particular group (say an approval process that goes through multiple departments)

1 Like

That is already possible: September 18, 2025 / ⚔️ Specify which Entity View to open based on some field value

1 Like

What do you mean by ‘each stage is only editable to a particular group’?

If you mean that the permissions for who can modify an entity change over its lifetime automatically, then this is already possible. You can do this by having a field which links to the people (or groups) who should be able to edit the entity, and then use automatic sharing.
The field’s value can be set using a formula, or via automation rules.

There still seems to be a limit on how much can be imported with CSV import at once.
The “We support CSV up to 50MB” seems misleading, if it actually only imports about a quarter of a 1.5 MB, 10k rows file (no warning before or after..).

Also, I still have issues of dates importing wrong:

I have dd.mm.yyyy format, and I made sure that first row data has values in date columns which cannot be mm.dd.yyyy (e.g. 24.09.2025). Still, dates are completely messed up.. Testing again now.

Edit:

Importing 10k rows worked on second try, date format still a minor issue but easily fixed by changing date fields in import CSV file to US style mm.dd.yyyy

I’ve imported a csv with 300,000 records… so I’m not sure where the limit lies with what you’re importing. Might be a bug?

Indeed it did work this time!

I think it was last Thursday when it didn’t, might have been a bug.

And I was able to easily fix the date issue by changing the date format to US-style mm.dd.yyyy in the import file and re-importing with the update existing entities value’s by ID matching, love it!

1 Like

I also had a lot of problems with dates when importing, and to me, it worked only importing dates as a text, and then coping the whole column to the date column.

1 Like