IT 202 Project Proposal

Review the general project requirements and milestone feature expectations for the Internet Applications final project.

Project Name: API Project

Project Summary: This project will primarily use data pulled from an API to do something project-specific.

GitHub Link:

Website Link:

API Link:

Your Name:

Important: Below is a list of generic core features for everyone's project. Your desired scope/design may be slightly different but each of these requirements must be met to the best of your ability, even if it is just to add an extraneous page to accomplish the feature. The goal of this proposal is to try to fit as many desired project types as possible, which may not be perfectly possible. Each feature is intended to be relatively generic and flexible and can be a little unclear in some cases in how it can fit your project; reach out to me at the earliest if there is any confusion and I can help offer suggestions/guidelines. Do keep in mind your project scope/design/goal as you work towards these features.

General Requirements When Not Explicitly Mentioned

  • All data entry forms should include HTML validation, JS validation, and PHP validation
  • All pages/views must have styling applied
  • All messages/notifications/alerts to the user must be user-friendly and non-technical
  • Every user action must have a clear positive or negative reaction
  • Code should generally follow the design/concepts from the course's lessons
  • All tables created should have the 3 standard columns of id, modified, and created in addition to their core data
  • All tables should have appropriate and reasonable data types and constraints applied
  • Features should be broken down into separate branches
  • Search/filter form field selections should persist as a sticky form
  • All code should have comments with UCID, date, and brief details
    • If the code was given, the date would be when it was analyzed or added to the workspace
    • If the code is new, it is when the code was added
    • There should be a brief summary of what the block/segment does
    • These are necessary for screenshot evidence in the submission worksheets

Milestone Features

Milestone 1 (9)

Milestone 1 should be a clear derivative of the completed account-system lessons. Your project can have its own theme and content, but the shared helpers, validation style, flash feedback, role checks, session shape, branch workflow, and project folder structure should follow the course project lessons.

  • User will be able to register a new account
    • Form:
      • Fields: username, email, password, confirm password; other fields optional
      • Email is required and must be validated
      • Username is required and should follow the shared project rule: 3-30 lowercase letters, numbers, underscores, or hyphens
        • HTML pattern attributes for username must escape the hyphen in the character class
      • Confirm passwords match
      • Include appropriate HTML validation attributes
      • Include appropriate JS validation of the fields via the validate() function
      • Include appropriate PHP validation before database writes
      • Ensure user-friendly messages
    • Users table:
      • id, username, email, password_hash with 60 characters, created, modified
      • Password must be hashed. Plain text passwords will lose points
      • Email must be unique
      • Username must be unique
    • System should let users know when a username or email is already taken
    • System should allow the user to correct the error without wiping/clearing the form
      • This is known as a sticky form
      • The only fields that may be cleared are the password fields
  • User will be able to login to their account, given they enter the correct credentials
    • Form:
      • User can login with email or username using a single identifier field
      • The server-side lookup should safely check username = :identifier OR email = :identifier, or an equivalent prepared query
      • Password is required
      • Include appropriate HTML validation attributes
      • Include appropriate JS validation of the fields via the validate() function
      • Include appropriate PHP validation before checking credentials
    • User should see friendly error messages when an account does not exist or passwords do not match
    • Logging in should fetch the user's details and roles and save them into the session
    • User will be directed to a dashboard page upon login
      • This is a protected page. Non-logged in users should not have access to this page during this milestone
  • User will be able to logout
    • Logging out will redirect to login page
    • User should see a message that they have successfully logged out
    • Session should be destroyed so the back button does not allow them access back in
      • Note: The back button usually shows a cached page, so you need to go back and reload the page to determine if this works
  • Basic security rules implemented
    • Authentication:
      • Function to check if the user is logged in
      • Function should be called on appropriate pages that only allow logged in users
    • Roles/authorization:
      • Have a roles table
      • Have at least one server-side role-protected admin workflow/page that allows an authorized role and blocks a user without that role
        • The admin role pages from the lessons, such as create/list/assign roles, satisfy this requirement
  • Basic roles implemented
    • Have a Roles table: id, name, description, is_active, modified, created
    • Have a UserRoles table: id, user_id, role_id, is_active, created, modified
    • Include a function to check if a user has a specific role
  • Site should have basic styles/theme applied; everything should be styled
    • For example, forms/input, navigation bar, etc.
    • Styles/theme should be pleasantly different than the provided bad design
  • Any output messages/errors should be user-friendly
    • Use the flash message helpers from the lessons to show success and failure states after form submissions and redirects
    • Any technical errors or debug output displayed will result in a loss of points
    • Ensure technical errors use error_log()
  • User will be able to see their profile
    • Email, username, etc.
  • User will be able to edit their profile
    • Account details form:
      • Fields: username and email
      • Changing username/email should detect duplicate values and show specific feedback
      • Changing username/email should not require the current password
      • Include appropriate HTML validation attributes
      • Include appropriate JS validation of the fields via the validate() function
      • Include appropriate PHP validation before database writes
    • Password change form:
      • Fields: current password, new password, confirm password
      • Include appropriate HTML validation attributes
      • Include appropriate JS validation of the fields via the validate() function
      • Include appropriate PHP validation before database writes
    • Allow password change only when the existing correct password is provided
      • Hint: logic for the password check would be similar to login

