Summary

The ScheduleDB project consists of a set of micro-services that allow a user with administrator credentials to login and maintain the database collections of Teams, Users, Venues and Meeting Schedules.  The user facing services include:

  • frontend : a User Interface for login and data management.
  • website: a micro-service implementation of the current tssg.tech website.  Includes a schedule page that automatically updates with the next three General Meeting schedules.

History

For the last few years that tssg.tech has had a page to list the upcoming schedules: a developer, like Joel Sharasheff, had to make code changes every week to keep the page updated. 

The ScheduleDB project was born out of a need to create a process whereby any authorized user could make the schedule, venues, teams and user changes into a database once.  The website (tssg.tech) would then update the schedule page automatically every week.

TSSG Management Responsibilities

Before these implemented services can be deployed to replace the tssg.tech production website, the Web Team is requesting that all TSSG Management stakeholders test the frontend and website services.  Management will then update the TSSG Management Input table below for a (tick)Go or (error)No-Go vote to Production along with Constructive Feedback.

Management will also need to decide who will update the General Meeting Schedules within the services.

Access

Access to the development instance of the FrontEnd Service is available by navigating your browser to the development endpoints: 

Login credentials for the administrator "admin" will be provided to the tssg-management group in an email.

Once you have logged in as admin, please create an administrative user for yourself to do the testing.  Log out as admin and then login as your newly created user.

TSSG Management Input

Please update this table with your Vote and/or Feedback.

ManagerTeam

Vote

  • (tick)Go
    or
  • (error)No-Go
Comments / Constructive Feedback
TSSG(tick)Go

Found the functionality adequate for the current tasks required.

Future:

  • Copy/Paste meeting info (or a duplicate function)
  • Schedule multiple dates at same venue
  • Ability to store comment data:
    • meeting minutes
    • information links
    • graphics/images
Mark PralatMobile Group(tick)Go

It worked as expected. I created the mobile group, added meetings etc.

Some areas need some refinement:

  • was able to enter incorrect email addresses, e.g. 0@1 was accepted.
  • long (150 digits) numbers were valid entries for first name and last name
    1. this has been addressed (does someone know a Jira ticket ID?)  BUT
    2. until we incorporate a feature to convert into tinyURLs, the new size limits for Website and Calendar URLs are too restrictive – should be at least the 254 we allow for Location (Map URL)
  • Adding venue - Mobile Hangout - can only list Busy Body as contact. Cannot unselect.
  • meeting - need to create venue first, just document venue needs to be created first.
Ray BloomQA Study Group

(tick)Go

