Non (WF) permissive users can change url [4.2.1650]

I'm not entirely sure if its a bug or deliberate design feature but when a standard 1 level approval workflow is in place users aren't allowed to publish or delete pages without permission.

They can however go to Actions > Titles & properties and change the URL of a page.

While this naturally doesn't change or delete the content of a page from a administrative point of view, from a browsing point of view this allows non authorized users to 'remove' a page.

---

I haven't used WF much prior to 4.2.1650, but I noticed when an admin (full perms WF role) chooses to unpublish a page, the page's status is set to 'unpublish'. When an author (WF approval required role) chooses to unpublish a page the page status gets set to 'Locked by author - published'. 

Since it's status doesn't change, nor an approval flag is raised it merely looks like this page is being actively edited...

Hi Jochem,

By Design, some roles have certain permissions on pages (you are particularly talking about
Modify properties of this page and its child pages ) but you can always change the permissions of all pages (or of a specific page).
About the Authors, unpublishing pages - this is known bug and we are working on it for our future releases.
Thanks for contacting us, feel free to ask any further questions.

Best wishes,
Svetoslav Petsov
the Telerik team

Hey Svetoslav,

Ok... to bad to hear. Would have been great if any definitive page action would fall under workflow since this means that any SEO changes (keywords/descriptions) would now have to fall to a 'trusted user'.

Just changed 'Modify properties of this page and its child pages' to administrator only to see how it would affect it but it doesn't have effect at all. I as a non-publishing-permissive user and in a non-admin role are still able to change the page properties.

Both from page overview > actions aswell as from page edit > more actions.

That setting should have done the trick no?

Jochem.

Hi Jochem,

Can you specify what role (or custom permissions) you assign to your "non-publishing-permissive user"? I tried that as an author and it works (I am not able to change the properties of the page).

All the best,
Svetoslav Petsov
the Telerik team

Hey Svetoslav,

When in page overview, clicking on the right 'settings for pages' disables the functionality.

I tried under Administration > permissions and then widget templates and disable it there. Which didn't work.

But since it listed all the page permissions there, I thought that was the same option even though it's listed under 'widget templates'.

Just out of curiousity, what permissions are set through those options?
Since the first 7 permissions listed there seem to be  about pages...

Jochem

Hello Jochem,

This is a UI bug that we are aware of - these permissions aren't ment to be there. So, for the moment - change the page permissions only from Page Overview. We are working on the bug and it should be fixed in our future releases. Sorry for the inconvenience caused.
Here you can follow the PITS issue: http://www.telerik.com/support/pits.aspx#/public/sitefinity/7489


Best wishes,
Petya
the Telerik team

Hey Svetoslav & Petya,

Originally marked this as answered, but today actually wanted to use it...

I know Svetoslav said that by design it was decided that being able to change the url, wouldn't fall under WF and that I could set permissions so people can't modify the url.

In theory that works, however, by setting the permissions so that one cannot change the properties, effectively makes it so that one cannot make a page.

If I try to make a page and either choose save and continue editing, or save and return I'm told I don't have permissions. And I'm stuck, browsing back Sitefinity gives me a dreaded pop up saying return code: 0 and then ends up with a pop up saying "Object reference not set to an instance" each time I now want to load the BackEnd page overview...


If I'm not allowed to add a page, what's the point in having workflow approval?
Any chance you guys wanna reconsider the design decision and make it so that changing a page's properties falls under workflow approval ?

Hi Jochem,

 I'm not sure I properly understand what you're trying to do. 
When you design a workflow, the purpose of it is not letting the Authors create and publish pages without approval. When a user is in the role of an Author, he can't change any other pages but the ones he created. Your point is that an author can create a page and then change its URL so that it becomes unusable. But if the author wants to do that - he can do it in the very creation of the page. An Author has full control over his own pages (except for publishing and deleting) but has no control over other pages. So, basically, he can "remove" only a page that he himself has created - so what would be the sense of such action?
About the inability to create pages - normally users shouldn't be able to create pages if they don't have Create pages permission. I tried what you're describing with Authors and Editors - I removed the "Change Properties" permission for these roles and was still able to create pages with them. So, please explain in detail exactly what you're doing - a user of what role you are creating and what permissions are you setting.

Hi Svetoslav,

You're looking at it from the BackEnd (Developer) point of view, try and see it from a end user perspective.
Setting WF means, I want that person to make pages and update the website, but I don't trust them enough to allow them to do anything directly on the public website.

Everything that changes the public website, needs to be approved first. As you said it yourself "the purpose of it is not letting the Authors create and publish pages without approval". Removing a page should fall under the same category. And it does, cause like you said it "Author has full control over his own pages (except for publishing and deleting)".

You see 'deleting' as physically removing the page from the db. I as an end user see a '404' as a delete page. Just because the page still exists in the backend does not mean a person who's not trusted to publish or delete a page should be allowed to remove a page from its current location.

It isn't a matter of 'sense'. When user accounts are linked to individual persons, the risk is limited because you couldn't move a page Petya created. But suppose you all the sales staff share the 'sales' login, a not so uncommon scenario with small/standard implementations, then all of a sudden the risk and damage will be far greater.

Suppose 'sales' login is shared across the team, meaning you have authorization to create and edit pages who need to be approved by someone. Now go and change the url from http://www.sitefinity.com/devnet/forums.aspx to http://www.sitefinity.com/devnet/jochem.aspx and wait till all hell breaks loose :) 

That's a security flaw, not a bad implementation or design choice because the end customer decided to create group BackEnd accounts instead of individual personal BackEnd accounts.

---

Secondly the ability to edit properties without workflow approval means I can move the homepage if I want to, even to a page that's still waiting approval. Even if the homepage is set to a page not created by me or someone in my role.

(Create a page>add some content>save for approval. Now in page overview click Actions>Set as Homepage. Now browse live site).


The only way to avoid people to do that, is make it so that they don't have permissions to edit properties. But if they don't have permission to change properties (set modify page properties to administrator alone and thus removing owner/etc...) they can't create any page, because when creating a page you start with editing it's properties which you don't have permission to do so....

---

I know I'm not the best at describing the issue in words, but if this doesn't explain it, I'll make a video :)

Jochem.

Hi Jochem,

 I get your point and I apologize for not being understanding. We will reconsider the design of workflow for our future releases.

Hey Svetoslav,

No need to apologize, I should be the one to apologize for needing 4 tries before getting my point across...

It's not easy understanding other people's point of view when a different view is like second nature to yourself so naturally 'group' accounts instead of 'personalized' accounts isn't something you guys immediately think of.

Thanks for hanging in there with me!

J.