1. Copyright Office Material Copyright Request System

2. Current System

3. The copyright office provides review and permission services for course related copying. Current system involves submission of an excel file with selections and sources for each class. One main resource and at times temporary help for reviewing all requests. Overview

4. Tracking is done largely by paper and a very large master excel sheet. Tracking points often change. Permission sources can change frequently. Lots of tedious manual work preformed by one person. Overview

5. Our System

6. Simplify submission of forms by moving the excel submission to an online form. Aid in tracking and generating reports about submissions. Reduce input errors which are costly to find and correct. Reduce or eliminate the ever changing submission form and tracking spreadsheet. Goals

7. Back: Django (Python) Django Rest Framework SQLite Front: Angular Technologies

8. Component Architecture

9. Django is widely used so there is lots of documentation for it Decided to use REST so that we decoupled the back and front end. This allows for easy altering of front end structure or adding of new access points for example an iPhone app. Angular for the front end as it is currently very popular. This enables us to learn a new framework that is also well supported. Architecture Choices

10. Challenges

11. Issue: Django and Django REST did not always provide easy solutions to the types of data CRUD we needed. Solution: A combination of plug and play Django REST code, lower level API code and custom overrides. Framework

12. Issues: Shibboleth makes development & testing hard plus Django does not have base support for this authentication scheme. Solution: Circumvented the more traditional 3 rd party Django authentication implementations. Created our own handler for retrieving authentication credentials which we could then inject a mock user for development and testing. Authentication

13. Issue: The excel sheet converts into a very long web form. Solutions: Split the form up into a wizard style input where sections are input one at a time. Fields are organized on the screen relative to the amount of input space needed. This means more fields can fit on the same amount of screen space. Web Forms

14. Bad Form Example

15. Better Form Example

16. Issue: Users often make mistakes inputting form data. These mistakes make processing slower. Solutions: Have the system validate what ever it can. If possible hook it up to a library system that can pull source information. Allow staff to tag sources as verified. Then allow users to search for and use these instead of inputting new ones. User Input

17. Issue: Certain input fields have a select set of available options. These options can change frequently. Solution: Fields that are liable to change often are backed by the database and can be added to and altered. No delete. Modifiable Lists

18. Issue: The kinds of information the office would like to track can change. Solution: Augment the base set of fields with tags. Staff can add any number of custom tags to a request or selection and search on these tags later. Meta Data

19. Issue: Django migrations are useful but very hard to keep aligned with multiple people working on different branches all making potential migration changes. Solution: Migrations were never pushed to the repository. If you pulled code you would make migrations locally but never put it on the repository. Part of the build process was to make migrations and include them as part of the build. This means that every build has 1 set of new migrations. Migrations

20. Lessons Learned

21. Authentication implementation should be done as early as possible. Injecting security later is both difficult and prone to mistakes. Identify what data needs to be stored, base data, and what can be derived or augmented later. Manage client expectations. A good solid base system that can be extended is better than a system with more features but build on a shaky foundation. Lessons

22. Keep team communication flowing. Divide your sprint into smaller manageable sections. For example features should be done well before the sprint end to leave time for testing and making a build. Consider all frameworks/languages you want to use/support early on. Ex. Karma/Jasmine does not support python 3. Lessons