In the <https://app.permit.io/policy-editor> under...
# general
j
In the https://app.permit.io/policy-editor under resources I already have a resource named ‘client’ and I need to add another one named ‘clients’ but it will not allow me to add ‘clients’ The error toast says that a resource of that name already exists but it does not. Only ‘client’ currently exists. How to get around this limitation and have both /client and /clients resources?
p
Hey, thanks for reaching out ! It seems our team is a little busy right now, a human will be with you within the next hour or so. In the meantime, can I help you ?
o
Welcome 🤗 1. note the differences between the display name and the key for the resource. I'd guess that's the source of the confusion 2. @Ask Inkeep please help 3. please ask future questions in #C02RTML2WNN
a
Thanks for tagging me @Or Weis. I'll look through relevant sources and get back to you shortly.
The issue is likely related to the ​*key*​ vs ​*display name*​ distinction for resources. When creating a resource, there are two separate fields: (1) (2) • ​*Key*​ – A URL-friendly identifier (slug) that must be unique within the environment. You query resources using this key. • ​*Name*​ – The display name shown in the UI. The key must be unique, while the name can be more flexible. (3) ​*What's likely happening:*​\ If you created
client
as the key, Permit may be automatically generating
clients
as a variant or the keys are conflicting due to similar naming. Check the ​*key*​ field of your existing
client
resource—it might already be
clients
or vice versa. ​*Solution:*​\ Use distinct keys for each resource. For example: • Resource 1: Key =
client
, Name = "Client" • Resource 2: Key =
clients_resource
(or another unique key) , Name = "Clients" You can verify and manage resource keys via the API or UI by chec
To learn more, see the sources I considered: [[1] Create](https://docs.permit.io/sdk/golang/resource/Create) [[2] createResource](https://docs.permit.io/sdk/nodejs/resource/create-resource) [[3] Migrating v1 to v2](https://docs.permit.io/api/v2-migration-guide)
Thanks for tagging me @Or Weis. I'll look through relevant sources and get back to you shortly.
The previous response covered the key distinction well. To add more detail: When you create a resource, you define both a ​*key*​ (the unique, URL-friendly identifier/slug) and a ​*name*​ (the display name) . (1) (2) The key must be unique within the environment. Permit may be preventing you from creating
clients
because: • Your existing
client
resource might already have
clients
as its key • Or the system is detecting a collision based on key similarity ​*Workaround:*​ 1. Check your existing
client
resource's ​*key*​ in the Policy Editor (not just the display name) 2. Use a distinctly different key for your new resource, such as: • Key:
clients_list
or
all_clients
, Name: "Clients" • Key:
client_single
, Name: "Client" (if you want to rename the existing one) You can update an existing resource's name and other properties (though not the key itself) using the SDK:
Copy code
resourceUpdate := models.NewResourceUpdate()
resourceUpdate.SetName("New Name")
resourceUpdate.SetDescription("New Description")
(1)
Copy code
const response = await permit.api.updateResource(
  resourceId,
  JSON.stringify(resource)
) ;
(2) If you're still hitting issues after verifying the keys are different, this may be unexpected behavior worth investigating. In that case, could you share: 1. Which Workspace / Project / Environment you're using 2. The exact key and name of your existing
client
resource 3. The exact key and name y
To learn more, see the sources I considered: [[1] Update](https://docs.permit.io/sdk/golang/resource/Update) [[2] updateResource](https://docs.permit.io/sdk/nodejs/resource/update-resource)
j
I understand that we can only have unique keys. So currently I have a resource that looks like this (this is working fine) and I need another where the key is ‘clients’ not client. and the name is ‘clients’ to match. Why is this not permitted? clients=!client Those are distinct strings as keys.
aarete.com default project (the only one) environment = dev
Anything else you need to check this out?
a
Hey @Jay Brown , let me check and will circle back to you soon
It works on my env, can I have your permission to log in to your workspace and try it myself there?
j
sure. Feel free to login and try it. What happens is it says it adds the key for clients then this little toast comes up. Here is a shot of the top of the screen for navigation
I’m having the same problem adding the admin resource in my UAT environment and this one is a blocker.
a
Hey @Jay Brown, We're investigating this - meanwhile I succeeded to create that resource through the API - https://api.permit.io/scalar#tag/resources/POST/v2/schema/{proj_id}/{env_id}/resources
j
Ok. I have a tool I wrote a while back for creating the resources. I will give that a try. thx.
z
@Jay Brown, we will fix this issue asap, and get back to you. It looks like it’s something related to default objects created in the system, not something that happened before. If something is blocking you, please write here and tag me.
j
I am not blocked now that I have gone back to using my user creation tool and resource creation tool (which both use your apis)
✅ 1
z
@Jay Brown, you can create resources now, the issue was related to the fact we create some default Roles per resource once you create a Resource. Since you have created a Resource named “admin”, there is a conflict between this Resource name and the Role name. In order to disable it you need to click on the settings button on the right side of the policy editor page. Inside there is a toggle “Assign the Default Permissions to every new resource”, I’ve set it to false. We are going to add docs for it, and disable it by default, it’s an old feature that’s probably not really useful. The reason that a Role and Resource have a conflict is related to some underline internal resources that we create which are related to how we implement ABAC policies.
image.png
j
ok. Thanks.