All OpenMRS ID accounts have been reset.

Read more and change your password before signing in.
Icon

EXTENDED: OMRS14 Proposals due 30 April! Read more and submit a proposal at OpenMRS Talk.

Skip to end of metadata
Go to start of metadata

Primary mentor

Ben Wolfe

Backup mentor

Burke Mamlin

Assigned to

Gaurav Paliwal


Introduction

Basic Description about this module is available here .

Workflow

Flow Chart for Feedback Submission
Gliffy Zoom Zoom Flow Chart for Feedback Submission
Administrator FLOW Chart for Feedback Module
Gliffy Zoom Zoom Administrator FLOW Chart Feedback Module
Use Case OpenMRS Feedback Module
Gliffy Zoom Zoom Use Case GSOC 2011 OpenMRS Feedback Module

Database Schema

Tables

Relations that will be required for the General Feedback Mechanism

  1. feedback_feedback
  2. user_properties
  3. feedback_severity
  4. feedback_status
  5. feedback_predefined_subject

In order to give clear distinction between the module tables and the other tables, the tables created while installing will have prefix “feedback” , this will help to prevent the name collision with other modules.

feedback_feedback

Attribute Name

Intention

Properties

feedback_id

This will be the unique ID number to identify each and every feedback.

  1. Int(11) --Quite Large to hold about 9^11 feedback.
  2. Primary Key
  3. Index (preferably BTREE based implementation)

creator

This will be the user id of the user, that has submitted the feedback.

  1. This is the foreign key that references the user_id attribute of the openmrs.users relation that is already existing in the table.
  2. This key is basically used for users mapping
  3. This key is can't be null ( NOT NULL Attribute )
  4. Size int(11) , same as that of user_id in users attribute.

subject

This is the subject of the feedback that the user is submitting.
( predefined as well as customed allowed )

  1. size varchar(255)
  2. This can't be NULL (NOT NULL attribute)

content

This is the content of the feedback that the user has submitted.

  1. size varchar(5000)
  2. Only simple plain text is allowed.
  3. This can't be NULL (NOT NULL attribute)

severity

This is used to tell the severity of the feedback.
(pre defined level)

  1. Size varchar(25)
  2. This attribute can't be NULL

comment

This field is used to store the administrator action over the feedback

  1. Size varchar(5000)
  2. This attribute can be NULL

status

This is used to store the current status of the feedback.
(pre defined level)

  1. Size varchar(25)
  2. This attribute can be NULL

date_created

This is the used to store the time at which the user has made submitted the feedback

  1. This will generated by the database trigger. This will be generated before the insert operation of the every new feedback.
  2. Type : Date

date_changed

This is the used to store the time at which the administrator has made the comment on feedback.

  1. This will be generated by the database trigger. This will be generated before the update operation of the comment.
  2. Type : Date
user_property

Following property will exist for all system users specific to the feedback mechanism module :

creator
email_id
phone_number
receipt_preference
followup_preference

feedback_severity

Attribute Name

Intention

Properties

index

To store the index of the severity table

AUTO_INCREMENT , NOT NULL

severity

This stores the predefined severity level by the administrator. I have intentionally not declaring it as a foreign key to the relation feedback(severity).
It can be on a scale of 1,2,3... or something like urgent , extremely severe,@ urgent etc.
So, that the user can pick the severity level from the drop-down while submitting the feedback.

Varchar(50)
Not a Primary Key, as there is no need to have index built over this attribute, resulting in decrease in system performance.

feedback_status

Attribute Name

Intention

Properties

index

To store the index of the severity table

AUTO_INCREMENT , NOT NULL

status

This stores the current status of the feedback that is submitted by the user. I have intentionally not declaring it as a foreign key to the relation feedback(status).
So, that the administrator can select the current status from the drop down while reviewing the feedback.

Varchar(50)
Not a Primary Key, as there is no need to have index built over this attribute, resulting in decrease in system performance.

feedback_predefined_subject

Attribute Name

Intention

Properties

