Android (Jimmy): The function of GOLD login has completely transferred to Google OAuth. It is available in Google Play Store 10 days ago. More than 70% of active users have updated to the newest version.
iOS (Henry): Henry has removed the Schedules information from the iOS app. He has also remove the username/password login screen. This was a great compromise to ensure the security of the students data.
Android (Jimmy) / Heroku (Jimmy): Jimmy will be adding a new secured endpoint onto the Heroku service which will provide data for the mobile apps. Jimmy will start working on transitioning the Android app over to use the new endpoint. Jimmy will also look into removing functionality from the unsecured endpoint to retrieve Schedules data.
iOS (Henry): Once the new secured endpoint becomes available, Henry will begin looking at updating the iOS app to use the secured endpoint. He hopes to have that transition done before the end of the summer.
Meal Plans - Uses access card information. The username/password for the access card system (https://accesscard.campuscardcenter.com/ch/login.html), which doesn't use ucsbNetId/password, has a separate website which is currently being screen scraped.
Seth Northrop had previously mentioned that there's a way to get into the access card system with ucsbNetId/password (Gary Scott / Mike Smith might know)
iOS application updated to use the Heroku Web API to retrieve Student Schedule information. This has been released in the iOS App Store on
The Heroku webservice endpoint has not yet been secured. Work on this is being researched and planned. This has been communicated to be the highest priority and expected completion will be by the next meeting, .
There was discussions about a need for an API endpoint which would list all the quarters in which a student has attended. The discussions resulted in a request for a written up Use Case describing the full the needs and reasons behind those needs. If provided, then use case will be used to begin a conversation with the Registrar's Office about developing an new endpoint and setting up access to other existing APIs.
Looks like all the initial Improvents have been completed!
The iOS product might take a bit before it gets approved in the Apple store. It's going through an audit.
Schedule Planner - User can select several courses. And the app will try to figure out the best classes for the current courses.
(Maybe on the future plans) Be able to plan out future quarters.
Seth - Registrar is doing some upgrades on their degree auditing system to get a planning solution in the student facing applications (GOLD / etc).
Curriculum Information
Could Restrictions (major restrictions / minor restrictions) be included?
Could the Full Title be included?
Could the Prerequisites be included?
Sometimes the Description is missing spaces (like two words are connected together).
Could these fields have their definitions improved?
class
contactHours - Total hours of a course, including class time and discussions (if applicable)
classSection
secondaryStatus - When any primary section has secondary sections, such as discussion or labs, these sections must be marked as required or optional.
concurrentCourses - Courses that happen at the same time/location with the same instructor, but are listed under a different course title (generally for a different department/major).
Would it possible to setup the endpoint to return just a specific field (if that improves performance)?
One field in particular of importance would be the enrolledTotal.
The curriculum API feels slow
Seth - The Registrar team is actively investigating this
Jimmy will update the API Access request to ask for access to the endpoint and the addition of the Pass Time fields. Seth will check with Anthony that this is okay to add in, and Nikhil will add the functionality before ending his work on the API Expansion project.
Check with Gary Scott / Mike Smith if there's an API behind the Access Card information
- It doesn't look like the API may accomodate the specific use case we're looking for without special programming around their API. ARIT (Gary Scott / Mike Smith) have noted that they will keep this in the background of their efforts but they don't really have resources to dedicate to it.
