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.
Related
I am developing a web-based iPhone app and possibly a PC friendly website version as well. The goal here to to allow users to submit a form where specific input values would be stored into a table in the database.
Mind you this information is being gathered for public display and will be posted onto a calendar or list.
However, to prevent from any trolling or spamming, I'd like to make it where submissions have to be approved prior to being submitted into the table.
I have no problem with creating the table, connecting to the database, storing input values into the corresponding table columns. The only issue is how would I go about setting up an approval system? Can I add information to a table via email? Is there a way to approve admissions in cPanel?
This is something that I would like make as smooth as possible, I am expecting a lot of submissions daily with quite a bit of information.
You can have two approaches for this.
Approach 1
Have two copies of the table (which you want to save information
into). The first one should be named tableName_Input. The second one
should be tableName_Final.
Any Data in '_input' is considered raw and needs approval. Once approved the data will be moved into '_final'. The LIVE list/calendar always read from '_final' data.
Approach 2
Have a column named 'isApproved' with a flag 0/1. If 1 it is approved, else it is not. Only show data that is Approved.
Now, how do you get the data approved ?
You have a hard fast rule like spam filter that tells certain post is valid and approved by default
After every post, you send the user an email or some notification (unique to the user - post) that when answered back, shall mark it as approved.
Optional: You can place a column called as 'approval comments' to fill in something at the time of approval.
Flow chart
Tables
'FirstSubmitContent' - Table to store user submitted information
prior to approval.
'FinalSubmitContent' - Table that stores the final information
Code Pages
Content Page --> Contains the form the user fills the content
ContentActionPage --> Calls the controller --> calls the Model
Controller --> calls the model based on page action
Model --> Interacts with the Database table
I do not have any tools at my disposable now to write more detailed Code or Flowchart. I hope this puts in the right direction.
Validate the form on submission and save info in a temporary table in your DB with a randomly assigned activation code (you could use sha1). Then send an email to user with activation code and a link to verify it, ie. domain.com/activate.php?code=abcde12345.
The activation page can be very simple with just a $_GET['code']. Then check if you find a match in the DB for that code and finally prepare your query with all the info you gathered before to store it permanently.
Then you can make a cron job to delete all records from that table every 24-48 hours so users will have to activate within that time range.
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.
I need to build a registration system which requires the collection of large data (many fields) from the user registering which is then inserted into a couple of tables in a database.
I don't really want to display a very long form to the user for the purposes of better UX.
This system will not run online, it is just a web app to run on the desktop.
I need help, pointers, references, etc on how I can better organize the registration process to make it more user friendly.
This How to encourage a user to fill in long application forms? has been helpful so far
As long as you don't mind requiring your user has Javascript, I would use AJAX. Let's say that you have 50 fields that you can logically combine into 4 different sets - the first may be about the person asking for name, email, etc., while the next set asks for historical information or employment information - like on an application.
Make one form for each set, and then present a new user with the first. When he completes the first page, instead of a "Submit" or "Register" button, use an AJAX call and a "Next" button to get the info and switch to the next page of the form with the next set of fields. You could use the AJAX calls to hold the information in a temp table in your database, and then, once the entire process is complete, you can write it to your member/users table.
You could do like other surveys or checkouts do and add a "title" for each page of the form above the form fields so that as a user moves through registration, they can monitor their own progress.
I'd recommend checking out the Amazon checkout, or really any multi-page survey (you may even be able to set one up yourself on Survey Monkey) to see how a large number of form fields can be broken down logically in a user friendly way.
Hope it helps.
Check out this link: http://www.smashingmagazine.com/2011/05/05/innovative-techniques-to-simplify-signups-and-logins/
It's talking about login- and registration-forms and how to make them more user-friendly. A suggestion which is also included in this article is as follows:
At registration don't ask the user to many questions. Only the basic data like their name for example. Then ask him about more detailed data when the user logs in the first time. This way the registration won't take too long.
Maybe this helps you out :)
I have a social website in developmenti n PHP codeignitor and MySQL. I am storing user sessions in the database to handle a multi-server enviornment. Currently there is only 1 database.
1) To handle multiple databases (+ the multi server) how and where will the user session be stored? I assume database wont work in a multi-database env.
2) The session ID given to the user, is it an auto increament from the database or generated from the application logic? I assume it should be a GUID?
3) Along with the session ID I have a user_session table which logs all session related details like login_datetime, logout_Datatime, if user was on web/mobile, etc. So this table has to be written to in 2 stages: When the user logs in and again when the user logsoff. The questions is when the user logsoff what is the logic the system should follow to write the date? Like how will the system know which user_session to write the data to since this PK ID is a database driven autoincreament value and created after the main session ID is created. So at end it will need to query user_session table to find the user_Session ID and then write.
Your comment gave me some clues about the best way to solve this problem for you.
First, if the site is launching soon but not live yet, the best way to solve your problem is: don't worry about this problem yet. Just host everything on one server with one database for the time being. Your idea, no matter how brilliant, will need to solve lots of problems with its first few real users before demand picks up enough to require more hardware.
Second, your image and video servers probably don't need a user's session information. If a user requests a web page with a video, and they have enough access to view the web page, then you can probably just send along the video without further auth checking. This choice will also enable you to use a content delivery network (I personally like RackSpace Cloudfiles, with has a partnership with Akamai) for a much-improved user experience over using your own servers.
Good luck!
Apparently there was confusion as to my original post so let me start over:
I am essentially creating an online shopping cart which gives a manager the ability to enroll his/her employees for training services which we provide. We charge $49 for the services for every employee enrolled. The primary difference between this and a traditional shopping cart however is that we must collect a solid amount of data about 'each' employee enrolled in the program - and this information is provided by the employer at the time of registration/purchase.
As a manager, I enter my personal information and then select how many employees I want to enroll. I currently have the site set up to handle 7 employees but actually need it to handle up to ~30. The issue I am having is the lack of dynamic ability and huge file sizes (especially in on the validation) I am running into.
Each fighter's information is passed and stored in session super globals such as: $_SESSION['F1Firstname']; and $_SESSION['F1SSN3']; and so on. I dont want to use javascript (and won't) to 'add another Enrollee' button because this can be turned off easily on the client side.
My assumptions are this:
1) I must be able to dynamically add variables to each new fighter so they may be stored in an online database and then passed along to our testing center - for example, emplotyee 1's name is F1FirstName; employee 12's Date of Birth is F12DOB1 and so on.
2) The validation for each employee will be the same based on each individual field (all first names must pass the same test). The validation for all email address must past the same email validation test and so on. If I simply build this by each individual record the validation file will be very large. I am thinking I need to add a Firstname array somehow but I'm not entirely sure.
3) I need this to be scalable that in the sense, I want a manager to enroll up to 100 employees, he/she can.
4) As I mentioned, this is like a shopping cart so a manager is enrolling all employees at once so they can pay for ALL of their employees in a single transaction.
Anybody got any ideas?
You can generate additional fields as needed by javascript. just provide a button 'add boxer' and there wouldn't have to be a lot of hidden fields.
If you're a "fairly new programmer" the best way would probably be to just have a form to input 1 fighter at a time. Not to mention this would be a lot more user friendly.