I’m putting together a site for a client, and as they are going to be adding and removing job postings on a very regular basis, I guided them towards CMS and hosting with Webflow. The setup and such are perfect, super-cool and so forth.
The thing is, I notice of course that the collaborators can then access every single text block and image across the entire site, and edit it.
If I wish to restrict their access to certain elements, I know I can go to Editor Settings and disable “Allow Collaborators to edit this element”, but I wanted to ask — is this a cascading control? For instance, if I have a main container or div with multiple elements inside and I want to disable all access, or even restrict to one text box within (for example), can I turn the collaborator edit option off on the top-level container element and it disables all the items within (and then turn one back on within)?
It doesn’t seem so, because their check boxes are still active when I view them… so does this mean I need to flick back and forth between the Navigator and Element Settings panels to select and manually activate/deactivate collaborator access PER ELEMENT?
Hey @energidesign I believe you are correct from what I recall.
I tested this myself and was not getting cascading settings for disabling content in the editor. @PixelGeek@Waldo@Brando can someone confirm if this is how the feature should be functioning. I was unable to find the documentation for this feature to confirm if this is bug or expected behavior.
Yes, it seems a strange behaviour. A very cool (and needed) option to have, but without some form of parent/child relationship control, it’s a ton of work in either direction to set up the relevant user controls…
Thanks for sharing your feedback on this. I did some testing too and can confirm the current behavior is that this setting will not cascade down from parents to children elements.
That said, I agree this would be a solid addition and I’ve filed an internal enhancement request to get the conversation started.
I can’t say for sure if or when we’ll build this out, but I’ll update this thread if anything changes
It would be fantastic to be able lock parent elements and have the lock cascade down, such a tedious task otherwise.
On a website I am currently building for client, I only want to grant them ability to edit one of the sites pages, be great to have an easy way to block editor access for an entire page too.
Bump as well as I regularly run into this when wanting to give clients not all the control. So @Brando@matthewpmunger@PixelGeek are there any news on this?
Having every element default to allowing collaborators to edit can be such a hassle for many projects. I just had a client delete an entire main heading and didn’t realize it. I’m not sure how long it was like that but after noticing and fixing it I had to go through every page, select every potentially editable element and uncheck the option. Even when using the keyboard shortcut it’s still a painstaking process – and it wasn’t even a massive site. Also, I’m not 100% sure I didn’t miss anything.
There are 3 possible options that could fix this that come time mind:
Have the parent element’s setting cascade down as mentioned by Steve (the original poster from almost 4 years ago).
Have the checkbox unchecked by default so we can check it as needed.
Provide a setting that allows us to decide if new element are checked/unchecked by default.
Bump - This feature is still missing and is necessary for any real collaboration. Even the ability to disable entire pages for collaborators would be super helpful. For example I want to provide access for someone to upload blog content only, so they can only access element on the blog page/CMS collection.
Why can we not attribute editor permissions to the classes of objects, this seems like the way I would implement this in a sprint.
Classes are the perfect handle for what is or what is not editable no? I think this is how it was intended and a bug has crept in as this is the only checkbox that does not propagate through the class structure yet is in a place in the ui that is dictated to by the class name or inheritance
I just had a client catastrophe where they edited the text of a CMS-linked field and didn’t realize it would affect hundreds of other items on the site since it was linked to a reference field. This is very confusing for clients, they can’t tell what will be affected when they edit something.
Effectively they wanted to change a pair of shoes from red to blue, and simply edited “red” and changed it to “blue.” They didn’t realize it would change every red product to display as blue.
While I was fixing that and locking down parts of the site for safety, I came across this lack of cascading support, which is baffling.
Finishing up on my first big Webflow CMS project. Happy creating everything so far, with so many beautiful workflows around implementing CMS elements, but absolutely stunned to find out I have to deselect every “Collaborators can edit this element” on the site to prevent future disasters once giving my client access. I was expecting something so radically more advanced from this beautiful platform, that I’m quite shocked…
Upvoted Michael Wells’ wishlist item as well as some other items around this topic, really hope something more intelligent than this will be implemented.
The easiest fix would be to deselect everything, as I assume most builders would restrict the editing to a limited number of elements… Also, it wouldn’t be that hard to implement the cascading feature as mentioned above, as well as deselecting all elements with the same class name once you deselect one of them.
Same problem here. it is a pain in the *** to work through each element in a multisite website. that makes collaboration with editors not really feasible
