I have a form which is submitted by a student and needs approval by different people based on the type of form. How can I achieve this in Laravel?
Ex. Student 1 submits Form type 1 which requires approval of Instructor and advisor in that order. The advisor would get notification to approve only when instructor approves it.
I have tried creating columns for each type of approver around(5) and check if the approver has approved and set the field. The issue with this approach is that the table has many columns.
I created a table with approvers and the priority for the approver for the specific form and based on that send the notification.
I know there should be a better way to achieve this.
$firstApprover = $form->approvallist->where('priority', '1')->first();
** Here approvallist is a relationship to a ApprovalList table which contains the list of people who approve this particular form type.
You can maintain a many-to-many relation. The tables would be, students, form_types and the pivot table could be form_type_student. In the pivot table, you will store the type of the form, student id and additionally two fields. One is approver_id (the person who approves) and is_approved(boolean) whether it is approved or not.
And then you can check if the form type submitted by the student was approved or not and if approved who approved it
There are "approval" components ready to use for Laravel. For example first or second. Just google Laravel approval and pick whichever suits your needs.
Let's assume that you are using the Application and Reviewer tables. I suggest linking them with many to many relation. Pivot table can have custom fields "approved" (0 by default) and "priority" in the pivot table. Set the Application's approved flag only when the last confirmation is received.
See https://laravel.com/docs/5.8/eloquent-relationships#many-to-many
Related
I have three entities:
Attendee (holds basic attendee information)
Project (holds basic project information)
Attendance (links attendees and projects and holds more information like "invited_at", "is_confirmed"...)
One attendee can attend one project only once, but can of course attend multiple projects.
When I filter by project on the attendance index page one attendee can have only one or no attendance. In this case I want to display the corresponding attendance's information (like invited_at).
But fields like attendances.invited_at show no informartion on the attendee index page.
I guess this due to the n:n relation. Because fields like attendee.firstname are displayed without a problem on the attendances index page.
How can I get the attandance extra information to display on the attendee's index page?
Ok, there is a quite obvious solution for this problem. Custom fields.
https://symfony.com/bundles/EasyAdminBundle/current/fields.html
I have following tables.
Users
id
name
Events
id
name
Cards
id
name
Transfers
id
event_id
card_id
An user has many events and cards. An user can accepts cards from other user which he met at an event.A row will be added under transfers table whenever a card is accepted by a user, this row links a card_id with event_id. I am looking for a way to check a card (card_id) is added under the transfers table for a logged in user's event(event_id).
eg:-
auth()->user()->events->transfers->where(([['card_id', '=',$cardid]])->find());
Can someone help me by telling what is the best way to handle above situation using eloquent?
Add a belongsToMany-relation
Take a look at the official documentation: https://laravel.com/docs/5.1/eloquent-relationships
i have three tables to store details of different types of uses: customers, suppliers, staff
here are the structures of them,
customer(id,f_name,....)
supplier(id, name, address....)
employee(id, name, job_title....)
now i need those to log-in to the system , the log-in details stored in separate table,
user(user_id, password, role, ref_id)
how i planed to work this is, when registering some one, firstly insert the record to customer, supplier or employee according to the person, then insert a record in to the USER table in which the "ref_id" is the id of the previous table. the user is provided the "user_id" which can not be changed and they can change their password themselves.
when log-in, check the user_id, password combination, if ok then takes the ref_id and type, the appropriate table can be determined by the type which may be customer, supplier or employee....
the reason i done this in above way is,
customer, supplier and employee table has many different attributes except few like id, name...so can not maintain all the data in one table. in this situation if we use ids of customer, supplier and employee..would provide duplicate ids because they are separate tables!
so i need to know,
Is it correct the way i have implemented the authentication ?
if it isn't what is the correct way? (please mentioned that the details of the three parties should be handled separately)
i need to define relationship between supplier, customer, employee --> with user table. so is it ok to define three relationship as follows or another solution, how if the user table keep alone without relationship? is it violate the relational database concept?
customer (id-pk) ---->user (ref_id-fk)
supplier (id-pk) ---->user (ref_id-fk)
employee (id-pk) ---->user (ref_id-fk)
I am trying to get my head around an issue relating to database logic.
I have a system that is to allow the user to create an event, performances and multiple different ticket types for a given event. These will then be added to the database with prices relating to the ticket types for a given event (the ticket types can be reused for other events and there is no set number of types for each event) and then a customer will go onto the site, select one of the events, performances and will then have listed for them to choose from the different ticket types with prices.
At this point I have a table for events which is using a series to store the ticket ids which are stored in a separate table and yet another table which stores the prices. The use of the series is ridiculous as it tends to crap out on me and either fails to work (as mysql doesn't handle the code properly) or it is incredibly limiting on what can be done with the info Has anyone any better idea how I might achieve this result?
example of an event:
event name: 'event 1'
performance: '23/03/13 (12:30)'
ticket types: Adult (€20), Student (€15), Special (€10), etc
the person setting up the event can create any ticket types they want or use existing ones in the system and just have a price set for this particular event.
If I understand you correctly, I believe what you are doing is most likely the best way to do it.
A user can create multiple events, each of which can have a variety of tickets. Tickets are not specific to an event (can be used on multiple events), and thus the price can not be stored with the ticket information.
Therefore, what you want to do is have these tables:
events - Stores information on the event
tickets - Stores information on the ticket
*events_tickets* - a join table for events and tickets (As it is a many to many relationship)
The events_tickets table would have columns like so:
primary id, event_id (Foreign Key), ticket_id (Foreign Key), price
Hope that helps.
table Event: Id_Event, Ds_Event, Dt_Event, Id_Venue
table Ticket_Type: Id_Ticket_Type, Ds_Ticket_Type, Ic_Ticket_Type_Is_Custom (boolean)
table Event_Ticket_Type_Price: Id_Event, Id_Ticket_Type, Nr_Ticket_Price
table Venue: Id_Venue, Ds_Venue, Ds_Venue_Address
I may not be asking this in the best way possible but i will try my hardest. Thank you ahead of time for your help:
I am creating an enrollment website which allows an individual OR manager to enroll for medical testing services for professional athletes. I will NOT be using the site as a query DB which anybody can view information stored within the database. The information is instead simply stored, and passed along in a CSV format to our network provider so they can use as needed after the fact. There are two possible scenarios:
Scenario 1 - Individual Enrollment
If an individual athlete chooses to enroll him/herself, they enter their personal information, submit their payment information (credit/bank account) for processing, and their information is stored in an online database as Athlete1.
Scenario 2 - Manager Enrollment
If a manager chooses to enroll several athletes he manages/ promotes for, he enters his personal information, then enters the personal information for each athlete he wishes to pay for (name, address, ssn, dob, etc), then submits payment information for ALL athletes he is enrolling. This number can range from 1 single athlete, up to 20 athletes per single enrollment (he can return and complete a follow up enrollment for additional athletes).
Initially, I was building the database to house ALL information regardless of enrollment type in a single table which housed over 400 columns (think 20 athletes with over 10 fields per athlete such as name, dob, ssn, etc).
Now that I think about it more, I believe create multiple tables (manager(s), athlete(s)) may be a better idea here but still not quite sure how to go about it for the following very important reasons:
Issue 1
If I list the manager as the parent table, I am afraid the individual enrolling athlete will not show up in the primary table and will not be included in the overall registration file which needs to be sent on to the network providers.
Issue 2
All athletes being enrolled by a manager are being stored in SESSION as F1FirstName, F2FirstName where F1 and F2 relate to the id of the fighter. I am not sure technically speaking how to store multiple pieces of information within the same table under separate rows using PHP. For example, all athleteswill have a first name. The very basic theory of what i am trying to do is:
If number_of_athletes >1,
store F1FirstName in row 1, column 1 of Table "Athletes";
store F1LastName in row 1, column 2 of Table "Athletes";
store F2FirstName in row 2, column 1 of Table "Athletes";
store F2LastName in row 2, column 2 of table "Athletes";
Does this make sense? I know this question is very long and probably difficult so i appreciate the guidance.
You should create two tables: managers and athletes
The athletes table would contain a column named manager_id which would contain the id of the manager who signed the athlete up or NULL if the athlete signed himself up.
During output, create two CSV files (one for each table).
Further reading:
Defining Relationships
If you will retain the names for a future submission, then you should use a different design. You should also consider if a manager can also be an athlete. With those points in mind, consider having three tables: PEOPLE, REGISTRATION and REGISTRATION_ATHLETE. PEOPLE contains all athletes and manager. REGISTRATION is the Master table that has all the information for a submission of one or more individuals for testing. REGISTRATION_ATHLETE has one row for every Athlete to be tested.
People table:
---------------
People_ID
Type (A for Athlete, M for Manager B for Both)
First Name
Last Name
Birthdate
other columns of value
Registration table:
-------------------
Registration_ID
Registration_Date
People_ID (person requesting registration - Foreign Key to PEOPLE)
Payment columns....
Registration_Athlete table:
---------------------------
Registration_ID (Foreign Key to REGISTRATION)
People_ID (Foreign Key to PEOPLE)
I am not a mysql person, but I would think this simple type of structure would work.
Finally, storing credit card information is problematic as it runs into PCI (Payment Card Institute) rules, which you will want to avoid (think complicated and expensive). Consider processing payments through a third party, such as Google Checkout, etc. and not capturing the credit card.
Well based on your comment reply and what you are looking for. You could do this.
Create one database for Registration.
Create the columns ID, name, regDate, isManager, ManagerID (Whatever Else you need).
When a Manager enrolls set isManager to 1 and form a hash based on name and regdate, that would be the Managers Unique ID that would be added to all of the Athletes entries that the manager registers.
When a lone athlete registers don't worry about the ID and just set isManager to 0.
I think I may be oversimplifying it though. Wouldn't be the greatest for forming different types of queries but it should be alright if you are trying to minimize your db footprint