Good work by all involved; sufficiently implemented and functional to release and start using.

  • Change the title element of the initial frontend page to something more meaningful than "TssgDbApp"
  • All frontend page titles should, perhaps, be something other than, for example, "TSSG Home", as that's not really the actual TSSG home page that people will see when they go to http://tssg.tech
  • Very long table values (such as the first and last name fields in the users' list) make it almost impossible for a user to scroll all the way to the right to use the Edit or Del buttons on the correct entry.  (Perhaps move the buttons to the far left on all tables, make the long fields/columns individually horizontally scrollable, or limit the length of data)
  • Move the descriptive text for the list pages (e.g., "A list of all venues currently in the database.") to the top of the page, perhaps between the page title and the table headers
  • We probably shouldn't allow whitespace in a username
  • Usernames are case-sensitive during login, this is non-standard IMHO
  • Home page (after user successfully logs in) should show username (either in addition to or instead of user's first and last names)
  • TWS-340 - Getting issue details... STATUS Add copyright in footer
  • On the "List Team Schedule" page, the on-page title shouldn't be "Select Team Name"
  • On the "List Team Schedule" page, move "(select one)" hint into the dropdown box as its hint
  • Add the capability for a user to see which teams they belong to (perhaps just dump it out on the "Current User" page, but it might also be useful for an admin to see all the teams each user is a member of
  • Add tips for when the user hovers over (with a mouse or whatever) a field name in all pages
  • Sometimes, when I'm adding data and click Add, I see the pink flash of an error message, but it's gone so fast, I can't capture it
  • When creating a new team, the specified team lead should be considered to be added as a member so as to not get the "At least one member is required" and/or "One or more team members are required." error
Web Team

(tick)Go

WebTeam approval is a given, our Jira is full of details

  • But we are turning these observations into backlog tickets
  • and at least Jim has made note(s) on others' observations, to address in these tix
DevOps Team

(tick)Go

  • (green star) Pushpa did a PoC for SonarQube; a static code analyzer.
  • We deployed SonarQube to sq.technologynursery.org.  The tool initially found over 300 potential vulnerabilities and bugs.  These included WCAG2 issues.
  • (green star) Paul has fixed all bugs and potential vulnerabilities found by SonarQube.

Norm Heckman

Alan Rawsthorne

Data Analytics Team(tick)GoApproval by Alan on behalf of Norm, but any feedback we have from any Data team members came from discussions in Data Science group, see below
Data Science Learning Team(tick)Go

Scheduledb Feedback

  1. TWS-339 - Getting issue details... STATUS Suggestion for recurring events. 
  2. TWS-341 - Getting issue details... STATUS Suggestion for automatic Zoom invite sent at meeting creation allowing invitees to add zoom meeting for example to their google calendar(or other calendar). 
  3. TWS-342 - Getting issue details... STATUS Suggestion for single login i.e. using Facebook or Google account.
  4. TWS-343 - Getting issue details... STATUS Suggestion to display the time zone the meeting times are using.
  5. TWS-345 - Getting issue details... STATUS Suggestion to further define and improve on the phone number entry.
Lora BatesTSSG

Conclusion

When all of TSSG management has approved these services for production, the following steps will be done:

  • We will follow the guidelines for code review as specified in Requesting a merge to scheduledb of your code contributions.
  • The scheduledb branch will be merged into the master branch.  The master branch contains the state of the current tssg.tech web site.
  • The database will be compared to the data on the current site and updated to match
    • We should split up the List All pages and each Web Team member update his/her collection data vs the True Data
    • Afterward, do the same for the static pages in the new Site folder.  Jim Turner  (or when it is done) Let client make modifications to either the database (through the FrontEnd) or raise tickets for the Web Team to change the Site content as necessary.
    • Final step: see to it somehow that this (newest) data is in the (initializing) db saved in the Git repository.  Not needed because the db is persistent.  Just change the data through the FrontEnd UI.
  • Ralph A. Navarro Jr. Upgrade a13 storage from 128G to 512G
  • A Jenkins project will deploy the master branch to a staging (i.e. QA) endpoints.  
    • decide the names of the services' subdomain endpoints
    • Ralph A. Navarro Jr.  configure Nginx to reverse-proxy them to the underlying services
    • Paul Scheidemantel  Enable scheduledb.env working in private branch taken from master branch
      to configure either dev or prod endpoints by passing an environment variable (deployEnv) option (default=dev) to scheduledb.env.
    • Paul Scheidemantel  Create a prod.install for deploying scheduledb to prod.
    • Ralph A. Navarro Jr.  configure Jenkins
    • Ralph A. Navarro Jr.  execute the deploy
  • Automated and manual tests will be run against the staging production area.  This will verify that the merge has happened successfully before moving to the next step in the pipeline.  Corrections will be made if needed until the staging area quality can be assured.
    • create "smoke" tests to verify service inter-connectivity
    • enhance code coverage for all UX features
  • Another Jenkins project will deploy the master branch to the production endpoints.  We will be 
  • Automated and manual tests will be run against the production endpoints.  This will verify the quality of the production endpoints.  Corrections will be made if needed until the production area quality can be assured.
  • Once in production, create a backup script to backup the database data periodically (either cron job or manually).


  • No labels