I am building a system that will use a commenting based ticket system. I would like to get some opinions around the idea of flagging a user as deleted or removing the record completely.
Ideally I want to keep the system free of old accounts but at the same time by deleting a user the commenting within the ticket system may not make sense.
Has anyone come up with a solution to this type of problem. My ideas so far:
Delete the users account, comments and all other relevant data.
Flag the user as deleted and create a brand new account if they subscribe again.
Flag the user as deleted but if the user was to try to subscribe again update and unflag as deleted instead of adding a new one.
Delete the user account only. Then when fetching comments etc. check for an associated id, if no result found then display the comment with a message "the users account has been deleted".
What do you think?
I would say that the third option is the best choice
My reasoning for this is any tickets stored in the database should be kept for the life of the database, if you attempt to delete a user from the database, you will remove that users reference to any tickets in the database.
(Thats if the database will let you delete it since the user's id will be linked to any tickets he/she may have created)
When that user goes to create a new account in the ticketing system, the tickets that he may have created months ago have dissapeared and may now have been created by null.
I would always use the last solution: delete the user account only and show an "account deleted" message if the poster's account doesn't exist anymore. If you don't allow users to change their username, you can also save the poster's username (beyond his ID) and display it as plain text if the user deleted his/her account, or as a link if the user is still active.
If you're representing the user <-> comment relationship with a FOREIGN KEY, you can't delete the user without deleting the comment or updating the comment's associated user to either NULL or to point to some "deleted user" fake user account (in either case, losing the information about the user who posted the comment).
The ticketing system I wrote basically did number 3. Anything else will ruin any audit trails you need to keep.
If you need to get rid of old stuff one way is to set cleardown of old tickets. Then, when all related tickets for an account are gone, you can remove the account.
It really depends on you use case.
Personally I would never delete stuff like user-accounts from a db completely.
So option 1 is out. (but that's just me)
Option 2 has the problem, that you'll have lots of dangling user-accounts.
Option 3 looks like the best option -cough- audit trail -cough-
Option 4 is asking for trouble, you have a link to another table, but that data has been deleted.
Related
I’ve a problem that I don’t seem to find on the internet. I was trying to create a website where users transaction histories are saved on the database. Let’s say after a new user signs up and login and then starts to buy or sell stuff from the site, their past transactions should be saved in the database, so whenever they want to view their transaction it will show them their transactions histories. If they have 1, 3 , 12 or more transactions history it will show them everything. My problem now is I don’t know how to do it or even start. It should be able to look a table for each user.
Please make one more table with required transaction columns with post-fix of tablename_history. Use primary key with Auto increment for reference. i.e history_id.
But important thing is that you need to make separate transaction to Insert and Update Query to avoid performance issue.
Our Symfony application makes use of Doctrine, in combination with the EntityAuditBundle to keep track of database changes. This works great for past revisions, the bundle almost exactly tells us what changes has been made.
The next problem is future database changes. Our customers are not able to change their user details, because we need to manually confirm those. Think of the following changes:
bank account number
email address
image of passport
Question: What is the best mechanism to let admins first review proposed database changes? The admin should be able to accept or decline the change.
Subquestion: Will this also work on Doctrine OneToMany and ManyToMany relationships?
For an app that I just finished, I had an Audit table set up - then info was sent in an email to a list of 3 admin emails through their outlook server, and I generated a link for a quick review with an "accept" and a "decline" button. The accept triggered a stored procedure with the Audit table's ID, copied the data to the normal table, then emailed the requesting user that the table was updated... Decline - held the data in the audit table, and forced the admin to enter a note which was emailed to the requesting user. There were only 2-5 requests a day and it was from employees (connected internally, so you could trust the requests more than promiscuous app data). There could be a much better way - but this method worked very well for me. Also, the audit table kept ALL data - all requests, regardless of whether or not they were granted. This was used for reports.
I'm currently working on a website which will have many users on it. These users are stored in a table with each having a unique id. The website will contain projects that the users can complete and these projects are stored in a separate table with unique id's as well.
I need to make the users have a page they can view which will display a list of all the projects they are currently working on.
To do this, I am going to set up another table in which each row will have the user's id as well as the project's id that they are working on. All of that will work alright but I would like to allow users to cancel their projects if they please. I am aware of how to do this, but I have read that deleting rows directly from a php script is insecure so the user used to access the database from PHP does not have 'DELETE' permissions. I am wondering if I should just delete rows at will when a user specifies which project to delete or if I should just have another field and simply mark each user-project row as being 'cancelled' in another field so I can work with them myself.
What you should do is, for maximum security is, have a parameter in the database table called "isActive", or something of that nature, that is a BIT data type to represent a boolean. If that boolean is false, then do not delete the project from the database, simply hide that tables data (do not display it on the site, but keep the data stored in the databse). That way, not only is your database secure from malicious users who would like to destroy data, but projects can also be "re-instated" if they wish to re-instate it. If the project sits around for a certain period of time, say, 14 days, just have the server delete it, not the user, if you wish. This worked for me in the past.
Hope This Helps!
The most common approach to this problem is to have a field in the table that can be used to mark a record as deleted. This would be the only access the general user would have to the table as far as deletion goes. Some people also have a full delete, which states clearly that it will never be accessible again after the operation is completed.
Personally, I prefer to retain full delete permission to administrators allow the user to only mark records as deleted. If you're concerned about space, add a last accessed field as well, and schedule at set intervals a call to perform a full delete on any records that are marked as deleted and have not been active for a certain amount of time.
I am wanting to create a user block I have the button
<a type="button" value="1" name="block" Cursor="pointer" href="blockuser.php?uid='. $data['id'].'">Block</a>
But I'm wanting to know how best to do this with PHP, Ajax and either the users table or a separate blockuser table. So when I click on block I cansend the value 1 to the database with the users id and stop them from veiwing my whole profile with a switch and visa versa.
I will then go on to creating a block list with the ability to unblock this user at any given point, if users so wish.
Privacy is a must! Thanks for any help given.
The only real question in your question is whether to create a new table for this or not, as the rest is a group of very straight-forward tasks for the technologies you mentioned.
Personally, I would opt for simply adding a column to the current users table and filling it with a comma delimited list of User IDs which you could simply search for a user ID within. This has the advantage that you'll only need to run one query vs. the two which would be required to check the block list and then get the viewed user's info in the two-table scheme.
Adding users to the blocklist is trivial (append a user id and perhaps a comma), and dropping the user from the blocklist would simply require splitting the blocklist, removing the proper user ID, then rebuilding the list by joining with a comma.
Also, this is only useful to implement if you require authentication to view a profile, and even then one could circumvent such a system by simply creating a new account.
On each row in the database where you store the profile information (perhaps the members table?) you can add a row called "blocked" which stores the ID numbers of the members that are blocked. I would separate these numbers using semi-colons personally and $blocked_ids = explode(";",$blocked) to get each blocked ID. From there you can check if the person is to be blocked from the profile by using: if(in_array($user_id,$blocked_ids)), if that value is in the array, prevent the profile view.
Hope this helps you, any questions just comment below
As far as the database goes, I would probably do it like this - create a table specific for blocks. Two essential fields would be the id of the blocker and the id of the person being blocked. This means that if one person blocks two users, he'll have two entries in the table - don't try creating one SQL field to act like an array.
Currently, you're setting up to use a standard request to a PHP stage with a $_GET parameter. There's nothing majorly wrong with that, but if you want the whole operation to happen without your page refreshing, you can use Ajax. With jQuery:
$.get("remove.php", { uid: "someID" } );
For instance , in my system i allow the user to create a list and add some information into the list eg. name , address, phone...
And after create the list, it will be inserted into database, and in the page the admin can delete the list
The problem is when user editing the list, the admin deleted the list, then what will happen?
The only way is to check the database again before the edit submit to the database. However, If there are a lot of form, a lot of input, how can i check each field , there is a lot of job if i have to check every field that is concurrent.
I am using php , mysql and pdo for query
Thank you
Well why wouldn't you simply check if the row exists in the corresponding table using it's primary key (id) ?
Basicly, you cannot avoid that situation. While the user edits the form, the user cannot find out if the form has been deleted.
One solution would be to have a flag up once the user starts editing the records that should prevent anyone from editing at the same time/deleting at the same time. Once the user submits the form, then the flag should be back to original value, so that other users/admins can edit/delet those records.
There is a second solution of using a service and check from time to time in the user's page via ajax if the records are still there, but if you have alot of inputs, that can be a little cumbersome to implement.
Basicly, you need to create something that resembles a transaction, aka. lock the records that are being edited. Be very carefoul, since you can end up with alot of locked records. You need to implement a time in which the user needs to finalize the "transaction". If there are locked records beyond that time, unlock them automaticly. Also beware of the fact that the user might exceed that time and you need to handle that situation also, since you will end up in the same state as your original problem.
PS: also you need to beware of informations that have been edited while the user was editig also, since those informations would be lost. For the edit part, i think i would go for a hashing approach to check the state before editing with the state after editing. from this point on, it's up to you to decide what to do.