I am working on PHP YII (Version 1.15) User management application.
My Scenario: A user can be assigned as supervisor and there are 'n' numbers of subordinates can assign to the user. Likewise, there are many supervisor available in the application. All users details falls in one table.
Objective: I want to give access to the supervisor to Edit and Delete only to the assigned subordinates. Other users data, he can't able to modify.
What I Tried: I am validating the call everytime before the supervisor clicks the edit button of the subordinates. (I have many forms, so have to use the code many places repeatedly)
Please help me to solve this issue.
Is it possible for you to add some column to your user table?
If it's possible, you should add one column in your user table that indicates the user's supervisor. It can contain the supervisor ID. Supervisors have null value for this column, so this column should be nullable. You can use the value of this column to validate supervisor's access to Edit and Delete by matching the ID of supervisor with this column's value.
Related
I've posted a few questions on here and have gotten very great help and support. I'm still fairly new to programming and I'm putting together what I thought would be a simple website for the company I work at. I apologize in advance for my lengthy post/question, I just want to be thorough and clear in what I'm asking. My question is more of needing some help getting pointed in the right direction of how to get started and some best practices to be aware of. What I'm working on right now is to create a system where a user can submit a questionnaire/online form to inquire about a specific product (in this case it's a hard money loan product). The way I am planning on setting it up is to have a database with multiple tables (users, user_info, loan_app, property) and connect these together by referencing each other. I've read about table joins and I understand them conceptually but I have no idea how to implement in practice. I've had a hard time finding actual examples.
Specifically, this is what I am doing and how I am thinking it should work (correct me if I'm wrong or if there's a better way to do it):
1- the user (aka the borrower) signs in to the website. The user log in system references the user table where things like first name, last name, user name, password and user ID are stored. I have included an "active" column in this table so that when a user logs in the condition for them to get into the website is that the username and password match AND the user is activated. This way we can control on the back end certain user accounts access. I have this part working.
2- when the user registers, they only fill out the information that creates a new record in the "user" table. I have created a second table called "user_info" that will contain other data like home address, phone number email etc. But I need to be able to associate the correct record with right user. This is my first issue to wrap my head around. My thinking behind doing this instead of simply putting all this information in the user table is that for one, I might keep adding to that table and make it very big, and two for security reasons, I would like to keep the information separate. I don't know if this thought process has any merit to it though. Again, that's why I'm posting this here.
3- The user, once logged in, clicks on a button on their home screen/dashboard that will take them to the loan "pre-approval application" form, which is the questionnaire. On this form their basic information will be echoed/posted from the "user_info" table to pre-populate certain fields like first name, last name, email, phone number, address etc. So going back to #2 making sure I can associate the user with the correct record in the "user_info" table is critical. THEN, there are additional fields that the user has to fill out in order to submit the application/questionnaire. These form fields will create a new record in the "loan_app" table. This table will have a loanid column that is the primary key for that table, and an auto generated/randomized 6 or 7 digit loan number (loannum). The loanid will be a hidden value but the loan number will be like a reference number that is associated with the loan for the life of it and used for later accounting and recording purposes internally, whether or not it actually becomes a loan. The loanid, I'm assuming here, is the Foreign key in the "user" table and the userid is the Foreign key in the "loan_app" and "user_info" tables correct? If so, how do I incorporate being able to simultaneously associate all these records when the loan application/questionnaire is submitted? My thought would be write individual php scripts that does each of these things separately then have a "master" php that includes all of those individual ones that is placed as the form action associated with the submit button on the form.
Thanks for taking the time to read through this. I'd really appreciate any advice or reference material that I can read up on to learn more about this stuff. My job has a pretty crazy schedule and I travel a lot so I don't have the time to take actual classes to learn this stuff formally. I'm pretty much doing this as I go.
Also, I'm using MAMP with mysql, not sure if that helps any or not...
The user table's primary key userid can be the primary key of the user_info table as well, since each user will have only one user_info record, right? A foreign key constraint is good to ensure only valid userids get recorded in user_info.
The loan_app table can contain a denormalized relationship from loanid to userid so that each loan application is associated with a user. Again, use an FK constraint for integrity.
Don't include loanid in the user table - that would mean each user has a relationship to a single loan application. You already have the one-to-many relationship you need in the loan_app table.
I'm looking to create a database for users with multi-level user rights and I don't know how to go about doing this. What I mean is that I want a manager of a business to be able to purchase my product; that person would be given Owner rights, but would also be able to grand additional users under that license--those people would be given Manager or User rights. Each level (as well as my level: Admin, and my staff: SuperUser) would obviously have individual rights/privileges).
What I'm asking, more specifically, is how to set up the database. For example, if my business is a corporate calendar/organizer, the Owner would set up departments, each with a Manager and many Users. What's the best and most efficient way to structure the database? Like, would each user (and each calendar entry) have to be associated with an ID that belongs to that specific Owner account? I'm just a little lost as to what the best way to organize the database to keep everything together, as I will have multiple different Owners with their own company structure under them.
I want to use MySQL and PHP.
I tried to make this as logical as possible. I think I'm making it too hard, but I am sure there is a standard that makes it easier....Thanks in advance.
At the very least every product/object whatsoever needs a foreign_key in its table, as for example the user's id. This is necessary and sets the relation from the product/object with the user.
And then it depends on how complex you want your system to become. An easy way would be to just use boolean columns in the user table, like an admin, an editor column and so on, with only true and false as values. In your code you could then use if and case to check if a user is an admin and show him parts of your app or not. Like a delete link for example. But you could also restrict updating and deleting to people whose user has a true value in the sufficient column.
The more complex route would include other id-fields in the tables which set a relation of something to something else. Like say you want the user to be a seller or a buyer, then you would add seller_id and buyer_id columns to the products table and check if the ids correspond with the user_id. But not "the" user_id, but a different user_id which you saved when the user created the product listing for example. This way you could guarantee, that besides your staff the user who created this thing has rights to edit it, too, because of the product's user_id being the same as his user_id (current user) when he is logged in to your system.
You could do even more complex relations but then you'd have to create another table and save other ids in it which relate certain users with say other users. In this table you save let's say a maintainer_id and a maintained_id, both have values of certain user_ids but this way you could make a relation between objects one user could change, though they belong to others. Or if you're talking of customers so the mainter_id would be allowed to write messages to those people with maintained_id, like if someone is a seller and the others are potential buyers.
I'm having a little trouble understanding exactly what you're looking for. From what I've gathered, it seems you want a database that holds permissions, users, and departments. In this very basic example I've created 3 tables. (assuming one user can only belong to one department)
You could set a foreign key in the users table which links to the primary key in the permissions table. The departments table would have the foreign key of the user_id.
You could base all of the logic on what each permission can do with your queries and application side logic.
(I can't embed images due to not having 'enough rep')
I'm currently making a payslip system wherein there are two tables, the account_table and the payslip_table. I'm currently having trouble with the database design, I'm torn between creating a relationship between two tables or not creating one at all. I guess I'll first explain how this system works:
Admin logs in to the site
Admin goes to the upload payslip page
Admin uploads an excel file and the back end code parses the excel file and saves it in the database
User logs in to the site
User goes to the payslip page
Payslip page shows the row where the employee_id is the session_user(since a user's username is his employee_id)
The account table has the following columns:
1. employee_id
2. password
3. first_name
4. last_name
5. user_type
The payslip table has the following columns:
1. payslip_id
2. employee_id
3. salary
4. tax
5. total_deductions
6. total_salary
The requirements for this system is that the owner wants to upload a payslip even if there "isn't an account for a user".
Q. Then why are your tables designed like that?
A. The payslip in its nature has an employee_id and its presence is the key on determining which payslip owns which. For me to effectively show a payslip, all I need to do is to compare the session user (which I have mentioned is their employee id since it's their username) with the employee_id on the payslip table and just echo the row that was hit.
Q. What happens to the payslips when a user isn't an employee anymore? There will be useless rows on the payslip_table
A. I've decided to create a column named created_on and add a triger to delete payslips that are 3 months old (since they have no use already)
Q. What happens to an account when a user isn't an employee anymore?
A. Admins have the authority to delete a user, once a user is gone from the company, the admins can terminate the account and as mentioned above, the payslips of the deleted user will be eventually deleted
Q. Why go through all this trouble?
A. The owner specifically stated that he wanted to have the payslips ready even if an account has yet to be made so if one person were to create an account, his payslips are automatically ready for viewing
I have very minimal knowledge in database designs and I'm very open to suggestions.
Or if you guys could suggest an alternative way of achieving the requirement using foreign keys then that would be the best way to go.
You should create a relationship between the two, as you can see here you will be able to add a null value into a foreign key field and fill it later with an employee_id.
This will help with finding rows, and making sure there is no useless data floating about wasting space.
The only problem I see is how the admin will link payslips already on the system to a new employee account. e.g. finding the correct payslips for the new employee number
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
i cant access site administration without that we cant do any changes,now how to assign admin roles to the new user in the phpmyadmin,if any one know means can u help me out
You are going to be messing with the database so be very careful and cautious of what you are doing. It would even be a good idea to make a backup of the database before you begin.
This will involve using phpmyadmin or some other tool that will allow you to access your database. The first thing you want to do is verify that your admin account is truly gone. To do this use phpmyadmin to access your Moodle database. The table you are looking for is more than likely called mdl_user. In this table you should see a user with a user id (first column) of 1 or 2 most likely 2. In the username column you should see an admin username if you didn't change the admin username when you installed your server. If you can't find the user name then it may just be gone. Either way, what you want to take away from this table is the user id for the user that you want to make an admin, that could be you or the admin user account. Remember this id number.
Now find the table called mdl_role. This table shows the various roles that you currently have on your server. More than likely the admin role will have an id (1st column) of 1, but check this table to be sure. Whatever the role id of the admin role is remember this number as well.
Now you need to find the mdl_role_assignments table. This table tracks all of the roles assigned to each individual user by whatever context in which they are assigned. What this means is that for every place in Moodle that you have a role, there will be an entry in this table. For example, lets say I am a teacher in one course, a student in a different course, and I have been given the role of a teacher on a specific activity within the course where I am a student. In this example I would have 3 entries in the role assignments table, one for each of those different roles. A user could have dozens of different roles in this table based on the context where a role has been assigned.
In the userid column of the mdl_role_assignments table find your user or the admin user. There could be multiple entries for this user. Once you find the correct userid, look at the contextid column. You are looking for a contextid of 1. If there is no contexted of 1 then you need to edit one of the existing contextid's so it becomes a 1, with the understanding that you are now removing this user from that existing role and may have to reassign it at a later time. The other option is to just add a new row to the table. Now once you have changed the contextid to a 1 you need to change the roleid to whatever number that corresponds to the admin role id from the mdl_role table mentioned before. Usually this will be a 1 as well. Change the roleid to 1 and save your changes.
This should give you a user that can now function in the admin role.
Source here
I am currently working on a system that would allow users to add additional custom fields for the contacts that they add.
I wondered what is the best and most efficient approach to add such ability?
Right now what I was thinking was to have 1 table per users (with foreign keys to a "main" contacts table) and then adding a column for each custom fields that the user adds (since I don't expect to have more then 100-200 users per database shards [sharding is easy since every users never see each-other's content in this system]), although I am not 100% sure that this would be the right solution for such problems.
Maybe you could try to have one separated table to store a reference to the user, plus the field name and value, this way you will be able to have lots of custom fields.
If you go with Boyce-Codd, you separate the information and store them into a table.
Means one table for all users with a foreign key.
One table per user would lead to hundreds or more tables with possible repeated information.
You need to have one table named USERS that stores the id of a user and fixed info you might want. Then, you could have a CONTACT table, that stores the type of contact user might create, and one matching table USER_CONTACT that matches the user unique id with the id of the contact that was created.
With this, you could have advanced data mining on all the information stored, like nowing how many contacts each user created, who created more, etc...