Milestone 2 (8)

Milestone 2 proves that the application can store, display, and manage the primary non-user data for the project. API-imported records and manually created records should share the same structure whenever possible so the same list, detail, edit, and delete pages can work with both kinds of data.

These are the minimum requirements for this milestone. You may include additional pages or workflows that better match your project vision as long as they do not conflict with or contradict a requirement.

  • Define the appropriate project data table or tables
    • Each table should include the shared project columns id, created, and modified
    • Store mapped API data in real database columns rather than one JSON/text dump
    • The API data should provide at least 3 relevant fields that become meaningful project columns
    • Manually created records and API-imported records should use the same table shape
    • Include a clear way to tell manual records and API-imported records apart
      • Example: is_api column or an api_id when the API provides its own id
    • Some APIs require multiple endpoints. Fetch additional data as needed instead of eagerly fetching everything at once
  • Admin API Fetch/Import Page
    • API data should be fetched from server-side PHP
    • The API response should be mapped into the database shape used by the app
    • The import should use only the fields that matter for the project
    • Values should be converted or cleaned when the API shape does not directly match the database shape
    • Duplicate API results should be handled consistently with a clear rule
    • Successful imports and import errors should use friendly flash messages
  • Admin Data Creation Page: custom form for manual records
    • The form should use input types and fields that match the project data table
    • Include appropriate HTML validation attributes
    • Include appropriate JS validation of the fields via the validate() function
    • Include appropriate PHP validation before database writes
    • Successful creation and validation errors should use friendly flash messages
    • The created record should be stored in the same table shape as API-imported records
  • Admin Data List Page: many records
    • The page should list the primary non-user records of the application for management
    • API-imported records and manually created records should be shown together
    • The list should include logical filtering and sorting options based on the record properties
    • The list should include a limit field between 1 and 100
    • Server-side code should validate the limit and default to 10 when the submitted value is invalid
    • A filter with no matching records should show a clear no-results message
    • Each list item should show a useful summary rather than dumping every column
    • Each list item should link to its detail page
    • Admin list items should include the management links needed for edit and delete workflows
    • Design/style must be applied; the page cannot be a plaintext dump
  • Admin Edit Data Page
    • The record should be fetched by id from the query string
    • Missing or invalid id values should redirect back with a friendly message
    • The form should follow the same field, validation, and feedback patterns as the create page
    • The form should prefill with the existing record values
    • System-managed fields like id, created, and modified should not be editable
    • API identity/source fields should only be editable when that is part of the project design
    • Successful updates should keep the user on the edit page, show a friendly flash message, and show the updated data
  • Admin Delete Handling
    • The delete action should identify the record by id
    • Missing or invalid id values should redirect back to the list page with a friendly message
    • Delete behavior should enforce the correct role or access rules
    • The project should consistently use either hard delete or soft delete for this data
    • Successful deletion should redirect to the list page or previous page with a friendly flash message
  • Non-admin Data List Page: many records
    • There should be at least one general user list page with links to a detail view
    • The page should list API-imported records and manually created records together
    • The non-admin list can reuse the same filter, sort, limit, no-results, and summary display behavior from the admin list
    • Users who cannot manage records should not see edit or delete links
    • Design/style must be applied; the page cannot be a plaintext dump
  • View Data Details Page: single record
    • The record should be fetched by id from the query string
    • Missing or invalid id values should redirect back with a friendly message
    • The page should show more detail than the list/summary view
    • Edit and delete links should appear only for the roles allowed to use them
    • Design/style must be applied; the page cannot be a plaintext dump

