A user can submit his data, after login. There is two tables in mysql: items, categories. Categories has a field: user_id, but in item table, there isn't, every item should belongs to a category.
When a user submitting a category, its fine, i get the user id from session, and inserting it.
When he submits an item, i set the category_id for it.
The problem is, the user can simply rewrite the category_id (javascript, on the frontend, click on a category : set the category_id), and submit the item into a category which is not related to him.
Two solutions what i'm thinking (but i haven't made like this):
When the user inserts an item, i check the category relation, and if it's not the user's one, its exit.
Add the user_id field into the items table too (not looking as a good option).
What is the good way or what's the proper/common solution in this case?
Add the user_id field into the items table too
If you already have the user_id in the categories table, and you're certain that each item has a category, then this is unnecessary duplication, as you suspect.
Check the category relation, and if it's not the user's one, its exit.
That's the way to do it - when you read the category id before inserting an item, make sure that category belongs to the user. Simple. I would probably just show_404(), but it's up to you if you want to show a meaningful error message.
Why not create a user_id column in category table. When user tries to submit entry check the user_id, if it is not that user redirect him wherever you want
Related
So I have two different tables, a users table and an articles table. The idea is to allow a user to rate an article, but only allow them to rate it once (possible change their existing rating too but I can come to that conclusion later).
As of now I just have the update value working to allow them to rate the article, but of course a user can rate an article as many times as they want.
To give you an idea of how I have everything working, when a user logins in, a session is created with their user information. So when they go to rate an article, I have the ability to check the user, I just don't know how to stop them from rating if they have already rated a specific article.
The user table consists of among other things their username and their unique ID
and the article table consists among other things the article contents, the article unique ID, and the articles rating.
I had some really sloppy ideas like when the user rates an article their ID gets stored into the articles row in some kind of "users who have rated" column, and then I can do a for loop or something to siphon out all the user IDs and then check if their ID exists in that articles entry but then each article would have a row with possibly hundreds or thousands of userIDs on it and there seems like there would be a more elegant way.
Any help or direction is appreciated :)
Create a UserRatings table which has foreign keys to the users table and the articles table, and stores a row linking the user to the article, and the rating they gave it and when it occurred.
Then if a user tried to rate it again you just check this table for the user ID/article ID combination before allowing it.
And then if you wanted got can do things like show the user a list of articles they have previously rated, etc
On my website, I have a users table and industry table and industry_overview table. industry_overview contain the overview data of an industry.
I want to have a "Add to Cart" function where user can add the overview detail such as value chain, market share and market price into their cart list.(Cart list item will eventually be merged and generate a report out in pdf form)
May I know what is the simplest way I could get something like that done? I've thought about this but I can't seem to find a solution or idea.
I don't need a ready-made script, just any idea that could get me working then will be great! (Also if you already have an example of such function, I'd be more than happy to have a look at it).
Thanks in advance!
Update:
Industry overview table has 5 column:
overview_id
industry_id
value_chain
market_share
market_price
I would do it using carts and cart_items tables:
carts
=====
- id
- user_id
cart_items
==========
- id
- cart_id
- industry_overview_id
- column
If you want a user to have multiple simultaneous carts you can add a name column, which the user can change.
Any data point (column in industry_overview) selected by the user will result in an entry in the cart_items table.
However, with this method a user's cart items will automatically be "updated" if the value of the overview item changes. If you don't want this you could save the exact values from industry_overview into the cart_items table, either instead of or in addition to the id.
Lets say I have a database table containing a list of statuses.
In my apps form, I have a <select> containing options for all of those statuses which a user can select.
Now, lets say there is another table called people which contains a column for status which represents a status that was previously selected from the list of statuses.
And lets say that I have removed a status from my statuses table, but there are still database rows for people with that removed status.
Now in my form, I can no longer pre-select the <select> option for that status because it no longer exists in my statuses table.
So how would I handle this so that it still pre-selects the removed status in the select? Is my only option to have an <input type="text"> and then some type of autocompletion like twitter typeahead? And if so, how would I validate this? Would I check if the status they enter is what is already there and also in the database table statuses?
Any insight would be awesome.
SOLUTION
Since you are using PHP, you could dynamically append the appropriate status value to the end of your list based on the person.
SUGGESTIONS
First, you should be using a foreign key to link the status table to your person table, and not just storing the status string in the person table. Creating this relationship would have kept the referential integrity of your tables and prevented you from deleting current statuses in the first place.
Never delete statuses from your table. If you need to remove a status from the list of active statuses, you should add a bit field to your status table called "IsActive" (or something similar). Then you could query SELECT * FROM status where IsActive=1 for new records while still having all the old values when needed.
I have one Category List user will select a category from the list if user didn't find a category in the list, then he will select "other" option and it will display a text box there user will enter a new category name. This newly added category will go for approval to Site Admin till then it should be mentioned as "Uncategorised".
So my question is how to achieve this using a mysql table should I create a new table as uncategorized category or should I add one extra column to category table as "isApproved". As the solution should be for both add and edit of new category.
As you described
Admin must approve newly added category.
To acheive that you definitely will have a field status or something like that to check if this category is approved or not. You can simply use that field. If it is not active, it is "Uncategorized.
A more flexible way than adding one isApproved (or rather a more generic name like status) column to your table is to create a whole new temporary table. There are number of reasons why this is the better approach:
You can save diagnostical information like who created this category, when did he create it, and so on.
You separate your logic: An unapproved entry is, simply put, a temporary one. Approving it is nothing more than moving it over to your categories table and thus making it permanent.
Your categories table doesn't get clustered with unnecessary entries.
I'm building a CMS (powered by PHP and MYSQL) with pages and categories. Currently users can create, edit and delete pages/categories. But when a user deletes a category, their pages end up in limbo...because the only way they can view pages is by selecting a category.
I'm thinking of designating a default category that cannot be deleted--for orphaned pages. But how would I go about implementing something like that?
Is there a better solution I'm not aware of? I could use some advice.
If each category has a row in a DB, have a field "is_deletable" (a TINYINT should do) and set that to 0 for the default category. This is more flexible than hard-coding the "default" category in.
Whenever you delete a category, make an UPDATE query for pages in that category, to update the category ID to 0 (which doesn't exist).
Then decide on an Uncategorized category, which will contain all pages with category 0.
A user is able to delete the category because you allow it, if you put some requirements to the deletion of a category (if a page belongs to only one category and that's the category the user wants to delete, don't allow it), then they wouldn't be able to delete it.