index

To store the index of the severity table

AUTO_INCREMENT , NOT NULL

subject

This stores some of the predefined subject of the feedback, which user MAY choose while submitting the feedback.
Predefined subject may includes subjects like System is running slow , add a new concept etc etc

Varchar(50)
No Indexing.

UI Mockups

Header

Feedback Submit Form

Admin Panel for Predefined Subject

Admin Panel for Severity

Admin Panel for Status

AdminList view for Feedback Module

Manage Feedbacks

Manage Feedback

Feedback Module Preferences

Java Classes

feedback
Attributes

        Private int feedbackId
        Private int creator
        Private String subject
        Private String content
        Private String severity
        Private String comment
        Private String status
        Private Date dateChanged
        Private Date dateCreated
        

functions

            Public setTicket                 ( int feedbackId  )
            Public  setSubject                 ( int feedbackId  , String subject )
            Public setContent                 ( int feedbackId  , String content )
            Public  setSeverity              ( int feedbackId  , String severity )
            Public  setComment             ( int feedbackId  , String comment )
            Public  setStatus                 ( int feedbackId  , String  Status )
            Public  setSubject                 ( String subject )
            Public  setContent             ( String content )
            Public  setSeverity              ( String severity )
            Public  setComment             ( String comment )
            Public  setStatus                 ( String  Status )
            Public  int getFeedbackId          ( int feedbackId  )
            Public  int getCreator             ( int feedbackId  )
            Public  String getSubject             ( int feedbackId  )
            Public  String getContent             ( int feedbackId  )
            Public  String getSeverity             ( int feedbackId  )
            Public  String getComment             ( int feedbackId  )
            Public  String getStatus             ( int feedbackId  )
            Public  Date getDateChanged     ( int feedbackId  )
            Public  Date getDateCreated    ( int feedbackId  )

severity
Attributes

        Private String severity ;
        Private int index ;

Functions

        Public setSeverity     ( String severity ) ;
        Public setSeverity     ( int index , String severity ) ;
        Public getSeverity     ( int index ) ;
        Public int  getIndex     ( String severity ) ;

status
Attributes

        Private String status ;
        Private int index ;

Functions

        Public setStatus     ( String status ) ;
        Public setStatus     ( int index , String status ) ;
        Public getStatus     ( int index ) ;
        Public int  getIndex     ( String status ) ;        

subject
Attributes

        Private String subject ;
        Private int index ;

Functions

        Public setSubject     ( String subject ) ;
        Public setSubject     ( int index , String subject ) ;
        Public getSubject     ( int index ) ;
        Public int  getIndex     ( String subject ) ;

Timeline

Timeline

Outcome

26 April – 15 May

-SRS Submission/fixation , UI finalization-

15 May -20 May

-Basic Module Design , Database , Configuration will be ready-

20 May -5 June (2 Days OFF for exams)

Administrator panel to be ready

6 June – 15 June

User panel to be ready

15June – 30 July

Testing , mailing list reviews , changes to be done , Documentation

30 July – 15 August

Finalization and final polishing

Goals

Mid Term Goals

The basic module will be ready that will be having all the functionality listed on this page.

Final Goals

1. Basic General Feedback Module ready with test cases

2. Proper Documentation

3. Adding Extra Credit functionality in case time allows.

  • No labels

4 Comments

  1. Gaurav, great documentation!

    During your design, please allow for the simplest use case of clicking a feedback button, writing a comment in a textarea, and submitting – i.e., provide a default for other fields or make them optional.

    Some admins may wish to hide (disallow) file upload.

    Cheers,

    -Burke

  2. Okey, I will do one things add a Module setting page where Admin can select which field he/she want their user to fill , where admin can check/uncheck requirement for subject/attachment/Page Context etc.

    Will that be okey ?

    With Regards,

    -Gaurav Paliwal

    1. Thats a good idea and can be an "extra credit" item.  Don't focus on that because it might hold up just being able to release functionality at the end of the summer if you don't get some things done.