This project is read-only.

What is the use of right "Edit Own User" ?

Topics: Controls, Themes
Feb 28, 2014 at 6:51 PM
What is the use of right "Edit Own User" ?

Is this right for editing the profile that any user with this role's right can edit his/her profile ? I just gave this right to a test user and I am not able to go to profile ?

I want users to be able to change their profile pics - how to do that ? what right I should give them ?
Mar 3, 2014 at 3:25 AM
Rtur, could you please advise ?
Mar 3, 2014 at 4:24 PM
Yes, edit own user is for... well, edit own user :) Including profile.
I would suggest you look at built-in editor role and set same rights for new role. Check what it let you to do, and then remove those you don't need. Just remember to clear browser cache when you switching users, authentication cookie saved in browser and if you go between roles app can still use old credentials from cache. And because UI also heavily cached, you can see elements pulled from cache that will go away after refresh etc.
Mar 3, 2014 at 6:20 PM
Edited Mar 3, 2014 at 6:21 PM
I just created a test user and assigned him a commenter role which has t he right to "Edit own user" but still when I log in as test user, I am not able to go to profile page, it still asks to login even tho I am logged in.

I have deleted cookies, history etc.

Is there any other right other than "Edit Own User" I need to give to the user who wish to edit his/her profile ?

Could you please test this option on your end and confirm here, please ? and please let me know what exactly you did ?
Mar 3, 2014 at 6:53 PM
Did you try what I suggested in the previous post?
Mar 3, 2014 at 7:17 PM
Edited Mar 3, 2014 at 9:26 PM
Yes, I kinda figured, the role needs:

1) Edit own page
2) Edit own user

But it kinda required general rights including "Access Admin Pages"

But it defeats the purpose as as an admin, I do not want comments to see the admin side just to let me able to edit their profile ? I don't think it is right to give people admin access and show them how admin manages the site.
Mar 4, 2014 at 4:23 AM
You right, we need to fine-tune permissions for admin UI. I'll try to get to it next.
Mar 4, 2014 at 11:42 AM
Thank you rtur for confirming the issue. I think making admin menus invisible would be a great idea if ONLY these 2 rights are enables for any role:

1) Edit own page
2) Edit own user

But again, you know better what is the best approach. I am glad that you will consider to fix this issue in the next version.
Mar 25, 2014 at 2:15 AM

I am having this same frustrating problem. Either logged-in users cannot access their "My Profile" page (they get a perpetual (repeating) BlogEngine.NET login challenge if given "Edit Own User" rights, or they get a Windows Security dialog login challenge, asking for domain and username and which is never satisfied, if given "Edit Own User" and "Edit Own Pages" rights), or if given "Edit Own User," "Edit Own Pages," and "Access Admin Pages" rights, users get access not only to "My Profile" (and "Change Password"), but also to some Administrative tools and settings ("Dashboard" and "Custom"), which they should really not be accessing! What I very much need is for regular registered users to have just two options: "My Profile" and "Change Password."

Is there a new cumulative distribution that fixes this problem? If so, I hope it does not require any compiling on my side. And if so, how do I obtain it? Also, please let me know what the minimum role-rights would be for regular users to successfully edit their own "My Profile" page, using that new distribution. In other words, would "Edit Own User" and "Edit Own Pages" be enough? Thanks.
Mar 25, 2014 at 4:40 AM
There was changes in source to address this, but you would need to compile latest source to use them.
Which is not hard, short tutorial on how to work with source code is here.
Mar 29, 2014 at 2:58 AM
Edited Apr 24, 2014 at 6:33 AM

I followed the tutorial link and instructions you provided. However, as I was opening the BlogEngine.sln for the first time in Visual Studio 2012 (Ultimate), I got this error message:


Would there be any harm in upgrading the project database file to SQL Server LocalDB Express? Visual Studio 2012 seems to expect that. But would it mess things up when it is deployed to the shared (GoDaddy) hosting server? What would you recommend? For now, I just ignored this action and continued loading BlogEngine.sln.

I had to change a line in two of the three project .csproj files from "<Project ToolsVersion="12.0"..." to "<Project ToolsVersion="4.0"...." I am guessing that the ToolsVersion="12.0" comes from VS 2013. However, VS 2012 seemed to like ToolsVersion="4.0" better. Was that change correct?

Finally, what folder(s) am I suppose to deploy as the website? Do I just copy the entire BlogEngine.NET project folder, or some subset of that?

Mar 31, 2014 at 7:56 PM
Not sure on that SQL server error, never seen it before. For deployment, easiest way is to right-click web project and select "publish". You can publish to local folder, and visual studio will push only required files, ready for server deployment.
Apr 1, 2014 at 7:43 AM
Edited Apr 1, 2014 at 7:44 AM

I set my VS2012 BlogEngine.NET web publishing settings to publish to a local folder. Unfortunately, I got an error during the build/publish that prevented any files from being published. The error indicated that a file named "BlogEngine.NET.dll.config" was missing from the project's bin folder. I couldn't find a file with that name in the project, so I just created an empty file with that name to satisfy the build/publishing requirements to have that file. Is that file important? If so, what text does it contain so I can fill the empty file with correct information?

Apr 24, 2014 at 5:55 AM
Edited Apr 24, 2014 at 6:36 AM

I have installed version, which you suggested to me on Mar 24 at 9:40 PM. There is further problem with the rights assigned to roles. Our blog has editors responsible for handling posts and for making sure our users (that is, users with usernames and passwords-- we have about 300 of them) are being advanced to the correct roles as they work with our organization. I have set up about six (6) additional roles to handle our current needs. Our editors are assigned to the role: "Editors." Editors are not administrators. I do not want Editors to be able to edit their own user roles, just those of other users. For, example they should not be able to edit their own username to give themselves administrator rights. However, giving them only the User right to "Edit Other Users" does not seem to be enough; giving them only this right results in an error when they try to edit another users roles. Surprisingly, I have to give the Editors role the right to "Edit Own User" too, in order for them to successfully edit another user's roles. This seems like a security breach to me because it allows members of the Editors group to make themselves Administrators if wish by simply check marking and saving that role for their own username. Can this be fixed? Please see the attached image:

Apr 24, 2014 at 2:57 PM
Have to look at it, but it seems like situation when you need edit others without been able edit yourself rather unusual, logically speaking it should be inclusive: you can edit yourself and then you might also able edit others. With roles it seems like "edit roles" should be an admin task, not editor. Editor might be able edit users, but not roles.
Apr 26, 2014 at 9:02 PM
Edited Apr 26, 2014 at 9:03 PM

It is unusual for an Editor, rather than an Administrator, to have the job of updating Users' roles. However, it is what management wants even if it not typical. On the other hand, just looking at the Users rights screen in the image I previously posted, the "Edit Other Users" Boolean attribute is discrete from the "Edit Own User" attribute. If they are really comingled attributes, shouldn't there just be just one Boolean attribute entitled, "Edit Users," rather than the two attributes mentioned above? The fact that there are two separate checkboxes for these attributes led me to believe that our Editors could have the right to neither, the right to both, or the right to one or the other as needed. I never imagined that checking one of these rights inherently meant that I had to check the other one in order to later get any Users screens edited by Editors to properly save.