Milestone 3 (7)

Milestone 3 proves that project data can be associated with users. This is the relationship layer of the project: favorites, watchlists, saved items, assignments, purchases, recipe builders, or another project-specific relationship.

These are the minimum requirements for this milestone. You may include additional pages or workflows that better match your project vision as long as they do not conflict with or contradict a requirement.

  • Define the association between users and project data
    • Use a relationship table when many users can be associated with many records
    • The relationship table should include id, the relevant user id, the relevant entity id, created, and modified
    • Duplicate relationships should be prevented with validation and database rules unless you have a specific use-case for duplicates
    • Removing an association should remove the relationship, not the user or the entity
    • The project should have a clear rule for what happens when an associated entity is updated manually or through the API
  • Add association behavior to the application
    • Users may associate records with themselves when that matches the project, such as favorites, watchlists, or saved items
    • An admin or other allowed higher role may associate records with users when the relationship is assigned by the application
    • The pages that create or remove associations should enforce the appropriate role or ownership rules
  • Logged-in user's associated records page
    • The page should show records associated with the logged-in user
    • Each line item should summarize relevant entity and relationship information
    • Each line item should link to the entity detail page
    • Each line item should include a way to remove the relationship when the current user or role is allowed to do so
    • The page should include a way to remove all associations for the current user or selected user when the current user or role is allowed to do so
    • The page should show result counts, including the number of matching associated records and the number currently shown
    • The list should include logical filtering and sorting options based on the entity properties
    • The list should include a limit field between 1 and 100
    • Server-side code should validate the limit and default to 10 when the submitted value is invalid
    • A filter with no matching records should show a clear no-results message
  • All-associated records page
    • This page should be limited to an admin or another authorized role when the data should not be public
    • This page should show relationship rows across multiple users
    • Each line item should summarize the user, entity, and relationship
    • Each line item should include the username for the associated user
    • The username should link to that user's public profile
    • Each line item should link to the entity detail page
    • Each line item should include a way to remove that relationship
    • The page should show result counts, including the number of matching relationships and the number currently shown
    • The list should include logical filtering and sorting options based on the entity properties
    • The list should include a partial username filter
    • The list should include a limit field between 1 and 100
    • Server-side code should validate the limit and default to 10 when the submitted value is invalid
    • A filter with no matching records should show a clear no-results message
  • Unassociated records page
    • This page should be limited to an admin or another authorized role when the data should not be public
    • This page should show project records that are not associated with any user
    • Each line item should summarize relevant entity information
    • Each line item should link to the entity detail page
    • The page should show result counts, including the number of matching unassociated records and the number currently shown
    • The list should include logical filtering and sorting options based on the entity properties
    • The list should include a limit field between 1 and 100
    • Server-side code should validate the limit and default to 10 when the submitted value is invalid
    • A filter with no matching records should show a clear no-results message
  • Association assignment page
    • The page should let an authorized role search for users and entities before applying associations
    • The entity search should use an entity identifier, name, title, or other user-friendly property
    • The user search should use a partial username match
    • Search results should show matching entities and matching users, with a maximum of 25 results for each side
    • The results should be shown in two clear groups or columns, similar to the User Role Assignment admin page
    • Each entity and each user should have a checkbox
    • Applying the form should create missing relationships and remove existing relationships for the selected user/entity pairs
  • Public profile page
    • Public profile links should show the user's username but link to the profile page by their id
    • The public profile should show safe public user information
      • A safe example option is to show that user's associated items
    • The page should not reveal private account details such as email, roles, or internal session information