3.1.1 JournalHub Database (Gabriel Marquez and Zobair Alijan)
This section details the requirements the JournalHub database must meet in order to
provide the desired interface between the student Product Website and the
3.1.1.1 Database Login
The Local Login section specifies the type of account which needs to be present so that the
machine hosting the JournalHub web page and database can execute queries necessary for
User Interface functionality.
3.1.1.1.1 Local Login
There must exist a password protected account which has full privileges over the JournalHub
database when logging in from localhost machines.
3.1.1.1.2 Remote Login
The Remote Login section specifies the type of accounts which needs to be present so that
Product Websites may execute queries on the JournalHub database from the remote machines
on which they reside.
3.1.1.1.2.1 There must exist a password-protected account which has full privileges over the
JournalHub database when logging in from any non-local IP address.
3.1.1.1.2.2 Queries made through non-local IPs will be performed through the User Interface.
3.1.1.2 Entities
Entities describe database tables which represent actual or conceptual objects. In the
JournalHub system, database entities consist of the users of TPOT and the objects created by
students during collaboration using their Team Sites.
3.1.1.2.1 Publication
A publication represents a physical newspaper populated with articles, images, and
other information. Space for each respective object is partitioned with the budgeting system. It
is organized based upon the day, month, and year it is printed, which is unique for each
publication.
3.1.1.2.1.1 The JournalHub database must contain a Publication Table.
3.1.1.2.1.2 For every entry, the JournalHub publication table must store a publication’s:
a. Print Identifier
b. Page Number
c. Date
d. Slug
Attribute
Datatype
Key
Requirements
Null
Title
String
Primary
Auto-Increment by 1
Not Null
Notes
Key
Page_Num
Integer
Date_Printed
Timestamp
Not Null
Must default to
Not Null
SYSDATE when record
is created
Slug
String
Foreign Key
Not Null
3.1.1.2.1.3 It must be possible to insert new values into the publication Table.
3.1.1.2.2 Tasks
A task represents an assignment given by one staff member to another. They are time
sensitive, and require confirmation of completion.
3.1.1.2.2.1 The JournalHub database must contain a Task Table.
3.1.1.2.2.2 For every entry, the JournalHub Tasks table must store a Task's:
a. Completion Status
b. Author
c. Date Authored
d. Date Modified
e. Task_Name
Attribute
Datatype
Compeltion_Status
Boolean
Author
Integer
Date_Added
Key
Requirements
Null
Not Null
Foreign
Maintain First and
Key
Last Name
Timestamp
Must default to
Not Null
Not Null
SYSDATE when
record is created
Date-Modified
Boolean
Task_Name
String
Not Null
Primary
Not Null
Key
3.1.1.2.2.3 It must be possible to insert new values into the Task Table.
3.1.1.2.3 Story
A story represents an account of an event, series of events, or subject.
3.1.1.2.3.1 The JournalHub database must contain a Story Table.
Notes
3.1.1.2.3.2 For every entry, the JournalHub table must have:
a. Length
b. Slug
c. Print Status
d.. Date_Added
e. Print Deadline
f. Author
g. Title
Attribute
DataType
Key
Requirements
Null
Print_status
Boolean
Foreign Key
Will appear in
Not null
publication table if 1
Print_deadline
Timestamp
Not null
Length
Text
Not null
Slug
integer
Foreign key
Not null
Title
Text
Primary Key
Not
Null
Date_Added
Timestamp
Not
Null
Author
Text
Foreign Key
Not
Null
3.1.1.2.3.3 It must be possible to insert new values into the Story Table.
Notes
3.1.1.2.4 Users
3.1.1.2.4.1 The JournalHub database must contain a User Table.
3.1.1.2.4.2 For every entry, the JournalHub User Table must store:
a. Section
b. Personal data
c. Permissions
d. Name
e. Task List
Attribute
Datatype
Section
Timestamp
Personal
Text
Permission
Text
Name
Key
Requirements
Null
Notes
Not Null
Foreign Key
Not Null
Not Null
Primary Key
Not Null
3.1.1.2.4.3 It must be possible to insert new values into the User Table
3.1.1.2.5 Event
An event represents a specific occurrence at a particular place and time.
3.1.1.2.5.1 The JournalHub database must contain a Event Table.
3.1.1.2.5.2 For every entry, the JournalHub event table must store the Event's:
a. Date
b. Name
Attribute
Datatype
Key
Requirements
Null
Notes
Date
Timestamp
Name
Text
Date of Occurrence
Primary Key
Not Null
Not Null
3.1.1.2.5.3 It must be possible to insert new values into the Event Table.
3.1.1.2.6 File
Files represent documents that contain information pertaining to individual stories.
3.1.1.2.6.1 The JournalHub database must contain a File Table.
3.1.1.2.6.2 For every entry, the JournalHub File table must store the File's:
a. Date Added
b. Date Modified
c. Author
d. Slug
e. File Name
Attribute
Datatype
Date_Add
TimeStamp
Key
Requirements
Null
Data must be time of
Not Null
inclusion into the
database
Date_Mod
TimeStamp
Date modified must
Not Null
be most current
revision
File Name
Text
Primary Key
Author
Text
Foreign Key
Must be Unique
Not Null
Not Null
Notes
to User
Slug
Text
Foreign Key
Not Null
to User
3.1.1.2.6.3 It must be possible to insert new values into the File Table
3.1.1.2.7 Event_Signup
List of staff who are assigned to events
3.1.1.2.7.1 The JournalHub database must contain a Event_Signup Table.
3.1.1.2.7.2 For every entry, the JournalHub File table must store the Event_Signup:
a. Staff_Name
b. Event_Name
Attribute
Datatype
Key
Staff_Name
Text
Primary
Requirements
Null
Not Null
Key
Event_Name
Text
Primary
Not Null
Key
3.1.1.2.7.3 It must be possible to insert new values into the File Table
3.1.1.2.8 Story_Signup
List of staff who are assigned to story
3.1.1.2.8.1 The JournalHub database must contain a Story_Signup Table.
3.1.1.2.8.2 For every entry, the JournalHub File table must store the Story_Signup:
Notes
a. Staff_Name
b. Story_Name
Attribute
Datatype
Key
Name
Text
Primary
Requirements
Null
Notes
Not Null
Key
Story_Title
Text
Primary
Not Null
Key
3.1.1.2.7.3 It must be possible to insert new values into the File Table
3.1.1.3 Relations
Relations describe database tables which represent some association between entities. In the
JournalHub system, database relations are used to track the Activities of Users.
3.1.1.3.1 Staff-Tasks
The Tasks relation records instances of User interaction with Task entities. Tasks in the
JournalHub database must conform to the following functional requirements:
3.1.1.3.1.1 The JournalHub database must contain a table representing the actions taken by
Users on Tasks. This table is the Tasks table, and a change will result in the change of one row
element.
3.1.1.3.1.2 For every entry, the JournalHub Tasks table must store:
a. Completion Status (Section 3.1.3.2.2)
b. Author (Section 3.1.3.2.2)
c. Date Authored (Section 3.1.3.2.2)
d. Date Modified (Section 3.1.3.2.2)
e. TaskName (Section 3.1.3.2.2)
3.1.1.3.2 Staff Add Event
The Staff Add Event relation records instances of staff adding, removing, or modifying an event.
Staff Add Event in the JournalHub database must conform to the following functional
requirements:
3.1.1.3.2.1 The JournalHub database must contain a table representing the actions taken by
Staff on Events. This table is the Event table, and a change will result in the change of one row
element.
3.1.1.3.2.2 For every entry, the JournalHub Tasks table must store:
a. Date
b. Name
3.1.1.3.3 Staff Event Signup
The Staff Event Signup relation records instances of staff adding, removing, or modifying an
event. Staff Event Signup in the JournalHub database must conform to the following functional
requirements:
3.1.1.3.3.1 The JournalHub database must contain a table representing the actions taken by
Staff on Events. This table is the Event_Signup table, and a change will result in the change of
one row element.
3.1.1.3.3.2 For every entry, the JournalHub Event_Signup table must store:
a. Event_Name
b. Staff_Name
3.1.1.3.3.3 The JournalHub database must contain a Story_Signup Table.
3.1.1.3.4 Staff Author Story
The Staff Author Story relation records instances of staff adding, removing, or modifying a story.
Staff Author Story in the JournalHub database must conform to the following functional
requirements:
3.1.1.3.4.1 The JournalHub database must contain a table representing the actions taken by
Staff Author Story. This table is the Story table, and a change will result in the change of one
row element.
3.1.1.3.4.2 For every entry, the JournalHub Story table must store:
a. Length
b. Slug
c. Print Status
d. Date_Added
e. Print Deadline
f. Author
g. Title
3.1.1.3.5 Staff Story_Signup
The Staff Story Sign_up relation records instances of staff assignment to a story. Staff Author
Story in the JournalHub database must conform to the following functional requirements:
3.1.1.3.5.1 The JournalHub database must contain a table representing the actions taken by
Staff Story_Signup. This table is the Story_Signup table, and a change will result in the change
of one row element.
3.1.1.3.5.2 For every entry, the JournalHub Story_Signup table must store:
a. Staff_Name
b. Story_Name
3.1.1.3.5.3 The JournalHub database must contain a Story_Signup Table.
3.1.1.3.6 Staff Author File
The Staff Author File records instances of documents that contain information pertaining to
individual stories.
3.1.1.2.6.1 The JournalHub database must contain a File Table.
3.1.1.2.6.2 For every entry, the JournalHub File table must store the File's:
a. Date Added
b. Date Modified
c. Author
d. Slug
e. File Name
3.1.1.3.7 File Associates Story
The File Associates Story relation records instances of Files associating to a story. File
Associates Story in the JournalHub database must conform to the following functional
requirements:
3.1.1.3.7.1 The JournalHub database must contain a table representing the actions taken by .
This table is the File table, and a change will result in the change of one row element.
3.1.1.3.7.2 For every entry, the JournalHub Story table must store:
a. Date Added
b. Date Modified
c. Author
d. Slug
e. File Name
3.1.1.3.8 Story in Publication
The Story in Publication records instances of a story to a publication, Staff Publication in
JournalHub database must confirm to the following functional requirements:
3.1.1.3.8.1 The JournalHub database must contain a Story Table.
3.1.1.3.8.2 For every entry, the JournalHub table must have:
a. Author Name
b. Title Name
3.1.2 Backend (Ben and Adam)
This sections describes the notification and budgeting systems, which are part of a layer
not directly seen by the user. These systems must be implemented to provide core features to
JournalHub that require interacting with outside systems, such as email.
The backend will meet the following functional requirements:
3.1.2.1 Notification System (Ben and Adam)
This section details the notification system, which delivers notifications to users working on a
story. Notification messages will vary depending on updates and modifications to a story.
The notification system will meet the the following functional requirements:
3.1.2.1.1 Immediately alert end users on story development information.
3.1.2.1.2 Have sufficient context for end users to understand the relevance of the
notification.
3.1.2.3 Special dates and events (Ben and Adam)
This section details special dates, which authorized users can add to a calendar.
3.1.2.3.1 Authorized users must be able to create special dates.
3.1.2.3.2 Authorized users must be able to modify/ delete special dates.
3.1.3 Website (Adam, Ben, Mark, and Jason)
The user interface through which users will access the various functionalities of the
JournalHub system is the Website. This is a standalone application written in PHP and HTML.
Each page of the Website has its own criteria for requirements.
3.1.3.1 Login Page (Mark)
This section details the Login Page, which allows employees and administrators to
access the functions of the website. Login credentials will be provided by an
administrator. The Login Page must conform to the follow functional requirements:
3.1.3.1.1 Unauthorized users who visit the login page must request login
information from an administrator.
3.1.3.1.2 Authorized users must be able to submit their credentials for login
access.
3.1.3.1.3 Authorized users must be directed to the appropriate dashboard with
preset privileges.
3.1.3.1.3 Authorized users must be able to request new password.
3.1.3.2 Story Search Page (Mark)
This section details the Story Search Page, which allows users to search for articles
based on attributes. The Story Search Page must conform to the following functional
requirements:
3.1.3.2.1 Must allow authorized users to submit a search for the following
attributes:
a. Date added
b. Date modified
c. Author
d. Slug
e. File name
3.1.3.2.2 Must allow authorized users to sort the following attributes:
a. Date added
b. Date modified
c. Author
d. Slug
e. File name
3.1.3.2.3 Must allow authorized users to filter for the following attributes:
a. Date added
b. Date modified
c. Author
d. Slug
e. File name
3.1.3.3 Story List Page (Mark)
This section details the Story List Page, which allows users to view the list of related
stories according to their search inquiry. For details on what constitutes a search inquiry,
see section 3.1.3.2. The Story List Page must conform to the following functional
requirements:
3.1.3.3.1 Must list the following attributes for Story List Page:
a. Completion status
b. Author
c. Date published
d. Date modified
e. Tasks
3.1.3.4 New Story Page (Mark)
This section details the New Story Page, which allows authorized users to create a new
story. The News Story Page must conform to the following functional requirements:
3.1.3.4.1 Authorized users must be able to input the following requirements:
a. Length
b. Slug
c. Print status
d. Date added
e. Print deadline
f.
Author
g. Title
3.1.3.4.2 Authorized users must be able to edit content on the New Story Page.
3.1.3.5.3 Authorized users must be able to delete content on New Story Page.
3.1.3.6.4 Authorized users must be able to save content on New Story Page.
3.1.3.7.5 Authorized users must be able to resume content on New Story Page.
3.1.3.7.5 Authorized users must be able to submit content on New Story Page.
3.1.3.5 Story Page (Mark)
This section details the Story Page, which allows users to view a finalized story. The
Story Page must conform to the following functional requirements:
3.1.3.5.1 Authorized users must be able to view the completion status on the
Story Page.
3.1.3.5.2 Authorized users must be able to view the print deadline on the Story
Page.
3.1.3.5.3 Authorized users must be able to view a preview of the story on the
Story Page.
3.1.3.5.4 Authorized users must be able to submit article the Story Page.
3.1.3.6 Budgeting System (Ben and Adam)
This section details the budgeting system, which will allocate space for articles intended
to go into print. The budgeting system will meet the following functional requirements:
3.1.3.6.1 Authorized users must be able to create a new budget entry with
specified publication date.
3.1.3.6.2 Authorized users must be able to lookup an existing budget using the
following fields:
a.
Contained Story
b.
Date Created
c.
Date Published
3.1.3.6.3 Authorized users must be able to add stories to an existing budget entry
that has not yet been published.
3.1.3.6.4 :
a.
Publication date
b.
Page numbers
c.
Story locations
3.1.3.7 Events Page (Jason)
This aspect of the product will provide users with the capability to review and
manage event reminders. This page will be accessible from all other pages. This page
will display a list of Events to which the user is subscribed. The Events Page shall meet
the following functional requirements:
3.1.3.7.1 Shall support unsubscribing from an Event to which the user is
subscribed
3.1.3.7.2 Shall support subscribing to an Event to which the user is not already
subscribed
3.1.3.7.6 Shall display the Name for each event in the Event List
3.1.3.7.7 Shall display the Description for each event in the Event List
3.1.3.7.8 Shall display the Hashtag for each event in the Event List
3.1.3.8 Event Search Page (Jason)
This aspect of the product will allow the user to search for stories with the use of
various criteria. The Event search Page will be accessible from the Events Page. The
Event Search Page shall meet the following functional requirements:
3.1.3.8.1 Shall support searching for Events by subscription status
3.1.3.8.2 Shall support searching for Events by name
3.1.3.8.3 Shall support searching for Events by hashtag
3.1.3.8.4 Shall support searching for Events by timestamp range
3.1.3.8.5 Shall support subscribing to an Event in the search results if the user is
not already subscribed
3.1.3.8.6 Shall display the Name for each event in the search results
3.1.3.8.7 Shall display the Description for each event in the search results
3.1.3.8.8 Shall display the Hashtag for each event in the search results
3.1.3.9 Event Page (Jason)
This aspect of the product will provide users with information pertaining to a
particular event and allow changes to that information. Each Event will have its own
Event Page containing this information. If a user is the event author or has permissions
to edit Events (see INSERT_USERTYPE_TABLE), then this page will be accessible
from the Events Page for that user. The Event Page shall meet the following functional
requirements:
3.1.3.9.1 Shall allow editing of the event Name
3.1.3.9.2 Shall allow editing of the event Hashtag
3.1.3.9.3 Shall allow the user to remove subscribers from the Event
3.1.3.9.4 Shall allow the user to add subscribers to the Event by User Name (see
INSERT_USER_TABLE)
3.1.3.9.5 Shall allow editing of the event Timestamp
3.1.3.9.6 Shall allow the user to submit the changes for writing to the database
3.1.3.9.7 Shall allow deletion of the Event from the database
3.1.3.10 New Event Page (Jason)
This aspect of the product will provide users with the ability to create a new
Event. It will be accessible from the Events Page for users with permission to create a
new event (see INSERT_USERTYPE_TABLE). This page shall meet the following
functional requirements:
3.1.3.10.1 Shall require the user to specify the event Name
3.1.3.10.2 Shall allow the user to specify an event description of a length not exceeding
300 characters
3.1.3.10.3 Shall allow the user to specify the event Hashtags
3.1.3.11 Settings Page (Jason)
This page will allow the user to make changes regarding some of their profile information
as well as other settings. This page will be accessible from all other pages. This page
shall meet the following functional requirements:
3.1.3.11.1 Shall allow the user to change the contact email
3.1.3.11.2 Shall allow the user to change the account password
3.1.3.12 Administrator Page (Jason)
This page will grant access to various pages to perform functions that affect the entire
system or the status of other accounts. This page will only be accessible to administrator-level
users. This page will be accessible from all other pages. This page shall grant access to the
following pages:
3.1.3.12.1 Manage User Accounts Page
This page will allow the administrator-level user to make changes to the status of
other user accounts. This page will only be accessible from the Administrator
Page. This page shall meet the following functional requirements:
3.1.3.10.1.1 Shall allow the user to change the User Type of an account
3.1.3.10.1.2 Shall allow the user to change the Name of the account
3.1.3.10.1.3 Shall allow the user to change the Section for an account
3.1.3.10.1.4 Shall allow the user to edit the Task List for an account
3.1.3.10.1.5 Shall allow the user to edit the Personal Data for an account
3.1.3.12.2 Manage User Types Page
This page will allow the administrator-level user to make changes to the list of
user types except the default Admin user type, which will always have full
permissions.. This serves to allow the user to establish permissions presets that
can then later be assigned to a user account. This page is only accessible from
the Administrator Page and shall meet the following functional requirements:
3.1.3.12.2.1 Shall allow the user to modify the permissions for each user
type (see INSERT_USERTYPE_TABLE)
3.1.3.12.2.2 Shall allow the user to create a new user type
Creating a new user type will create a new
INSERT_USERTYPE_TABLE_NAME table and add it to the list of user
types.
3.1.3.12.2.2.1 Shall require the user to enter the name for the new
user type