Git Product home page Git Product logo

eduhub-org / eduhub Goto Github PK

View Code? Open in Web Editor NEW
10.0 3.0 7.0 147.01 MB

A comprehensive education platform focusing on course applications, event registrations, learning communities, and more.

Home Page: https://edu.opencampus.sh

License: GNU Affero General Public License v3.0

Dockerfile 0.09% JavaScript 5.33% CSS 5.42% TypeScript 69.55% PLpgSQL 3.31% FreeMarker 2.81% HCL 5.51% Shell 0.96% Python 7.00%
certificates courses education events hacktoberfest

eduhub's Introduction

EduHub 🎓

A comprehensive education platform focusing on course applications, event registrations, learning communities, and more.

Introduction

EduHub aims to centralize educational offerings. It enables users to apply and get accepted into courses, organize course information, manage project results, and issue certificates. It also supports micro-degrees.

Current Focus: Enhancing different application and registration processes, particularly for event registrations, and building stronger learning communities through a chat integration based on Mattermost.

EduHub Screenshot

🚀 Quick Start

  1. Install Docker.
  2. Clone this repository.
  3. Run docker compose up.
  4. Open localhost:5000 in your browser.
  5. Log in as [email protected] with password dev.

👥 Contributing

We welcome contributions from everyone. Please check out the technical details for the development here.

💻 Tech Stack

📝 License

This project is licensed under AGPLv3 License.

eduhub's People

Contributors

steffen74 avatar ericstumper avatar ckru-kiel avatar pct-cclausen avatar okwast avatar pct-fahmed avatar fschindler avatar dependabot[bot] avatar sina-cau avatar sertonix avatar freerafiki avatar bastibuck avatar virejdasani avatar

Stargazers

Fernando Bold avatar Boris Dudelsack avatar Malte Hecht avatar Regina Klünder avatar Khanh Ho avatar Matti Nannt avatar  avatar Daniel Banck avatar  avatar

Watchers

James Cloos avatar  avatar  avatar

eduhub's Issues

Projects Epic: Backend Table Changes

The initial goal is to allow for the definition and completion of projects (upload of documentation and results). However, additionally the structure must be flexible enough to generalize beyond the definition of projects as achievement certificates.

Details

The following new table are needed:

AchievementOption (table Project can be deleted)

  • id
  • title
  • description
  • recordType
  • documentationTemplateUrl
  • csvTemplateUrl
  • evaluationScriptUrl
  • showScoreAuthors
    Relationships
  • AchievementOptionMentors (Array: AchievementOptionMentors.achievementOptionId -> AchievementOption.id)
  • Course (Array: AchievementOptionCourses.achievementOptionId -> AchievementOption.id)

AchievementOptionMentor

  • id
  • achievementOptionId
  • expertId

AchievementOptionCourse

  • id
  • achievementOptionId
  • courseId

AchievementRecord (table ProjectEnrollment can be deleted)

  • id
  • achievementOptionId
  • description
  • coverImageUrl
  • documentationUrl
  • csvResults
  • uploadUserId
  • score
  • rating
  • evaluationScriptUrl
    Relationships
  • AchievementRecordAuthors (Array: AchievementRecordAuthor.achievementRecordId -> AchievementRecord.id)
  • AchievementOption
  • Course

AchievementRecordAuthor

  • id
  • achievementRecordId
  • userId

ENUM AchievementOptionType (table ProjectType can be deleted)

  • DOCUMENTATION_AND_CSV
  • DOCUMENTATION

ENUM AchievementRecordRating (table ProjectRating can be deleted)

  • UNRATED
  • FAILED
  • PASSED

Further, the table "Course" is changed as follows:

  • ProjectType --> field is deleted
  • OnlineCourseTitle --> field is deleted

Optional and Future Implementations

  • N/A

Cours Description (logged in and declined)

A user applied for a course but his application got declined. The corresponding status of the application shall be visible in the course description.

Details

  • The design of the site is the same as for logged in version without application pending, however, instead of the apply button, a status message including the following text is shown: "Leider wurde Deine Bewerbung auf diesen Kurs abgelehnt."

Optional and Future Implementations

  • NA

Course Administration - Applications (Part 3)

This issue is part of a series of four issues in total, where each issue is describing a view with a common top and bottom section.

