I’m setting up public space like Fibery’s roadmap, but for apartment listings. Listings can be checked as “Public” and it creates an identical entity in the public space.
The problem is when a listing is rented, then a year later it might be back up again. I can have the automation delete the listing from public, then make a new one, but then the URL is different. If i can either set the public ID when i create (so that the url stayed workable), or restore the old one from trash, that would be fantastic.
If i just set it to a state “archive” and filter it, it’s still accessible to the end user by api, or via navigating to the space URL with nothing else. Example: Fibery
Is it possible to set the public ID when creating via API? Maybe adding the “Option+Click” to allow to set fields like Public ID and Rank, and others that are only accessible via Scripting?
Public IDs are a user facing UUID. They have to be unique per entity.
They’re not a traditional number column.
Why does it create a problem if the end user can gain access to an archived listing?
Yeah, I see. But if the other entity is in the trash is it not still unique then? I just tested it and indeed we can set the Public Id if its created with a script, as long as the old entity is in the trash. This way it just aligns more nicely where the backend ID’s are exactly the Public IDs. It does create problems with restoring from trash, where the old entity, and I also see that it can not create public IDs greater than ones that exist… Weird…
"createEntity: Cannot create entity {{entity}} of “Space/Database” database with “fibery/public-id” field value 15 greater than last “fibery/public-id” field value 13.
Might be able to get this work with some scripting then. Where it creates a public entity the first time, then store its public id in the private space, and next time it will create with a script using the public id instead of making a new. But that means they gotta pay for the pro plan…
The reason I don’t want the public to see the archive is because its sensitive info. They would be able to deduce how many apartments I’m renting in total, per week, per month, etc. They would see a list of all apartments I own. They would see photos and floor plan of houses that someone currently lives in. Whatever isn’t on the market should not be able to be public.
Once something has been on the internet, I don’t think you can guarantee that it won’t be accessible at some point in the future (think wayback archive for example).
Hmm in the US this is publicly searchable info in the states (see streeteasy.com) so I can’t say I’m familiar with the need for privacy but I do have an idea!
Clear the contents of public pages once the status changes - you already have a private database that is the source of truth for the info. Once a public listing is marked as filled, then clear the contents of properties and rich text fields.
Just want to chip in here and say that, in general, it should not be possible to create an entity that reuses a Public Id that has previously been used, and this ability (loophole?) to do so via API may not remain possible in the future, so I wouldn’t want you to rely on this as a mechanism to solve your needs.
I understand the reasoning behind this: A unique ID should always point to the same resource and not to another in the future. This is also a REST principle if I remember correctly.
However, I discovered - just like @RonMakesSystems in his previous post - that setting the ID of an entity during creation is possible via the API. This will most likely not change in the future and can be relied upon, as it is a necessary for creating an entity:
When creating an entity, not all fields can be set during the initial create. Some fields like multi-user, multi-select or multi-relation can only be updated after the entity has been created. Now, in order to update an entity you have to know its ID, which is not available until it has been created. Unless the user can specify the ID during creation as part of the input.
Why is this important? When knowing the ID of an entity in advance by providing it as part of the input, the user can create an entity and update the multi- fields within one batch command. This results in a single database operation, which will trigger only a single webhook and a single automation execution. Otherwise, the creation would be split into a create operation and a batch update command, which causes multiple webhooks and automations to trigger, which can cause problems.
In a nutshell, I think you can safely rely on the Fibery API to offer the ID as an input to entity creation as this is needed to perform atomic entity creation via the API.
My comment was merely that the ability to set the ID to a value that has previously been used will likely be deprecated.
So yes, you can use the ID as an input to a create_entity request call, but you should expect the request to be rejected if that ID has previously been used.
I got this error: "createEntity: Cannot create entity {{entity}} of “Space/Database” database with “fibery/public-id” field value 15 greater than last “fibery/public-id” field value 13.
That’s not a permissions error (meaning you are able to)
Rather, Fibery is telling you that the entity you tried to create has a public id value that his too high. The error tells me that Fibery is expecting entities to be created in sequential order with no skips.
Doesn’t seem to be working…
“Create new entity” failed
createEntity: Cannot create entity {{entity}} of “Home/Testing” database with “fibery/public-id” field value 2 greater than last “fibery/public-id” field value 1.
I made a new space DB, only one entity. I’m trying to make a new entity with Public ID = 2. This command: