Hi I have an issue that I have some understanding of what is happening but I have no idea how to correct it. The basic issue is that we have an umbraco site where the original administrator user (lets call him User-0) was deleted after creating a new administrator user called 'User-1'. When we subsequently either log as User-1 into the back end and create a new member, or we programmatically create a new member off of a Register request the creator of the member is detaild as being User-0 and not User-1.
I can only assume that the original user is godlike in some way...... The record is still there in the database but he has been deleted via the app a point proven by the fact that I cant log on as him.
My Question is.... How can I ensure that new Members are marked as being created by user-1, i.e the user who ACTUALLY logged onto the system and created them!!! not some weird relic of a day gone by?
I am not programtically setting the creator at all!
Sorry, I'm a bit confused here...to me it sounds like you're talking about users that can login to the Umbraco backoffice? Or is it members that can log onto the website?
The Umbraco API defaults to User 0 (literally ID = 0) anywhere it has an overload that accepts that let's you specify a user id. E.g. the overload with no userId uses id = 0.
As such I would say it's safe to say that deleting user 0 is bad. The first user ever created, should always exist in my experience.
The table in question in sql that stores these is umbracoUser. However the Id column is an auto incrementing id, so once 0 is gone, it's gone for good unless you reset the index. Basically getting 0 back will be difficult.
This is why when we install umbraco, we also call the first user Admin, then we create additional user accounts for individual back office users and we treat the Admin user like a sql SA Account.
If I am accurate on these claims, I think they should add a delete trigger to umbracoUser that prevents you from deleting user 0 and instead just disables their login with a bit flag or something.
Really there are a lot of things Umbraco should have in the database that aren't there. Like stored procedures, views, triggers, etc. Their reason for not doing so is probably because it uses PetaPoco and supports multiple database server types. But in my experience, if they drop SQL Server Compact Edition support, everything else supports views, triggers, and stored procedures. PetaPoco can call stored procedures and serialize their results to pocos no problem. PetaPoco also supports Views and Poco's for Views. So the wild card would be triggers, which I think you could do with PetaPoco's Sql class and a direct sql call. It doesn't need a lot of triggers, just a few here and there, like on umbracoUsers.
Ok, it's because you used user/members quite a lot in your initial post and users and members in Umbraco terms are two different things - Therefore I was a bit confused.
As Ryan is saying above it should not be possible to delete the admin account but currently it unfortunately is. This should changed and there has been an issue reported about this on the issue tracker here http://issues.umbraco.org/issue/U4-5766 for the record. Feel free to go and vote it up.
Not sure how to activate the admin user again since I'm a frontend developer so giving advice about the database is something that I rarely do :)
I just did some testing in sql server, and have a solution for you to recreate the admin account,
use CommunitySite_Umbraco; --Change this to the name of your umbraco database
DECLARE @maxId int;
SELECT @maxId = MAX(Id) FROM umbracoUser; --this is used to reseed the table back to what it was when we are done.
DBCC CHECKIDENT('umbracoUser', RESEED, -1); --this resseds the table making 0 available again on the Id identity column
--Insert the admin back into the table
INSERT INTO umbracoUser(userDisabled, userNoConsole, userType, startStructureID, startMediaID, userName, userLogin, userPassword, userEmail, userLanguage) VALUES(0, 0, 1, -1, -1, 'admin', 'admin', '', '[email protected]', 'en')
--Reseed the table back to what it was
DBCC CHECKIDENT('umbracoUser', RESEED, @maxId)
For this to work, id 0 does indeed need to be gone.
What it does basically is reseed the table so Id = 0 can be used again. Then inserts a record, which will be Id 0 (the admin account). Then it reseeds the table back to what it was, which is determined by querying the maxId before reseeding it to 0.
OK. Thanks. However these do not really answer my question. I know that the special user is 0 an admin user. I did delete it but it has NOT deleted the record, just disabled it somehow. My question really is WHEN i am logged in as BackOffice administrator named 'Rocky' and I create a new member why does it insist on saying it was created by Admin (user 0)!! It was not created by User 0, Rocky created it!!!I can understand why when you create members via the api it might do that as it would default to 'user 0' (which by the way Id also like to prevent, Id like to assign another back office user as the default creator!)
Creating Members...
Hi I have an issue that I have some understanding of what is happening but I have no idea how to correct it. The basic issue is that we have an umbraco site where the original administrator user (lets call him User-0) was deleted after creating a new administrator user called 'User-1'. When we subsequently either log as User-1 into the back end and create a new member, or we programmatically create a new member off of a Register request the creator of the member is detaild as being User-0 and not User-1.
I can only assume that the original user is godlike in some way...... The record is still there in the database but he has been deleted via the app a point proven by the fact that I cant log on as him.
My Question is.... How can I ensure that new Members are marked as being created by user-1, i.e the user who ACTUALLY logged onto the system and created them!!! not some weird relic of a day gone by?
I am not programtically setting the creator at all!
KInd Regards
Conrad
Hi Conrad
Sorry, I'm a bit confused here...to me it sounds like you're talking about users that can login to the Umbraco backoffice? Or is it members that can log onto the website?
/Jan
Yes the users that I am referring to are the back office users.
The Umbraco API defaults to User 0 (literally ID = 0) anywhere it has an overload that accepts that let's you specify a user id. E.g. the overload with no userId uses id = 0.
As such I would say it's safe to say that deleting user 0 is bad. The first user ever created, should always exist in my experience.
The table in question in sql that stores these is umbracoUser. However the Id column is an auto incrementing id, so once 0 is gone, it's gone for good unless you reset the index. Basically getting 0 back will be difficult.
This is why when we install umbraco, we also call the first user Admin, then we create additional user accounts for individual back office users and we treat the Admin user like a sql SA Account.
If I am accurate on these claims, I think they should add a delete trigger to umbracoUser that prevents you from deleting user 0 and instead just disables their login with a bit flag or something.
Really there are a lot of things Umbraco should have in the database that aren't there. Like stored procedures, views, triggers, etc. Their reason for not doing so is probably because it uses PetaPoco and supports multiple database server types. But in my experience, if they drop SQL Server Compact Edition support, everything else supports views, triggers, and stored procedures. PetaPoco can call stored procedures and serialize their results to pocos no problem. PetaPoco also supports Views and Poco's for Views. So the wild card would be triggers, which I think you could do with PetaPoco's Sql class and a direct sql call. It doesn't need a lot of triggers, just a few here and there, like on umbracoUsers.
Hi Conrad
Ok, it's because you used user/members quite a lot in your initial post and users and members in Umbraco terms are two different things - Therefore I was a bit confused.
As Ryan is saying above it should not be possible to delete the admin account but currently it unfortunately is. This should changed and there has been an issue reported about this on the issue tracker here http://issues.umbraco.org/issue/U4-5766 for the record. Feel free to go and vote it up.
Not sure how to activate the admin user again since I'm a frontend developer so giving advice about the database is something that I rarely do :)
/Jan
I just did some testing in sql server, and have a solution for you to recreate the admin account,
For this to work, id 0 does indeed need to be gone.
What it does basically is reseed the table so Id = 0 can be used again. Then inserts a record, which will be Id 0 (the admin account). Then it reseeds the table back to what it was, which is determined by querying the maxId before reseeding it to 0.
This should fix it.
OK. Thanks. However these do not really answer my question. I know that the special user is 0 an admin user. I did delete it but it has NOT deleted the record, just disabled it somehow. My question really is WHEN i am logged in as BackOffice administrator named 'Rocky' and I create a new member why does it insist on saying it was created by Admin (user 0)!! It was not created by User 0, Rocky created it!!!I can understand why when you create members via the api it might do that as it would default to 'user 0' (which by the way Id also like to prevent, Id like to assign another back office user as the default creator!)
Ah, I think the backoffice UI is using the api with ID = 0 all the time and never actually logs the actual creator as the person who created it.
It's probably a bug, should report it in the issue tracker.
is working on a reply...