Details

  • The URL of the site is: [domain]/course/?course_id=xyz&tab=applicants (however, you can also choose a different format)
  • The site is accessed by double clicking on corresponding row in the course overview table (see issue #41), by clicking on the corresponding tab in the top section in one of the related views, or by clicking on the "Next" button in the previous tab.
  • The design should be as follows:

Top section

  • See issue #50

Middle Section

  • This section includes a table with the information on the applications for the given course and with the option to rate each applicant's motivation letter and review basic information on the applicant.

  • Above and below the table is a legend for the four different ratings a motivation letter can be given.

  • The table includes the following five columns:

    • First name [Enrollment:UserId--User:Firstname]
    • Last name [Enrollment:UserId--User:Lastname]
    • Motivation letter [Enrollment:MotivationLetter] with the text truncated to fit the column width.
    • Motivation rating [Enrollment:MotivationRating] shown as a filled circle in the colors according to the legend.
    • Status [Enrollment:Status], which shows the applicants current enrollment status
      • If [Enrollment:Status] equals "INVITED" and the current date is after [Enrollment:ExpirationDate], it is not the icon for "Invited" shown but the one for "Expired" (see legend below).
      • Instead of a legend, the title of the current status is given via a tool tip on mouse over the status icon. The icons and titles for the 6 different status that are possible are given here.
  • Additional to the main fields each row of an application can be unfolded by clicking on the downward pointing arrow on the right. As soon as the application is unfolded the arrow points upwards. Collapsing the appplication is done by clicking on the arrow, which the again points downwards. It is possible to unfold as many applications as are shown. The fields shown in the unfolded status are:

    • on the left side: the applicants email address [Enrollment:UserId--User:Email]
    • the further information below the email address is optional (see comment below)
    • the full text of the motivation letter [Enrollment:MotivationLetter]
    • on the right side: a horizontal radio button element to set the rating of the motivation letter [Enrollment:MotivationRating]; when the rating is changed here, it is updated correspondingly in the table row above.
    • if the Status of the application [Enrollment:Status] equals "INVITED" a text field showing the expiration date of the invitation to participate [Enrollment:ExpirationDate] is shown below the radio button element.

Bottom Section

  • A "Next" button to proceed to the next tab (see issue #51). However, a change to the next tab is only possible if Course:Status is unequal to "DRAFT", "READYFORPUBLICATION", and "READYFORAPPLICATION". If the status does not have a corresponding value, it is checked whether the current state of fields allows for a status change. If the conditions are met the Course:Status field is changed to "APPLICANTSINVITED" and the next tab is opened. If the conditions are not met, an error message is displayed stating: "The next section is only available if at least one applicant conformed the participation!".
  • The conditions to change the status are:
    • at least one user confirmed the participation [Enrollment:Status=="CONFIRMED"].

Context Menu Actions

  • One or several applicants (i.e. rows) can be selected by clicking on it (for multiple rows using the combinations with the alt and ctrl keys) and by using the right mouse button a context menu can be opened.
  • However, only for admin users a context menu is opened (in the future there might also be a context menu for instructors), which includes the item "Invite", and by selecting the item a modal is opened to initiate the invitation of the selected participants; the form of the modal is described in issue #58

Optional and Future Implementations

  • Allow to adjust the column width
  • Add additional information on the left side of the unfolded application:
    • Employment Status [Enrollment:UserId--User:Employment]
    • The titles of the courses for other enrollments in the same program
    • The total number of enrollments for programs with an Program:End before the current date
    • The total number of participations [Enrollment:Status is equal to "CONFIRMED", "ABORTED", or "COMPLETED"] for programs with an Program:End before the current date
    • The total number of successful completions [Enrollment:Status is equal to "COMPLETED"]

Individual pages "project" and "online-course"

Currently the AchievementOption table includes the full info independent of being of the option being an online course or an achievement option.
The goal is to replace the AchievementOption table by corresponding tables Project and OnlineCourse. which have a corresponding relationship to the table AchievementOptionCourse.

original idea (might need to be revised and extended for online courses):
Users must not be logged in to see the single project view. However if a user is not logged in and wants to upload a documentation, the sign-in window opens, forcing them to log-in first.
Considering the download of the documentation any user is allowed to do that (open source approach).

For users who are enrolled for the shown project (i.e. user is logged in) and already uploaded a documentation before the view includes an additional section below the upload button, showing the file name of the last submitted project documentation, the authors and the date it was uploaded.

Details

  • All views are mobile first, the desktop views should follow as much as possible the design of the desktop view for a course.
  • For achievement options of type DOCUMENTATION_AND_CSV the design is given here.
  • For achievement options of type DOCUMENTATION for a logged in user with previous uploads, the design is given here.
  • For achievement records of type DOCUMENTATION the design is given here.

Optional and Future Implementations

  • NA

Backend Table Changes

For the implementation of admin frontend some new, additional fields are needed.

Details

Table Program

  • Field Name: max_length=40
  • New text field "ShortName"; max_length=6
  • New integer field "MaxMissedSessions"; default=2
  • 3 new text fields: "QuestionnaireStart", "QuestionnaireSpeaker", "QuestionnaireEnd" (for the links to the corresponding questionnaires)
  • For the upload of the certificate templates in total 4 new fields are needed, 2 for the original names of the files and 2 for the link where they are stored on the server: "FileNameTemplateParticipationCertificate", "FileNameTemplatePerformanceCertificate", "FileLinkTemplateParticipationCertificate", "FileLinkTemplatePerformanceCertificate"
  • 2 new boolean fields to set the visibility of the certificates: "VisiblityParticipationCertificate", "VisibilityPerformanceCertificate"; default for both is FALSE.

Table User

  • New text Field "UniversityOther" (for entering the name of a university not listed in the table University)

Table Course

  • New boolean field "Visibility"; default=FALSE
  • Change filed Status according to the description given below for the ENUM table
  • BookingDeadline --> ApplicationEnd
  • "DayOfTheWeek" --> "WeekDay"
  • "TimeOfStart" --> "TimeStart"
  • "Duration" --> "TimeEnd"
  • Multiple Locations --> new join table
  • MaxMissedDates --> MaxMissedSessions

Instructor

  • Person --> User

Table Location

  • A new table with possible values for the dropdown to select a location
  • For the seed data, it should be "ONLINE" and "KIEL"
  • LocationName --> Name verlinkt mit ENUM Table

ENUM Table CourseStatus:
The fields of the table should be the following:

  • DRAFT
  • READY_FOR_PUBLICATION
  • READY_FOR_APPLICATION
  • APPLICANTS_INVITED
  • PARTICIPANTS_RATED
    For migration all past courses withe status "FINISHED" should be set to "PARTICIPANTS_RATED, all courses marked as "ACTIVE" to "APPLICANTS_INVITED" and all other courses to "DRAFT"

ENUM Table LocationOptions:
The table includes only one value by default (which must not be deleted)

  • ONLINE
    For migration additionally "KIEL" is to be included

CourseDefaultValues

  • "Semester" can be removed
  • New text field Language; for migration set to "de"
  • Default for MaxParticipants is an empty field (equals no restriction on number of participants) (positiver Integer oder leer)
  • "Location": for migration set to "KIEL"

Table Session

  • the field "Date" is missing
  • Start --> TimeStart
  • Finish --> TimeEnd
  • Join Table für "Address" (not Location)
  • "SessionReferents" --> "Speaker"
  • Title --> Name (its named "Name in all other cases as well, should be her accordingly)

ENUM Table MotivationGrade

  • Rename table to "MotivationRating"
  • BAD --> DECLINE
  • AVERAGE --> REVIEW
  • GOOD --> INVITE

Table Enrollment

  • MotivationGrade --> MotivationRating
  • CertificateURL --> FileLinkPerformanceCertificate
  • CertificateOfParticipationURL --> FileLinkParticipationCertificate
  • New field "Performance - Rating"
  • UploadFile --> FileLinkPerformanceRecord

new ENUM Table PerformanceRating

  • "UNRATED"
  • "PASSED"
  • "FAILED"

Table Attendence

  • Table name should be "Attendance" (and in the same way table "AttendanceDocument")
  • Attending --> Status
  • New field "Source" (ENUM Table AttendanceSource "ZOOM", "INSTRUCTOR"

new ENUM Table AttendanceStatus

  • "NO_INFO"
  • "ATTENDED"
  • "MISSED"

Optional and Future Implementations

  • NA

Serverless Function to Generate Certificates

The function gets a course ID as input When the function is called certificates are generated for all participants of the course that meet the requirements (see Details below).
After the generation of the certificates, it is checked whether all participants have fully rated attendances and performance records. If so, [Course:Status] is set to "PARTICIPANTSRATED".

Details

  • An attendance certificate is generated for a participant if the following criteria are met:
    • for all sessions the participant has an [Attendance:Status] unequal to "NO_INFO"
    • the number of sessions with [Attendance:Status=="MISSED"] is not larger than [Course:MaxMissedSessions]
  • A performance certificate is generated for a participant if the following criteria are met:
    • for all sessions the participant has an [Attendance:Status] unequal to "NO_INFO"
    • the number of sessions with [Attendance:Status=="MISSED"] is not larger than [Course:MaxMissedSessions]
    • the performance record [Enrollment:PerformanceRating] was rated as "PASSED"

Optional and Future Implementations

  • NA

Course Administration - Description (Part 1)

This issue is part of a series of four issues in total, where each issue is describing a view with a common top and bottom section.

The top section includes the title of the course and additionally four tabs, which serve to access the different pages allowing to enter the needed course specific information as well to manage the participation. The colors of the tabs change according to the completion status of each section, whereby a section can only be completed when the section before has been completed.
The bottom section consist of a button to move to the next section. However, only when all mandatory fields are completed the page with the next tab is displayed, otherwise an error message is shown.

Details

  • The URL of the site is: [domain]/course/?course_id=xyz&tab=description (however, you can also choose a different format)
  • The site is accessed by double clicking on the row of the corresponding course in the course overview table (see issue #41), or by clicking on the corresponding tab in the top section in one of the related views.
  • The design should be as follows:

Top section

  • The tab that is currently selected is always marked with a black background.
  • If Course:Status equals "DRAFT", only the first tab can be selected; if it is "READY_FOR_PUBLICATION", only the first and second; if it is "READY_FOR_APPLICATION", only the first 3; and if it is "APPLICANTS_INVITED" or "PARTICIPANTS_RATED", all tabs can be selected.
  • Depending on the course status field the colors of the not selected tabs are given a light grey or green background. If Course:Status=="READYFORAPPLICATION", the first two tabs are with green background (except for the currently selected one); if Course:Status=="APPLICANTSINVITED", the first three tabs are with green background (except for the currently selected one); and so on.

Middle Section

  • The upper part includes 6 text input fields [Course:Description (max.length=200), Course:Learning:Goals (max.length=500), Course:TitleTextField1 (max.length=50), Course:TitleTextField2 (max.length=50), Course:ContentTextField1 (max.length=1500), Course:ContentTextField2 (max.length=1500)]; all input fields can be edited directly and are saved as soon the text fields are left. If this is complicated a modal can be used instead.
  • 3 input fields to select a weekly time for the course; the weekday can be implemented via a dropdown and the two times via text/date inputs, which are checked for the correct format. The fields are as well saved automatically after editing. Other solutions are welcome here as well (modal or time picker). [Course:WeekDay; Course:TimeStart; Course:TimeEnd]
  • a dropdown menu to select the language of the course [Course:Language]
  • Integer input fields for the number of maximum participants [Course:MaxParticipants; must be a positive integer]
  • The bottom part includes a table to define the locations of the course. New locations can be selected by the named add sign below the table on the right (the default values when a new location is added are given below). The table columns are the following:
    • location: directly editable via a dropdown menu including the values from the table LocationOptions (default for a new loaction is given in CourseDefaultValues:Location)
    • address:
      • if location is unequal to "ONLINE", it includes a an address given via GPS-coordinates [Location:Latitude; Location:Longitude]. The address/coordinates are provided via a location picker (if the selected location picker need a different format to store the location, the latitude/longitude fields in the Location table can be changed accordingly).
      • if location is equal to "ONLINE", it includes an editable text field with the link to the corresponding online call. The field is directly editable and saved on editing (if it is complicated it can be edited via a modal).
    • trash bin: by clicking on it the corresponding location is deleted

Bottom Section

  • A "Next" button to proceed to the next tab (see issue #51). However, a change to the next tab is only possible if Course:Status is unequal to "DRAFT". If the status does not have a corresponding value, it is checked whether the current state of fields allows for a status change. If the conditions are met the Course:Status field is changed to "READYFORPUBLICATION" and the next tab is opened. If the conditions are not met, an error message is displayed stating: "Please, complete all mandatory fields to proceed!".
  • The conditions to change the status are:
    • The text input fields Course:Description, Course:LearningGoals, Course:TitleTextField1, and Course:ContentTextField1 are not empty.
    • At least one location for the course is defined
    • If a location with Location:Name=="ONLINE" is part of the locations, the field Location:Link must be not empty.

Optional and Future Implementations

  • Showing the number of currently used characters and the total number of characters available on top of the 6 text input fields

Course Administration - Session Dates (Part 2)

This issue is part of a series of four issues in total, where each issue is describing a view with a common top and bottom section.

Details

  • The URL of the site is: [domain]/course/?course_id=xyz&tab=sessions (however, you can also choose a different format)
  • The site is accessed by double clicking on the row of the corresponding row in the course overview table (see issue #41), by clicking on the corresponding tab in the top section in one of the related views, or by clicking on the "Next" button in the previous tab.
  • The design should be as follows:

Top section

  • See issue #50

Middle Section

  • This section includes a table with the information on the individual sessions for each course, where a new session can be added via a named plus button above and below the table. The new session is added at the top of the table and initially all fields of the new session are empty. The table is always sorted according to the date starting with earliest date on top. If no date is provided, the session is sorted at the top and according to the creation date, where the one added most recently is the one on top.
  • The columns of the table are:
    • date: the date can be entered/changed by clicking on it, only dates between Programm:Start and Programm:End are allowed (including the days of Programm:Start and Programm:End themselves) [Session:Date]
    • start time of the session [Session:TimeStart]; the time can be edited via an appropriate time picker
    • end time of the session [Session:EndStart]; the time can be edited via an appropriate time picker
    • Title of the session [Session:Name]; the title can be directly edited or, if this is complicated via a modal; if the title is longer than the column the full text is shown on mouse over in form of a tool tip.
    • Addresses and online links [Address]; new addresses can be entered via the add button on the right, which opens a location picker equal to the one in issue #50 ; an address can be deleted by clicking on the cross at the end of the tag of an address field; if the address/link is longer than the column the full text is shown on mouse over in form of a tool tip.
    • Speaker [Speaker]; new speakers can be entered via the add button on the right, which opens a modal with equal to the one for selecting a course instructor (cf. issue #41) ; a speaker can be deleted by clicking on the cross at the end of the tag for a speaker; if the name is longer than the column the full text is shown on mouse over in form of a tool tip.
    • trash bin to delete a session

Bottom Section

  • A "Next" button to proceed to the next tab (see issue #52 ). However, a change to the next tab is only possible if Course:Status is unequal to "DRAFT" and "READYFORPUBLICATION". If the status does not have a corresponding value, it is checked whether the current state of fields allows for a status change. If the conditions are met the Course:Status field is changed to "READYFORAPPLICATION" and the next tab is opened. If the conditions are not met, an error message is displayed stating: "All session titles must be unique and all relevant fields must be completed before you can proceed!".
  • The conditions to change the status are:
    • at least one session is added.
    • for all sessions a date, start time and end time is defined.
    • for all sessions the title [Session:Name] of the session is not empty and not equal to Course:Name
    • all session titles are unique
    • for all sessions at least one address or link is provided

Optional and Future Implementations

  • If no session at all is defined for the given course, a set of standard sessions is generated before the page is shown. The data for these sessions are as follows:
    • Based on the dates Program:Start and Program:End sessions for all days of the week that correspond to Course:WeekDay are generated and the dates are set correspondingly.
    • Session:TimeStart and Session:TimeEnd are set equal to Course:TimeStart and Session:TimeStart for each session.
    • The field Session:Title is set to Course:Name.
    • For each session links and addresses are set equal to those given for the course (if no address is given, it is not added to the session addresses)

Addons for the User Profile View

This view is for the user to change his own profile information as well as for the admin to change the profile information for a selected user.
This issue is part of the participant functionality as well as part of the back-office, This part is therefore mobile first.

For the MVP only the top part to show/change the profile information is relevant. The bottom part including information on past participation etc. is optional or for future implementations.

Details

  • The URL of the site is: [domain]/profile/id=xyz
  • A special URL for this site is [domain]/profile/id=new. This site displays all entry fields with empty values and creates a new user when the
  • The site is accessible via an additional menu item "Profile" in the standard header menu or for an admin via the site displaying the currently existing users by clicking on a the corresponding user row (cf. mockup here)
  • The design should be as follows:
  • A top section including the profile photo and the first name of the currently displayed profile
    • if the users clicks on the photo a dialogue is opened to upload a new profile photo
    • if the below mentioned text input field on the first name is updated, the first name is updated here automatically (optional, see comment below)
  • An upper middle section of text fields showing basic profile information that is stored and changed via the Keycloak profile dialogue and a button to access the Keycloak dialogue:
    • first name (User:Firstname)
    • last name (User:Lastname)
    • mail address (User:Email)
  • A lower middle section including additional profile information that is only used within the EduHub application. The fields show the currently given information of a user and includes the option to change it. All changes are automatically saved when leaving the input field. The input fields are the following:
  • dropdown menu including the employment status (User:Employment; values are taken from table Employment) [mandatory]
  • dropdown menu including the name of the university (User:University; values taken from table University) [hidden if the employment status is unequal to student or scientific staff else mandatory]
  • text input field for the name "Other Universtiy" when this one was selected in the dropdown menu on university (User:UniversityOther) [hidden if User:University is unequal "OTHER"]
  • student registration number (USER:UNIRegistrationNumber) [hidden if User:University is unequal "CAUKIEL" else mandatory]
  • a checkbox indicating if the user is provided with admin rights, resulting in a new entry for the user or a deletion of the user in the table Admin.
  • A button below the section to enter the profile information to save changes (or create a new user with the given information; iff all mandatory information has been provided)

Optional and Future Implementations

  • Displaying the first name on the right side of the profile photo is optional if the automatic update is complicated.
  • A check box to activate or deactivate the registration to a newsletter.
  • The bottom section including past activities of the user.
  • Course instructors can view a user profile if the user has participated or is participating (Enrollment:Status equals "CONFIRMED", "ABORTED", or "COMPLETED") in one of the instructor's courses. However, all fields are read only for course instructors.

Bowsing Existing Projects

In order to browse all currently open achievement options and all successfully completed achievement records that are of type DOCUMENTATION_AND_CSV or DOCUMENTATION (these types corresponds to the achievement options that are projects).
If an achievement option is selected by several courses as possible achievement, a separate tile is displayed for each course it is selected for.!
The tile view for the projects should as much as possible use the same components as the tile view for the courses. Such that design changes are seamless across the courses and projects view.

Details

  • To access the site a new menu item Projects is added to the menu of all users. It is added directly below the menu item Courses
  • The URL of the site is: [domain]/projects/?tag=[ENUM of the selected tag]&open=[0 or 1]&completed=[0 or 1]
    • The URL tag open corresponds to whether all open projects listed in the AchievementOption table are are displayed (1) or not displayed (0). Displayed projects must comply with the following conditions:
      • AchievementOption.type==DOCUMENTATION_AND_CSV or AchievementOption.type==DOCUMENTATION
      • AchievementOption.Course.endDate<=[date_of_today]
    • The URL tag completed corresponds to whether completed achievements are displayed (1) or not displayed (0). Displayed projects must comply with the following conditions:
      • AchievementOption.Course.endDate>[date_of_today] and it exists at least one achievement record for this option. Eeven if several records exist only one tile is displayed (the corresponding project view will instead include a table with the scores from each achievement record).
        or
      • AchievementRecord.AchievementOption.type==DOCUMENTATION and AchievementRecord.rating==PASSED
    • If the URL tag tag is provided, it corresponds to an element of CourseThemeTag that is used to filter the displayed projects. Displayed projects must additionally to the above conditions comply with the following:
      • AchievementRecord.AchievementOption.Course.themeTag==[element from ENUM CourseThemeTag]
        or
      • AchievementRecord.Course.themeTag==[element from ENUM CourseThemeTag]
  • The design of the site is mobile first and given here.
  • The design for desktop should correspond to the design used for the tile views of the courses
  • The following elements are included equally in project tiles:
    • Project cover image
      • The cover images are stored in the folder public, that is the function loadFile is not needed but the images can be download directly
      • For type DOCUMENTATION the link given in AchievementRecord.coverImageUrl is used
      • For all other type the link given inAchievementOption.Course.coverImageUrlis used
    • Project title (AchivementOption.title)
    • Course title (AchivementOption.Course.title)
    • Program short title (AchivementOption.Course.Program.title)
      The element including the names of persons (displayed below project title) depends on whether the displayed item refers to an achievement option or an achievement record:
    • For achievement records of type DOCUMENTATION the authors of the project are displayed (AchievementRecord.AchievementRecordAuthors)
    • In al other cases the mentors of the projects are displayed (AchievementOption.AchievementOptionMentors)

Optional and Future Implementations

  • NA

Start Page (logged out)

A new (unregistered) user wants to get a quick overview of all offered courses in order to see if they are roughly according to his/her interests and needs.

Details

The design should be as follows:

The page includes the following sections:

  • The standard header (logged out) and footer
  • A large header section with a title image
  • Info tiles for all courses; the tile include:
    • A top part with a selected image from a video is displayed. The video will be a future task see Additional Information
    • The title of the course
    • A text at the bottom indicating the tile type (here always “course”)

Optional and Future Implementations

  • The mockups already contain a filtering by category. As we are working on an MVP at first, we skip this feature for now, but will add it later down the road.
  • The courses are in a horizontal slider. For a first version it is enough to allow the user to scroll through the list. So no more complex paging is necessary here, but can be used instead of a plain scroll view, if implementation is very simple.
  • In a future task it should be added that hovering over the course tile cover starts a video (muted).

Course Description (logged in and completed)

A user successfully finished a course and wants to download his certificate. Therefore, comparable to the participating status, the site includes an additional tab. However, the content of the tab is changed to only include the certificate, the attendances and a confirmation on tasks that were completed successfully.

Details

  • The definition of the URL corresponds to that in the participating status.
  • The design is as follows:
  • The status message displayed on Tab 0 is indicating that the course was successfully completed, the remaining part is as in the participating status.
  • Tab 1 now includes:
    • A title section as in the participating status
    • A status message with the same text as in Tab 0, which is displayed below the title section.
    • A section with a tile for the certificate download is displayed. By clicking on it a the certificate download is initiated, the link to the certificate file is given in the enrollment table.
    • A section including the attendances just as in the participating status
    • A section on the Tasks, with texts showing the name of the selected project and/or online course and that it was completed successfully.

Optional and Future Implementations

  • NA

Extension of Project Results Upload

The logged-in course page is changed in such way that the section for upload achievement records is adapted depending on the chosen achievement option. This is mainly achieved by adding a model that is opened when clicking the button to upload the achievement record ("Nachweis hochladen).

Details

If the field Course.achievementCertificatePossible is TRUE the site includes the section "Achievement Record" ("Leistungsnachweis"), otherwise it is not shown. The section includes:

  • A dropdown menu to select a specific achievement record, which the course instructor made available for this course [AchievementOptionCourse]
  • A button to upload an achievement record, which is only active when an achievement option is selected in the dropdown menu. Clicking the button opens a modal for an additional upload dialogue.
  • A text message providing information about already uploaded achievement records:
    • if the current user is author of an achievement record for the selected achievement option [AchievementRecord.AchievementRecordAuthors], the text displays the date and time of the record that was last created (achievement records are never updated but new uploads always result in new entries) and the user that uploaded the last record
    • if the current user is not author of any uploaded record for the selected option, the following text is displayed: "Bis jetzt wurde noch kein Nachweis mit Dir als Autor hochgeladen."
    • if no achievement option is selected in the drop down menu, no info text is displayed.

The content of the modal opened on clicking the upload button depends on the type of the record for the selected achievement option [AchievementOption.recordType]:

  • Design
  • The section on the csv result file upload [AchievementRecord.csvResults] is only shown if AchievementOption.recordType is DOCUMENTATION_AND_CSV
  • The cover image that is to be uploaded for the case of type "DOCUMENTATION" is stored using the serverless function saveAchievementRecordImage
  • The documentation that is to be uploaded is stored using the serverless function saveAchievementDocumentation
  • The file with csv results that is uploaded for the case of type "DOCUMENTATION_AND_CSV" is stored as a base64-encoded string in AchievementRecord.csvResults
  • If AchievementOption.recordType is DOCUMENTATION_AND_CSV, the column AchievementRecord.evaluationScriptUrl is set to the value of the corresponding AchievementOption.evaluationScriptUrl. The evaluation script will then automatically be triggered on the insert of the new achievement record and will save the results in the column AchievementRecord.score.
  • If all fields are correctly completed, the ID of the current user is stored in the field AchievementRecord.uploadUserId before the modal is closed and the page the modal was opened in is updated (to update the information on the last documentation that was uploaded).

Optional and Future Implementations

  • NA

Logging

Die Leitungen des Bildungsprogramms und der Plattformentwicklung möchten wissen, welche Elemente der Anwendung wie genutzt werden, um Informationen darüber zu erhalten, wie die Plattform weiter optimiert werden kann, um die Nutzer bestmöglich zu unterstützen.

Details

  • Alle Aktivtäten von Teilnehmenden (und auch Kursleitungen und Admins, die in den späteren Issues folgen) werden in einem Event-Log gespeichert.

Optional and Future Implementations

  • NA

Header (logged out)

This is the standard header that is the same on all pages. Depending on the whether the user is logged in or not lot log-in (and register) button or the profile avatar is shown. Since there is no login when working on this ticket, the implementation of the avatar is postponed to a later ticket.

Details

Optional and Future Implementations

  • Implementation of the logged in version including an avatar with drop-down menu on the right
  • The background of the header should be transparent and switch to white as soon as the user scrolls down.
  • The background and color of the header should be changeable between light (black on white) and dark mode (white on black).
  • The dropdown menu in the logged in version includes access to applications (e.g. a chat tool like Mattermost) that are integrated via iFrame. The iFrame is then displayed in the full width of the screen with just the sticky header on top.
  • Inclusion of a search field in the desktop view.

Up- and Download of Files in a Storage Bucket

Implementation of a serverless function to allow up- and download of a file.
The files are saved in a Google storage bucket and a Hasura update, insert, or select will be done with a header that allows to check who calls the function and if she(he has sufficient privileges.

Details

The files will be up- and downloaded according to the following structure and the reading and writing access is according to descriptions provided below:

Fallback Images
public/fallback_images/course_cover_image.png
read: public
write: admins only

** Logo images **
public/logos/<logo_name>
read: public
write: admins only

User Profile Images
public/<User.id>/profile_image/<upload_file_name>
read: public
write: user with the corresponding User.id and admins

Cover Images for Courses
public/<Course.id>/cover_image/<upload_file_name>
read: public
write: instructors for the corresponding course und admins

Cover Images for Achievement Records
public/<AchievementRecord.id>/cover_image/<upload_file_name>
read: public
write: user that are authors of the achievement record and admins

Achievement Certificates
<User.id>/<Course.id>/achievement_certificate_<Course.title>.pdf
read: user with the corresponding anonymousId, instructors for the course withe the corresponding Course.Id, and admins
write: only admins

Participation Certificates
/<Course.id>/participation_certificate_<Course.title>.pdf
read: user with the corresponding anonymousId, instructors for the course withe the corresponding Course.Id, and admins
write: only admins

Templates Achievement Certificate
<program_id>/achievement_certificate_template/<uploaded_filename>
read/write: only admins

Templates Participation Certificates
<Program.id>/participation_certificate_template/<uploaded_filename>
read/write: only admins

Optional and Future Implementations

  • NA

Automated Mailing of Feedback Questionnaires

In each program the admins can define a start questionnaire, administered after the first session of a course, an end questionnaire administered after the last session of a course, and a speaker questionnaire that is administered after all sessions that have at least one speaker defined (if a speaker is defined for the last and the first session, two questionnaires are mailed).

Details

  • A cron job runs once an hour and checks if the current time is after the end time of a session, which is the first session in a course, the last session in a course, or a session with a speaker. If the mail log table does not include the feedback mails for these session yet, new entries in the mail log table are generated for all course participants [Enrollment:Status=="CONFIRMED"] using the respective templates for sending out the feedback questionnaires and including the corresponding links given in [Program:QuestionnaireStart], [Program:Questionnaire:Speaker], and [Program:QuestionnaireEnd].
  • If no questionnaire link is provided in [Program:QuestionnaireStart], [Program:Questionnaire:Speaker], or [Program:QuestionnaireEnd] the respective feedback mails is not sent.
  • The links of the questionnaires are extended by information to identify the course and the session

Optional and Future Implementations

  • NA

Review: Project Administration

The administration projects (in the following achievement options to allow for other types beyond projects) consists of two parts:

  • the definition of an achievement option (for example a project or the completion of a set of online courses)
  • the selection of an achievement option to make it available for the participants in course, so the participants can select it in their course view as achievement and upload the needed documentation and possibly also a csv including results to fulfill the requirements of an achievement certificate.
    In order to allow for the definition of an achievement option and the attribution to a course, a new site is added, and further a new section is added to the existing tab 4 of the course admin site to show the currently available achievement options for a course.

Details

  • Selection of an achievement option for a course:
    If the field Course.achievementCertificatePossible is TRUE the tab 4 of the course admin site includes an additional section above the participant table showing the currently selected achievement options that are possible. A new achievement option can be added to the course by clicking on the plus sign located in that section. Clicking on it opens the page to define new or update current achievement options. Another way to open that same site and to add an achievement option to a course is to select the entry "Achievement Administration", which is added as a new item to the menu for instructors and admins.

  • The URL of the new site is: [domain]/achievements/

  • For admins and instructors the menu of the standard header is extended by the item "Achievement Administration" ("Administration Leistungsnachweise")

  • The design for the site is the following:

    • Desktop: here
    • Mobile: no particular design provided, should only be functional
  • The given list of projects can be filtered according to the programs the projects are part of (via the courses they are connected to) and can be sorted according the courses.

  • Admins see all existing projects. Instructors only see projects that are connected to the courses they are instructing.

  • Defaults for adding an achievement option:

    • Title [AchievementOption.title]: "New Title" (Cursor is positioned here after adding the new achievement option; the maximum length for a titel is 200 characters)
    • Mentors [AchievementOption.AchievementOptionMentors]: The current user is automatically added as a mentor to the newly added achievement option
    • Courses [AchievementOption.Course]: Empty. If the site was opened via the add sign of tab 4 of a course admin page, the corresponding
    • Description [AchievementOption.description]: initially empty, the maximum length for the description is 3000 characters
    • Type of achievement record [AchievementOption.type]: "DOCUMENTATION" (dropdown from ENUM table AchievementRecordType)
    • Documentation template [AchievementOption.documentationTemplateUrl]: initially it is empty, documentation templates are uploaded under <AchievementOption.id>/documentation_template/<uploaded_file_name> and after upload the file name is displayed in the white field.
    • If the type of achievement option is "DOCUMENTATION_AND_CSV" an additional upload field is shown (otherwise it is hidden) [AchievementOption.evaluationScriptUrl]: initially it is empty, evaluation scripts are uploaded under <AchievementOption.id>/evaluation_script/<uploaded_file_name> and after upload the file name is displayed in the white field.

Optional and Future Implementations

  • If the site is opened via the add sign of tab 4 of a course admin page, the site is opened with a newly added achievement option using the defaults described above, and additionally the corresponding course is automatically added to it under related courses [AchievementOptionCourse.courseId].

Hasura Role Management

To prevent misusagee of the frontend API, a user must only have access to the data he is allowed to see.
Currently we have a role for a not logged-in user and role for a logged-in user.
Additionally, the role admin is needed with general access to the data, and the role course instructor. In the future the role speaker might be needed additionally (however, there is no need at the moment).

Details

  • The role admin has reading and writing access to all tables.
  • The role instructor has the same rights as the role user logged-in, and for the course he is instructing, he has the same rights as a user participating in this course; further, he has writing access to the input fields mentioned in the issues #50 , #51 , #52 , and #53 (just for the courses he is an instructor for)

Optional and Future Implementations

  • NA

Multilanguage Support

A user (or admin) wants to take part in one of the courses offer in English language, and therefore wants to navigate in English language through the platform.

Details

  • All sites should support multiple languages (at the start only English and German).
  • The description of the courses itself will be in one language only. However, titles, explanatory text fields, menu items, etc. are translated.

Optional and Future Implementations

  • An element in the standard header bar that is used to switch between the different languages.
  • It should be possible to extend the number of languages beyond English and German.

Course Description for Invited (and not Confirmed) Participant

A user is logged in and viewing the description of a course he or she was invited for.

The view is based on the one for a logged-in user with the option to apply for a course. However, the section of the apply button is replace with a section including three text fields and a button to confirm the participation.
When the deadline to confirm the course participation is expired, the confirmation button is deactivated and the text below the button is changed to "Die Frist zur Bestätigung der Kursteilnahme ist abgelaufen."
By clicking the button the user's course enrollment status is changed to CONFIRMED and the site is refreshed to show the course description for a participating user.
The text below the button includes the information from the user's CourseEnrollment.invitationExpirationDate

Details

  • the design is mobile first
  • the mobile design is given here
  • the desktop design is given here
  • the text below the button includes the information
  • If the current date is after the user's CourseEnrollment.invitationExpirationDate, the confirmation button is deactivated (color set to grey, no hover effect) and the text field below the button is set as given above.

Optional and Future Implementations

  • NA

Course Administration - Grading (Part 4)

This issue is part of a series of four issues in total, where each issue is describing a view with a common top and bottom section.

Details

  • The URL of the site is: [domain]/course/?course_id=xyz&tab=grading(however, you can also choose a different format)
  • The site is accessed by double clicking on the corresponding row in the course overview table (see issue #41), by clicking on the corresponding tab in the top section in one of the related views, or by clicking on the "Next" button in the previous tab.
  • The design should be as follows:

Top section

  • See issue #50

Middle Section

  • This section includes a table with the information on the participants attendances and their performance records. Further, the user can change the participants' attendances and download and rate their performance records.
  • The table includes the following four columns:
    • First name [Enrollment:UserId--User:Firstname]
    • Last name [Enrollment:UserId--User:Lastname]
    • Attendances [Enrollment:Course--Course:Session--Session:Attending]
      • For each existing session in the course a circle is shown, depending on the participant's attendance for each session the circle is green [Attendance:Status=="ATTENDED"], red [Attendance:Status=="MISSED"], or grey [Attendance:Status=="UNRATED"]
      • By clicking on a circle the user can change the attendance status of the course, from grey to green, from green to red, and from red to grey.
      • After the circles for the individual sessions, a user's attendance is summarized by providing the number of all currently attended sessions, after the summary another circle is shown, which is red if the number of missed session is larger then the number of allowed missing sessions [Course:MaxMissedSessions] and green otherwise.
    • Performance record [Enrollment:PerformanceRating]
      • If the participant uploaded a performance record, a download icon is shown, and by clicking on the icon, the participant's performance record is downloaded [Enrollment:FileLinkPerformanceRecord]
      • For [Enrollment:PerformanceRating=="PASSED"] the shown status circle is green, for [Enrollment:PerformanceRating=="FAILED"] red, and for [Enrollment:PerformanceRating=="UNRATED"] grey
  • Additional to the main fields each row of an application can be unfolded by clicking on the downward pointing arrow on the right. As soon as the application is unfolded the arrow points upwards. Collapsing the application is done by clicking on the arrow, which the again points downwards. It is possible to unfold as many participants as are shown. In the unfolded status a radio button with three colored options is shown. The user can edit here the rating for the performance record. As soon as the rating is changed, the status is also changed correspondingly above in the table row.

Bottom Section

  • Instead of the "Next" button this tab includes a button to generate certificates for the participants. However, this button is only visible to admins. For course instructors it is invisible (unless they are also admins). When the button is clicked a certificate is generated for all participants that meet the requirements by calling the corresponding serverless function, which checks the requirements and generated the certificates for the participants. (If [Program:VisiblityParticipationCertificate] or [Program:VisibilityPerformanceCertificate] are TRUE, the corresponding certificates are then also available to download for the participants.)

Optional and Future Implementations

  • One or several applicants (i.e. rows) can be selected by clicking on it (for multiple rows using the combinations with the alt and ctrl keys) and by using the right mouse button a context menu can be opened. The context menu includes an item "Send Mail" to open the local mail client with the email addresses of all selected participants added in the BCC field.
  • On mouse over of a circle showing the attendance status of a single session, the date of this session is shown in a tool tip.
  • In the future information to review the results of the feedback questionnaires will be included below the bottom section.

Footer

This the standard footer, which is the same on all pages. Except spacing the footer is the same for desktop and mobile and generally static.

Details

It is divided into 3 parts:

  • The top part, with an image that should be shown at the top:
    grafik
  • The center part, containing the links to three static pages:
    grafik
  • The bottom part, with the copyright on the left and two circular dots on the right, which should become share icons in the future:
    grafik

Optional and Future Implementations

  • In the future the footer might become dynamic markdown content, but for now it will be static. However, the URLs should be easily editable for non-developers, so keep them in a global config/constants file and document how to change them.

Renaming and Cleaning Database Fields

After finishing the MVP including the views for the admins and course instructors, it was decided to conduct thorough clenaing and renaming of the database according to the following points:

  • It is beneficial to rename certain variables to be in accordance with how they are named in the corresponding frontends.
  • All column names should start with lowercase letters to allow for an easier automatic recognition of the fields in the GraphQL environment.
  • Several tables and columns that were migrated mainly due to legacy reasons are removed.
  • Further, several columns are renamed to follow a common pattern.

Important note on projects and online courses
Additionally, the information on projects and online courses that can be selected for completion to obtain an achievement certificate are changed in that way that the completion of "online courses" is now a special type of project. This way it is easier in the future to integrate further, other types without changing the structure of the database. The name project is kept for the table because this is the primary focus.

Important note on instructors and speakers
Additionally, the tables on instructors and speakers are joined into a common table Expert. The tables SessionSpeaker and the CourseInstructor are now corresponding join tables with the table Expert.

The below given details correspond to an update of the database according to the following convention.

General Naming and Documentation Convention for Database Tables and Columns

Tables

  • names: camel case starting with an upper case letter
  • comment: Indicates for which events a new entry in the table is generated

Columns

  • names: camel case starting with a lower case letter
  • comment: Indicates in which events the entry is (usually) changed; The description does not have to be complete but should rather provide an example to make the usage clear.
  • If the type of a column is included in its name it should typically be added at the end. Further, if types already exist thes abbreviations/ names of these must be re-used and should not be changed. Here, examples of currently existing types:
    • URL: All links to files stored in a cloud bucket should be stored in columns ending with the name "URL"
    • Link: All URLs to external resources (not to the internal cloud bucket storage)
    • DateTime: All date-time variables
    • Time: All variables including only time
  • title vs. name: In many occasions either the column name title or name might be fitting; in general, the name title should be preferred.

Enum Tables

  • names: A concatenation of table and column name of the column for which the enum values are primarily defined.
  • comment: If the enum is used in more than one column the further columns should be named here

Enum Values

  • names: All letters are upper case and if the name includes different words these are separated by underscores
  • comment: A short description for the meaning of the value

Details

  • All columns were renamed to start with lowercase letters.
  • All created_at ans updated_at columns were rename to correspond to the camel case naming convention.

The following tables are removed:

  • CourseDefaultValues
  • OnlineHybridOffline
  • ProjectType
  • Referent
  • CourseButtons
  • CourseAddress
  • Speaker
  • Referent
  • SurveyType (enum)
  • Event

The following table columns are removed:

  • Course.MaxParticipants
  • Course.Description
  • Course.City
  • Course.TextOnCertificate
  • Course.DatesOnCertificate
  • Course.MaxProjectParticipants
  • Course.ExternalProjectsAllowed
  • Course.Online_Hybrid_Offline
  • Course.Projects
  • Course.ProjectsAllowed
  • Course.OnlineCoursesAllowed
  • Course.Difficulty
  • Course.CourseType
  • Course.LinkVideoCall
  • Course.OnlineCourses
  • Enrollment.WantsEcts
  • Enrollment.WantsCertificate
  • Enrollment.ProjectTitle
  • Enrollment.OnlineCourseTitle
  • Enrollment.TypeOfProject
  • Enrollment.Online
  • Enrollment.CertificateOfParticipation
  • Enrollment.CertificateConfirmed
  • Attendance.Source
  • Mail.SenderId
  • Program.FileLinkParticipationCertificate
  • Program.FileLinkPerformanceCertificate
  • Session.SurveyType
  • Session.SurveyId

The following tables were added:

  • CourseProject
  • SessionSpeaker
  • MailStatus (enum)

The following table columns are added:

  • MailTemplate.cc
  • MailTemplate.bcc
  • MailTemplate.from

The following tables are renamed:

  • AttendanceDocument --> AttendanceSourceData
  • Mail --> MailLog

The following table columns are renamed:

  • Attendance.NameRegistered --> Attendance.recordedName
  • Attendance.TypeRegistered --> Attendance.source
  • Attendance.TimeStart --> Attendance.startDateTime
  • Attendance.TimeEnd --> Attendance.endDateTime
  • AttendanceDocument.Content --> AttendanceSourceData.URL
  • AttendanceDocument.Type --> AttendanceSourceData.source (added relationship to enum AttendanceSource)
  • Course.Name --> Course.title
  • Course.TimeStart --> Course.startTime
  • Course.TimeEnd --> Course.endTime
  • Course.Image --> Course.coverImage
  • Course.TitleTextField1 --> Course.headingDescriptionField1
  • Course.TitleTextField2 --> Course.headingDescriptionField2
  • Course.LinkChat --> Course.chatLink
  • Enrollment.FileLinkPerformanceRecord --> projectRecordURL
  • Enrollment.FileLinkPerformanceCertificate --> Enrollment.achievementCertificateURL
  • Enrollment.FileLinkParticipationCertificate--> Enrollment.attendanceCertificateURL
  • Enrollment.ExpirationDate--> Enrollment.invitationExpirationDate
  • Program.ApplicationEnd --> Program.defaultApplicationEndDateTime
  • Program.Name --> Program.title
  • Program.performanceRecordDeadline --> Program.performanceRecordUploadDeadline
  • Program.Start --> Program.lectureStart
  • Program.End --> Program.lectureEnd
  • Program.QuestionnaireStart --> Program.startQuestionnaire
  • Program.QuestionnaireEnd --> Program.endQuestionnaire
  • Program.QuestionnaireSpeaker --> Program.speakerQuestionnaire
  • Program.VisibilityPerformanceCertificate --> Program.visibilityAchievementCertificate
  • Program.FileLinkCertificate --> Program.achievementCertificateTemplateURL
  • Session.name --> Session.title
  • Session.start--> Session.startDateTime
  • Session.end--> Session.endDateTime
  • Session.finish--> Session.endDateTime
  • User.Firstname --> User.firstName
  • User.Lastname --> User.lastName
  • User.image --> User.picture
  • User.LinkedInProfile --> User.externalProfile
    -User.AnonymId --> User.anonymousId

The following enum table fields are renamed:

  • EnrollmentStatus.REJECTED --> EnrollmentStatus.EXPIRED
  • University.UNIFLENSBURG --> University.UNI_FLENSBURG
  • University.FHKIEL--> University.FH_KIEL
  • University.CAUKIEL--> University.CAU_KIEL

The following enum table fields are added:

  • University.UNI_LUEBECK
  • University.UNI_FLENSBURG
  • University.TH_LUEBECK
  • University.FH_WESTKUESTE
  • University.FH_FLENSBURG

Optional and Future Implementations

  • NA

Re-Usable Function Component for Admin Tables

Details

We need a base table implementation with some custom functionalities for usage on multiple admin pages

  • The table should have the styling like can be seen in Figma (https://www.figma.com/file/TtucXsvBOfZE7NZKzTimrA/edu-Wireframe-–-WIP?node-id=4%3A499)
    • Should have grayish color
    • Rows can be highlighted with a little darker color
  • Columns can be sorted by different types of content (strings, dates, booleans, numbers, ?status?)
    • New entries with default values should be on top
  • Rows should be able to be expandable and then again collapsible
  • The table should offer an onRowChange handler
  • Simple pagination of static data

Optional and Future Implementations

  • The table should be able to also work with validation errors

Adding an Extra Certificate View

The user needs a quick access to their certificates. Also, for legacy reasons not all courses the users have participated in might be shown (the format of the descriptions might often not be adequate according to the current format). However, they will still need to have access to their certificates.

Details

  • The URL of the site is: [domain]/certificates
  • For all users an additional item "Certificates" is added to the menu in the standard header.
  • The design should be as follows:
  • Below the title and subtitle of the view follows a tile view similar to the one showing the offered courses. For all certificates a user received [non empty fields in Enrollment:FileLinkPerformanceCertificate and FileLinkParticipationCertificate] a tile is displayed with the following content:
    • Enrollment:CourseId--Course:Program--Program:ShortName
    • Enrollment:CourseId--Course:Name
    • the type of certificate; if it is a tile for a performance certificate the shown type should be "Certificate"; if it is for a Participation Certificate, it should show "Attendance"
  • By clicking on a tile the corresponding certificate is downloaded [either via Enrollment:FileLinkPerformanceCertificate or FileLinkParticipationCertificate]

Optional and Future Implementations

  • NA

Tasks for Course Description

Extends functionality of #15

  • A section on "Tasks" including:
    • A text indicating until when the task proof has to be uploaded (the date for the final upload is given in the Cours Default Values table)
    • A dropdown menu to select a project from a given list of projects and an upload button for a selected project: These two elements are only shown if the field "projects" in the course table is TRUE; the list of projects for the drop down is given as well in the course table; if no project is selected, the upload button is deactivated.
    • A dropdown menu to select an online course task from a given list of tasks and an upload button for a selected project: These two elements are only shown if the field "online courses allowed" in the course table is TRUE; the list of online courses for the drop down is given as well in the course table; if no online course is selected, the upload button is deactivated.

Course Description (after or before application period)

A user is reviewing the courses to check for which courses she/he might want to apply a soon as the application period starts or she/he reviews them after the application period to check what's currently given and what maybe might be interesting in the next semester.

Details

  • The design of the site is identical to the one for a user not being logged in (or logged in and not having applied to the course), however, the apply button is replaced by corresponding status messages:
    • If the current date is before the start of the application period, the following text is shown: "Bewerbungen sind ab dem [registration start] möglich!
    • If the current date is after the end of the application period, the following text is shown: "Bewerbungen sind erst wieder ab dem kommenden Semester möglich."

Optional and Future Implementations

  • NA

Course Description (logged in and participating)

When a user is logged in, he wants to see the status of the courses for which he/ she applied, and for the courses he is currently participating he wants to see additional information on links to learning resources, check if his/her attendances to course dates in the past are correctly registered, select a particular project and upload a proof of a task that was mandatory within the project.
The additional information for a course in which a user is participating in is shown in form of an additional tab in the course description.

Details

  • The URL of the site is: [domain]/course/id=[course _id]&tab=[tab_name], where [course_id] provides the info on which course is displayed and [tab_name] is defined as "0" or "1", where "0" displays the site with the tab including the course description selected, and "1" displays the the site with the additional tab selected. If tab "1" does not exist for this page it defaults to the site with only the course description and no tabs.
  • For the enrollment status "participating", the design is as follows (the section "Resources" is implemented in a later point in time):
  • A section with the name times, title, and subtitle of the course (corresponding to what is shown on Tab 0).
  • A section including buttons that link to the Chat and the Zoom Call for this course. The link for these buttons are given in the corresponding field of the course table.
  • A section on the attendances, displaying registered attendances in green, absences in a reddish color, and dates for which the attendances were not yet checked in grey, Further, below the title a text is displayed which indicates the number of allowed absences, which is taken fro the course table [Max Missing Times].

Optional and Future Implementations

  • For the status "completed" and "incomplete" the title of the additional tab will change and the content of it will also change in the section above (including the a tile to download the certificate) and below (including a status on the uploaded task proof instead of an option to upload a file) the registered attendances.
  • In a future version Tab 1 is extended by a section with links to learning resources.

Modal to Send Course Invitations

This modal is opened via the context menu of the table described in issue #52

Details

  • The design should be as follows: https://www.figma.com/file/TtucXsvBOfZE7NZKzTimrA/edu-Wireframe-%E2%80%93-WIP?node-id=2347%3A9153
  • If the invite button is clicked and no date was provided or a date in the past was provided (the date of today is ok) and error message is shown stating: "Please, select a valid date for the expiration of the invitation!"
  • If the invite button is clicked and the above validation is successful the following actions are executed:
    • a new mail log [Mail] entry is generated for each selected applicant with [Enrollment:Status] equal to "APPLIED", "INVITED", or "REJECTED"
    • for each mail log entry the field [Mail:User] is set to the respective user ID and the field [Mail:Template] is set to "INVITE"
    • for each mail log entry the text provided in [MailTemplate:Subject] and [MailTemplate:Content] of the template named "INVITE" is parsed for variables that have to be replaced with the corresponding values of the user [User:Firstname; User:Lastname] or the current enrollment [Enrollment:ExpirationDate; Enrollment:CourseId--Course:Name]
    • finally set the field [Mail:Status] to "READY_TO_SEND"
    • for all selected applicants for which new mail log entries were generated, the [Enrollment:ExpirationDate] is set to the date that was selected in the modal, and the [Enrollment:Status] is changed to "INVITED"

Optional and Future Implementations

  • NA

Send system mail on course application

Details

When a user applied for a course a system email should be sent.
This was originally part of #12.

A new entry in the mail log is generated with the following content: Current Date and Time, "0", "application"

Course Description (logged out)

An unregistered user wants to get detailed information on a course in order to decide whether to apply for the course or not.

Details

  • The URL of the site is: [domain]/course/id=[course _id], where [course_id] provides the info on which course is displayed.
  • The design should be as follows:
  • The standard header bar and footer are displayed.
  • A large header section with a video that is played automatically (in mute) when the site is opened and that can be un-muted.
  • A section with the course title, course subtitle and weekly time of the course (see corresponding fields in the course table for the texts)
  • A section including the button to apply for the course and below a text field including the deadline for the application (Deadline for registration field I the course table)
  • A section displaying the learning goals (“Das wirst Du lernen”)
  • A section displaying the course content, that is a list of all sessions associated with that course, including the date and time of each session and its title (see Session table). The session in the list shall be ordered according to their date starting with the earliest date.
  • A section including the following technical info on the course:
    • Weekly time (Day of the week, Time of Start, Duration)
    • Number of ECTS (ETCS)
  • A text field including information on the cost of the course (from the table Course Default Values)
  • A section with information on the course instructor or instructors (if there is more than one course instructor, the section is included as often) including the instructor’s name, a profile image, and a text field with a short description.
  • The standard footer is displayed.

Optional and Future Implementations:

  • The section including the technical info shall be extended by 2 additional items in the future.
  • The text including information on the cost shall later be replaced for a course individual text field included in the course table and the text I the Course Default Values table will be the fall back.

Registration, Log-in, and Log out

A new user wants to register for the platform to be able to apply for a course or an existing user wants login into the platform to be able to apply for a course.

Details

Optional and Future Implementations

  • In future versions the user might be on a page that is not accessible in logged out form. Than the view changes to the startpage.

Admin Course Overview

This view is needed for admin user to add new courses to a program, assign instructors to a course, publish courses to be visible in a published program, and review the current application and participation status.
For course instructors this view is read only and the shown table includes only those course, for which the user is assigned to as an instructor.
By double-clicking on a row in the course table the page to edit/admin the corresponding course is opened (see issue #50 )

Further optional functions include reviewing the current status of a course considering the completeness of the information needed for the publication, the application process, and the further conduct of the course.

This issue is part of the back-office functionality and is therefore desktop first.

Details

  • The URL of the site is: [domain]/courses
  • For admin users and users that are instructor of a course the menu of the standard header is extended by the item "Courses" to access this site
  • The design should be as follows:
  • The top section includes a filter with exactly 5 tabs, where the first 4 tabs are named with the short titles of the 4 programs with the most recent course start date and the 5th tab is always "all"; clicking the tabs results in filtering the complete set of courses according to the respective programs (or showing all). The standard tab is the one for the program with the most recent start date (always shown on the very left).
  • On top of the table on the right is a titled button to add a new course (the search field above is optional; see comment below). The button is added in the same way below the table at the end of the page. By clicking on the add button a new row with default values for a course will be added at the top of the table. The course will be added to the program that is currently selected in the program filter if the filter is selected to "all" it will be added to the program with the latest start date. If the program to which the course has to be added to has no valid start and end date, an error message is displayed stating: The program "selected program" needs a valid start and end date in order to add a course to it!" If the start and end date exist the new course is added to the corresponding program.
    For the fields shown in the table the default values for the new course are set as given below. Further the field Course:ApplicationEnd is set equal to the field Program:ApplicationEnd of the corresponding program, the field MaxParticipants is set as given in CourseDefaultValues:MaxApplicants, the field Course:Langauge is set as given in CourseDefaultValues:Language, and the field Course:ApplicationEnd is set as given in Program:ApplicationEnd.
  • The main section is a table. It includes up to 50 courses at once. If there are more than 50 courses the user can use a switch page button below the table to view the next page (see comment below). The table (in the same way as other described tables) included an arrow on the right to unfold a row. On the main row the includes the following seven columns :
    • a check box to switch the publication status of the course (a confirmation message is not shown in this case) [Course:Visibility; 0=not visible; 1=visible]
    • a course title (sortable) [Course:Name; default="Enter course title here" (if the course name already exists it is extended by an underscore, e.g. to "Enter course title here_")]
    • the names of the first provided course instructor [Course:Instructor]; if more than one course instructor is provided the tag including the course instructor name is followed by a number indicating the additional course instructors for this course. Further an add sign is included in this column (see details below).
    • the total number of current applicants/participants for a course (sortable) [all entries where Enrollment:CourseId corresponds to the respective CourseId]
    • the number applicants that are: invited/ confirmed/ unrated [Enrollment:Status=="INVITED"; Enrollment:Status=="CONFIRMED"; Enrollment:Status=="APPLIED"&&Enrollment:MotivationGrade=="UNRATED"]
    • the short title of the program the course is part of (sortable) [Course:Program]
    • the publication status (optional; see comment below)
    • a trash bin symbol with the option to delete the corresponding program; if the user clicks on the trash bin this confirmation message is shown
  • The expandable part of a row includes the following information:
    • names/tags of further course instructors (if given)
    • an image with the currently uploaded course image [course.imageURL] and an option to upload a new image.
    • a text entry field to provide a link for a course chat [course.chatLink]
    • a dropdown box to select the number of ECTS [Course:Ects] that can be obtained by receiving a certificate of achievement. If the the certificate of achievement is not marked as possible for this course, the ECTS field is invisible.
    • two check boxes to indicate whether the corresponding types of certificates will be issued for this course [course.CertificatePossible; course.AttendanceCertificatePossible]
  • The following columns are editable in the table:
    • the course title: Can be edited directly in the table or if this is complicated via a corresponding modal.
    • the course instructor: By clicking on the add sign this modal is opened including an input text field. When the admin starts typing, matching user names (first or last name) are shown in a drop down menu below the input field and the admin can select the corresponding user. A selected user is then added as an instructor of the corresponding course. By clicking on the cross in the tag including the course instructor's name. The corresponding user is removed as an instructor from this course.
    • the program: by clicking on the program short title a dropdown menu is shown including the short titles of all existing programs. By clicking on it the, the course is assigned to the corresponding program (if the filter is set in a way that the courses of the newly selected program are not shown the action will result in this course "vanishing" from the table).
  • Below the table are buttons to change the currently displayed page and a text indicating which part is currently shown.
  • Further, an additional option to add a new course is shown (equivalent to one above the table.)

Optional and Future Implementations

  • When a row is double clicked to access the page to edit/ manage a specific course, a tab corresponding to the current course status is opened. If Course:Status is equal to "DRAFT", the view with first tab is opened; for "READYFORPUBLICATION" the second tab is opened; for "READYFORAPPLICATION" the third tab is opened and otherwise the 4th tab is opened. Alternatively, it can be stored in a cookie which tab the user had opened the last time when he was managing this course.
  • A text search field on the top right, comparing the entered text to all course titles and filtering the course table to only those with matching strings (still respecting the currently selected tab filter).
  • The publication status of the course [Course:Status] shown in form of a pie chart, where "DRAFT" corresponds to a grey pie chart, "READYFORPUBLICATION" to a quarter pie, "READYFORAPPLICATION" to a half pie, "APPLICANTSINVITED" to3/4 pie, and a full pie to "PARTICIPANTSRATED".
  • It is possible to select/mark a single course or a set of courses and click the right mouse button to perform an action on these courses, for example to copy or delete these.

Initiating Mails on New Table Entries

In order generate and log mails a table "Mail" is used. New entries in this table result in an Hasura action to send a corresponding mail. To easily adapt the content of the used emails (currently a small set of standard emails), a second table including mail templates is used [MailTemplate].
However, besides using a template, which is used to complete all fields in the mail log table as needed, it is also an option to "manually" complete all the fields and thereby allow a frontend application to freely formulate an email.

Details

Table [Mail] (maybe "MailLog"?)

  • The table includes the following fields: User, Template, From, To, CC, BCC, Subject, Content, Status (default of Status is "IN_PREPARATION"
    (where [Mail:Template] must be any of the values given in [MailTemplate:Name])

Table [MailTemplate]

  • The table includes the following fields: Name, From, CC, BCC, Subject, Content
    (where "Name" corresponds to the name of the template and must be unique)

Enum table MailStatus

  • "IN_PREPARATION"
  • "READY_TO_SEND"
  • "INVALID"
  • "SEND_ERROR"
  • "SENT"

Sending via a template

  • If the field [Mail:Status] of an entry is set to "READY_TO_SEND", the hasura action checks if [Mail:User] and [Mail:Template] are provided and include valid values (the user exists and the template exists as well), and if the fields subject and content are not empty.
  • If any of the conditions is not met, [Mail:Status] is set to "INVALID"
  • If the values are valid, the template with the name [Mail:Template] is used to complete the remaining fields in the table [Mail] and the field [Mail:To] is set to [Mail:User--User:Email].
  • Finally, the mail is tried to be sent; if the sending was successful [Mail:Status] is set to "SENT" otherwise [Mail:Status] is set to "SEND_ERROR"

Optional and Future Implementations

  • NA

Modal to Confirm Course Participation

This modal is shown when a logged-in user clicks in his start page (issue #13) on a tile of a course that he had applied for and received an invitation [Enrollment:Status=="INVITED"].
If the user confirms the invitation, the [Enrollment:Status] is set to "CONFIRMED"; thereafter, the modal closes and a check is performed on the date of the last profile update. If there was no profile update within the last two month, a second modal opens asking the user to confirm his current profile information. After the confirmation (or change) of the profile information, she/he is forwarded to the corresponding course site.
If the user rejects the invitation, the {Enrollment:Status] is set to "REJECTED", and the user is directly forwarded to the corresponding course site.

Details

Optional and Future Implementations

  • NA

MOOChub API

In order provide other course providers/platforms with information about available courses, the information is provided via JSON-API implemented according to the MOOChub schema.
Current examples of such implementations are the ones from openHPI and KI-Campus:

The API should be provided under:

Details

The MOOChub schema shall be implemented as follows:

TODO: Assignment of the keys in MOOChub based on corresponding values in hasura

Optional and Future Implementations

  • NA

Course Application (logged in)

A logged-in user found a course he would like to participate and clicks on the apply button in the view with the course description to start the application (the behavior for a user that is not logged in is described in a later ticket).
The application itself consists of a motivation letter that the applicant must submit.
After submission of the application the apply button in the course description disappears and a message showing the application status is shown.

Details

Optional and Future Implementations

  • NA

Review: Serverless Function for Scoring

A serverless function is implemented that can download and execute a python script using a csv as an input.

Details

  • The serverless function accepts two inputs:
    • an Url providing the download location of the python script
    • an Url of a csv (or directly the data given in a csv)
  • The output should be as follows:
    • The output of the python script if it is a numeric value above 0 or equal to 0
    • NULL if the output of the python script is not a numeric above 0 or equal to 0

Optional and Future Implementations

  • NA

Mail Interventions

In order to better inform, guide and motivate the course participants, it is useful to automatically generate mails for the participants when certain conditions are met. To do so for each such mail intervention, a mail template is stored in the corresponding backend table and a cronjob regularly starts a serverless function is defined to check for each individual participant if one of the conditions is met and send the corresponding mail template.

Details

The following interventions are needed:

  • If the number of sessions with [Attendance.status=="MISSED"] is equal to [Course.maxMissedSessions]:
    Info that she or he must not miss any more sessions to get any type of certificate for the course.
  • If the number of sessions with [Attendance.Status=="MISSED"] is larger than [Course.maxMissedSessions]:
    Info that he won't get any type of certificate sut may resume to take part in the course if the course instructor is ok with that- If a participant missed three session:
    Info that he won't get any type of certificate but may resume to take part in the course if the course instructor is ok with that.
  • I a certificate was generated and made visible for a participant/ course:
    Info that a new certificate was made available.

Optional and Future Implementations

  • NA

Course Description (logged in and incomplete)

If a user did not successfully complete a course. The enrollment status is incomplete. The shown site is then very similar to the site with "complete" status. However, the status messages are changed correspondingly, the section for the certificate download is not included and possible a different text is shown in the section on the tasks

Details

  • The format of the URL and the design can be taken from the site variant with "completed" status, except that the section for the certifocate download is excluded.
  • The text of the status message should be "Du hast den Kurs leider nicht erfolgreich abgeschlossen."
  • The text displayed in the section on the tasks now depends on whether a task was completed successfully (check corresponding field in the enrollment table). If a task was not completed successfully, it is changed to: "Du hast den zugehörigen Online-Kurs leider nicht erfolgreich abgeschlossen." or else "Du hast das Projekt “XYZ” leider nicht erfolgreich abgeschlossen."

Optional and Future Implementations

  • NA

Start Page (logged in)

A logged-in user not only wants to review currently available courses to possibly apply for them but review the courses he already applied for, got declined, got accepted, or completed. Therefore, this view shall include an additional section with only these courses. In order to differentiate the status of these courses the background of the text field in the course tiles shall additionally have different colors depending on the course status.

Details

Optional and Future Implementations

  • Depending on the status of a course the background color of the text field in a course tile is changed to a status specific color. An extra ticket was created for that: #35

Admin User Overview

A basic need for the administration of the users on the platform is to create new users, revise and potentially change their information. This view displays the currently on the platform registered users in a table.

This view is part of the back-office functionality for the Admin users, which is to be implemented responsive but desktop first.

Details

  • The URL of the site is: [domain]/profiles/
  • For admin users the menu of the standard header is extended by the item User to access this site
  • The design should be as follows:
  • A section on the top right with a search field and a button to create a new user (the filter functions on the top left may be omitted in the MVP version; see optional implementations below):
    • the search field searches through the first name, last name, and mail address of all users in the database and filters the table to users with matching strings only
    • a titled plus button to create a new user. When the button is clicked, the user profile view is opened (see issue #39) to create a new user ([domain]/profile/id=new; cf. issue #39).
  • A table including the sortable columns first name, last name, email, and registration date of the user. As a fixed standard 50 rows are displayed. The sorting of the table is always conducted across the full dataset of users and the first fifty users of the selected sorting are displayed. The sort icons are always displayed 15 px right of the title text. If a title text is too long for the column width, the title is wrapped on multiple lines. The standard sorting of the table is according to the user registration date with the user who registered last on top.
  • Below the table are buttons to change the currently displayed page and a text indicating which page is currently shown.
  • Further, an additional option to add a new user as shown (equivalent to one above the table.)

Optional and Future Implementations

  • A section on the top left with filter functions:
    • according to the program a user has had an activity, as a applicant, participant, speaker, or instructor (admins are always considered as active in a program)
    • according to the role of a user
  • It is possible to select/mark a single user or a set of user and click the right mouse button to perform an action on these user, for example to delete these or export their data.
  • For course instructors this view is filtered to only those users that participated or participate in a course of the course instructor (Enrollment:Status equals "CONFIRMED", "ABORTED", or "COMPLETED").

Admin Program Overview

The first step in providing an educational offer via the EduHub application is always to create an educational program. Any course must be part of an educational program, which is why its creation is a necessity before any course offer can be created.
A new program is created by clicking on the add sign on the top or below of the table of currently existing programs.
By clicking on the add sign a new program is added at the top of the table with default or empty values for the data fields that can be defined (the default values are given in brackets below, the names of the corresponding table fields are given in parenthesis directly before).

This issue is part of the backoffice functionality for the Admin users, which shall be implemented responsive but desktop first.
All admin as well as the course instructor views include the standard header and standard footer.

Details

  • The URL of the site is: [domain]/programs/
  • For admin users the menu of the standard header is extended by the item "Programs" to access this site
  • The design should be as follows:
  • On top of the main section with the table is a titled button on the right to add a new program. The titled button is added in the same way below the table at the end of the page. By clicking on the add button a new row with the given default values is added at the top of the table.
  • The main section is including the table showing all currently existing programs. Initially the table is sorted according to the date indicating the start of the courses, with the most recent start date on top. All date and text fields in the table can be edited directly. All columns are sortable, and the sorting item is shown 15 px right of the text box including the title. If a title text is too long for the column width, the title is wrapped on multiple lines.
  • The columns of the table are as follows:
    • a check box to switch the publication status of the program (by clicking on it). When the user clicks on the check box to change the status a confirmation message is shown before the status is actually changed. The design of the confirmation message is given here: Veröffentlichen / Veröffentlichung zurücknehmen (Program: Visibility) [not checked]
    • title of the program (Program: Name; max_length: 40) ["Enter program title here"; if the program name already exists it is extended by an underscore, e.g. to "Enter program title here_"]
    • short title of the program (Program: ShortName; max_length: 6) [default: "PRG"]
    • start of the courses (Program: Start) [empty field, might be something like "MM/DD/YYYY"]
    • end of the courses (Program: End) [empty field, might be something like "MM/DD/YYYY"]
    • start of the application period (Program: ApplicationStart) [empty field, might be something like "MM/DD/YYYY"]
    • end of the application period (Program: ApplicationEnd) [empty field, might be something like "MM/DD/YYYY"]
    • date for the last upload of a performance record (Program: PerformanceRecordDeadline) [empty field, might be something like "MM/DD/YYYY"]
    • a trash bin symbol with the option to delete the corresponding program; if the user clicks on the trash bin this confirmation message is shown
  • Additional to the main fields each program row can be unfolded by clicking on the downward pointing arrow on the right. As soon as the program is unfolded the arrow points upwards. Collapsing the program is done by clicking on the arrow, which the again points downwards. It is possible to unfold as many programs as are shown. The fields shown in the unfolded status are:
    • 3 input text fields for entering links to three different types of questionnaires (Program: QuestionnaireStart, Program: QuestionnaireSpeaker, Program: QuestionnaireEnd) [empty, no default questionnaires are provided]
    • 2 upload fields showing the title of the uploaded fields and an upload icon; by clicking on the fields the file upload dialogue for the local operating system is initiated. The texts in the upload field contain the titles of the originally uploaded file. (Program: FileNameTemplateParticipation, Program: FileNameTemplateParticipationCertificate, Program: FileLinkTemplateParticipationCertificate, Program: FileLinkTemplatePerformanceCertificate) [empty, no default files are provided]
    • 1 text input field for the maximum number of missing attendances (Program: MaxMissedDates) [default is 2; will be set in the backend table]
    • 2 check boxes to set whether issued certificates should be visible for the program participants or not (Program: VisiblityParticipationCertificate, Program: VisibilityPerformanceCertificate).

Optional and Future Implementations:

  • The two upload fields for the certificate template might be implemented at a later point during the semester and are not necessary for the start of the semester
  • The check boxes for the visibility of the certificates can only be selected if corresponding certificate templates are uploaded. If not a corresponding error message is shown.
  • It is possible to select/mark a single program or a set of programs and click the right mouse button to perform an action on these programs, for example to copy or delete these.

Course Application (logged out)

A user that is not logged in found a course he would like to participate and clicks on the apply button in the view with the course description to start the application.
Since a user has to be logged in for an application, he is guided at first to the login dialogue, in which he or she can login (or potentially register). After a successful login the user is then guided back to the title page.

Details

  • By clicking on the apply button the login dialogue is opened.
  • After successful login, the user sees the start page in the logged-in version.

Optional and Future Implementations

  • The login dialogue is extended by a message indicating that the user must login first in order to apply for this course.
  • After the login the user gets directly back to the page with the course description where he clicked the apply button, and the popup for the application is open.

Location and language for course description

This was originally part of #10


The course meta information needs to display a reasonable location and the language of the course.

This was omitted in the first place as the values were not available at that moment.

Two custom block for course description

This was originally part of #10


The course description page should be extended by two custom blocks with content the admins / course instructors can set individually for each course.

  • Two sections with additional course information are displayed, each with a title (Title Text Field 1; Title Text Field 2) and an unformatted text (Content Text Field 1; Content Text Field 2)

Serverless Function for Attendance Registration

It must be checked how the frontend is currently querying and displaying the data.
Changes by the course instructors are probably not saved correct at the moment (i.e. as additional rows in the attendance table).
The whole process must be reviewed again and the frontend be changed correspondingly.

Details

  • ...

Optional and Future Implementations

  • NA

Profile Registration and Update in Hasura

Initial a user is only registered in Keycloak via the Keycloak registration dialogue, in which the user defines first name, last name, email address, and password.
The user is not registered in Hasura until the application tries for the first time to update the user profile. When the user profile is supposed to be updated and the user does not exist in Hasura yet, a profile update dialogue is shown to the user, in which he is asked to complete his profile with additional information. After completion of the dialogue by the user, the user then is instantiated in Hasura.

Details

The design should be as follows:

  • Desktop
  • Mobile: In correspondence to the desktop view
    All input fields that are shown are mandatory. However, some fields are only shown under conditions of other input fields.
    In the following more details on each specific input field:
  • first name:
    • User.firstName
    • if the user has not been instantiated in hasura before, the current content is retrieved from Keycloak
    • input format must correspond to the one given in Keycloak
  • last name:
    • User.lastName
    • if the user has not been instantiated in hasura before, the current content is retrieved from Keycloak
    • input format must correspond to the one given in Keycloak
  • email:
    • User.email
    • if the user has not been instantiated in hasura before, the current content is retrieved from Keycloak
    • input format must correspond to the one given in Keycloak
  • password:
    • the password is only stored in keycloak, so a change her should lead to a direct change in keycloak
    • if the user has not been instantiated in hasura before, the current content is retrieved from Keycloak
    • input format must correspond to the one given in Keycloak
  • employment status
    • User.employment
    • input options are given in the enum table Employment
  • university
    • is only shown if for employment status either STUDENT or ACADEMIA is selected.
    • User.university
    • input options are given in the enum table University
  • university name
    • is only shown if in the university input field OTHER is selected
    • User.otherUniversity
    • open text field
  • matriculation number
    • is only shown if in the university input field CAU_KIEL is selected
    • User.matriculationNumber
    • open text field

Optional and Future Implementations

  • If the profile is updated by an admin user, he can grant the user additionally with admin privileges.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.