If I have a content type named article and I set access control permissions for certain roles to create and edit articles, then I go and rename the content type to magazine, if you go to access control you will see the permissions I gave to article are unchecked....
I would have expected the newly renamed content type to have the same permissions as the old content type. One wonders if you have other node access control permission modules in use, if they would have been affected too.....I can't say for sure though.
To reproduce problem:
1. Install Drupal 5
2. Create content type foo
3. Go to access control and give a role permissions to create and edit foo
4. Rename content type foo to bar
5. Now go to access control and you will see that the permissions you set in Point #3 above are unchecked.
I have set this to critical as I renamed a content type not realising the permissions were gone and then the client called me to complain because all users of that role could not create/edit the content type.
Don't ask why I renamed it, I just had to for the aesthetic reasons.
Also, this issue was posted for version 4.7 of CCK and it seems this bug leaked through to version 5.
| Comment | File | Size | Author |
|---|---|---|---|
| #18 | drupal6_alert_machine_name_change_345754_5.patch | 814 bytes | juampynr |
| #18 | drupal7_alert_machine_name_change_345754_5.patch | 770 bytes | juampynr |
| #18 | drupal8_alert_machine_name_change_345754_5.patch | 770 bytes | juampynr |
| #17 | drupal6_alert_machine_name_change_345754_5.patch | 814 bytes | juampynr |
| #17 | drupal7_alert_machine_name_change_345754_5.patch | 770 bytes | juampynr |
Comments
Comment #1
xamountActually, I am not sure if I posted this issue in the right issue queue....is this a CCK problem or a Drupal core problem?
Comment #2
yched commentedThat's for core, CCK doesn't manage content types, it simply ad fields to them.
Please update the issue description with the exact core version you're using.
Comment #3
xamountUpdated the version (drupal 5.10).
Also, I just noticed this too: I had a view filtering by node type. After I renamed the content type, the new node type in the view filter was no longer selected (I'll posted this as a separate issue in the Views issue queue #346053: Renaming content type screws up views filter by node type).
Comment #4
ultimateboy commentedMoving this to the 7 queue as that is where the fix will be applied. And, this is not technically a bug... but more of a usability issue (though I am keeping it under the node component)
This definitely is a pretty big issue. We should either warn the user that the permissions need to be updated, or update the permissions based on the content type name change.
Comment #5
xamountI think the permissions should be kept and also be told to the user.
So for e.g. when I rename a content type, the confirmation page tells me something like "the same permissions have been applied to the new content type".
Its sort of unbelievable that this issue was not picked up sooner though...
Comment #6
damien tournoud commentedSeems reasonable.
Comment #7
xamountis this a feature request or a bug? My opinion, its a bug. Changing the Category to bug. Change it back if you feel its necessary.
Comment #9
giorgio79 commentedI believe this may be a duplicate
http://drupal.org/node/346053
Comment #10
Tresler commentedI have to agree that a form removing previously set values when the user did not actively change them is a bug. If a node submit form removed the body of the node when I changed the post's title, would we consider that a lacking feature?
But yes, this is a duplicate of http://drupal.org/node/346053 marking it so, continue the conversation there.
Comment #11
Tresler commentedActually scratch that, as I see now that that conversation has veered towards views, and this is about access permissions. Let me install 7.x and check this.
Comment #12
Tresler commentedOk, confirmed with Drupal 7 head. IMO, this is fairly important, as it allows an admin to unwittingly expose large portions of their site.
It seems to me that content types should have a unique identifier that isn't the machine readable name. I, unfortunately, don't know how far reaching such a thing is.
I'm going to start a fix that ads a cid column to the node_type table, please chime in if you have an opinion on this.
Comment #13
webchick"IMO, this is fairly important, as it allows an admin to unwittingly expose large portions of their site. "
Er, no. The opposite. It means that users who previously had permissions to create and edit their own "articles" now won't have permissions to create and edit their own "news_stories" once the content type machine name is changed, until the admin goes back and re-enables the permissions.
I don't feel strongly opposed to a cid column. I'm not sure why that wasn't added to begin with, though. There may be a reason.
Comment #14
Tresler commenteddoh. Correct, I had that backwards in my head. Still think it is pretty important, but not as bad as I was thinking. Thanks for correcting me.
Comment #15
jody lynnI don't think we should allow people to change the machine names of content types without warning them on a confirmation screen that numerous unexpected results may ensue.
Comment #16
jbrown commentedYes - many bad things can happen if a machine name is changed.
Is there a hook for this? Modules need to be informed when this happens so they can update their data.
Comment #17
juampynr commentedAfter reading this thread and #346053: Renaming content type screws up views filter by node type I see that we least we could do is alerting the user.
Here are patches for Drupal 6, 7 and 8. 7 and 8 are identical. They all just add an alert when content type machine name changes.
Comment #18
juampynr commentedAttaching again patches. These are the right ones for each version.
Comment #19
juampynr commented#18: drupal7_alert_machine_name_change_345754_5.patch queued for re-testing.
Comment #20
hass commentedNewlines in translatable strings are not supported. Remove the line breaks, please.