Permissions are not syncronized when collection is renamed

[jblevins1991]

Describe the bug

When renaming a collection, the permission is not renamed. Because this is happening, the endpoint for that collection is also not updated to reflect changes to the collection. In my example I created a collection named 'Blogs' but later renamed it 'Post'. Below are URLs for the collection.

Steps to reproduce the behavior

1. Go to my old collection name
2. Observe that an empty collection with a status code of 200 is provided
3. Go to my new collection name
4. Observe that a 404 status code is provided

Expected behavior
I expect that the permissions and endpoints be renamed to reflect the changes to the collection.

System

• Node.js version:
• NPM version: N/A
• Strapi version: N/A
• Database: Postgres
• Operating system: Ubuntu

Additional context
I installed strapi using the 1 click install on digital ocean.

[jblevins1991]

I decided to delete the collection and make a new one called Post. This is still an issue that is easy to reproduce though. Those links in the steps no longer are relevant though.

[lauriejim]

Hello! We are aware about that, I think this is the wanted behaviour.
I ping @alexandrebodin about that.
I found it weird too.

[alexandrebodin]

Hello @jblevins1991 Renaming is mearly an action of change the display name. We should be clearer in the UI.

This does not change the routes or the db table name to avoid breaking something if you started creating data.

A full rename is a file system an database operation. It is really destructive so we want to make sure the user does not make a mistake and uses the delete action. We could add this action in a CLI command maybe.

[jblevins1991]

I think there should be an option to rename both. I understand the benefit to not immediately renaming the endpoint as the work might not be planned within the same sprint the collection was renamed. However, most teams will not be happy with the added confusion and will want to align the endpoints with the collections.

[tmikaeld]

I just tried with renaming the display name and the collection name under advanced, then going into permissions and "Public". It still says the old name, even after restart.

Version 3.1.1

[alexandrebodin]

I just tried with renaming the display name and the collection name under advanced, then going into permissions and "Public". It still says the old name, even after restart.

Version 3.1.1

What model are you trying to rename ?

[jblevins1991]

I also just don't understand the point of not renaming the table in the database or the registered api endpoint. It just feels like this will lead to confusion between those who write content and the people developing the website. While this might be "intended behavior" it makes me feel like the product is somewhat immature. The endpoint, database table, and label in the permissions should serve as feedback that let's the content manager know that their changes in strapi were successful. I honestly thought that strapi had a bug in it or just didn't work when I saw that none of these things had changed, so I decided to go another route for my content management needs. I would be happy to contribute to the project, but I can't realistically contribute to something that the strapi team sweeps under the rug like "it's a feature, not a bug".

[alexandrebodin]

@jblevins1991 I'm sorry you feel this way. Let me give more context on how we see it.

Allowing a technical rename (file rename / database migration) through the UI makes it really hard to do the right operation as the server is still running (and connected to the db). We cannot simply create a new table and migrate while the app is running. This kind of operation makes a lot more sense as a CLI operation and would give more control.

That being said, We think that changing the display name should always be possible as in some cases it can just give more details in the UI without needing to change the unerdelying endpoint or db.

We must certainly make it clearer in the UI so people don't get confused.

[tmikaeld]

@alexandrebodin I assume that versioning is on the way as well, so it would make sense to have an overlap when changing API endpoints, as to now break previously versioned API paths.

[alexandrebodin]

@alexandrebodin I assume that versioning is on the way as well, so it would make sense to have an overlap when changing API endpoints, as to now break previously versioned API paths.

Sorry I'm not sure I understood your comment ?

[tmikaeld]

@alexandrebodin
Say we have an api URI: /v1/events

And we change events to happenings in a new version.

So we'll then have URI: /v2/happenings

While still keeping v1 like it was.

Suggested in the roadmap.

[alexandrebodin]

Ok I see your point. This is a whole other set of issues to solve but it is related :)