| 77 | | ## B10 ## |
| 78 | | ## B2. Register course payment ## |
| 79 | | ## B3 ## |
| 80 | | ## B4. Update learner account status ## |
| 81 | | ## B5 ## |
| 82 | | ## B6. Register course admission status ## |
| 83 | | ## B7. Register course denial status ## |
| 84 | | ## B8 ## |
| 85 | | ## B9. Register learner-course performance ## |
| 86 | | ## C1 ## |
| 87 | | ## C2. Yield CPCC information ## |
| 88 | | ## D1. Create a netid + password ## |
| 89 | | ## E1. Provision a new user ## |
| 90 | | ## E2. Enroll user in course ## |
| 91 | | ## F1. Handle course / program payment ## |
| | 78 | Then it performs the following two actions: |
| | 79 | |
| | 80 | - The subprocess 'Manually handle the admission' is started. (TODO: specify how this is done) |
| | 81 | - Display an informational page for the learner on how to proceed now. (QUESTION: Also e-mail confirmation?) |
| | 82 | |
| | 83 | # Learner registration system actions # |
| | 84 | |
| | 85 | == B1. Register pending course registration == |
| | 86 | |
| | 87 | This action registers the fact that a learner is in the process of registering for a cpcc. This process is always in a certain state. |
| | 88 | |
| | 89 | == B2. Register course payment == |
| | 90 | |
| | 91 | This action registers the fact that a pending registration has been payed. Special care needs to be taken that this information cannot disappear (financial tracking). The action then forwards to action [#B3 B3] |
| | 92 | |
| | 93 | == B3 == |
| | 94 | |
| | 95 | This action is a parallel branching action starting of a number of separate actions: |
| | 96 | |
| | 97 | - Make sure a netid is created for the current learner through action [#D1 D1]. |
| | 98 | - Make sure the learner is registered in Osiris through action 'Create student record in Osiris' (TODO: specify how this is done) |
| | 99 | - Update the learner's account status through action [#B4.Updatelearneraccountstatus B4] |
| | 100 | |
| | 101 | == B4. Update learner account status == |
| | 102 | |
| | 103 | This action makes sure that the account status for the given learner is updated to the proper status (meaning this learner has payed money to the extension school!) |
| | 104 | |
| | 105 | == B5 == |
| | 106 | |
| | 107 | This action waits for two processes to finish: [#B4.Updatelearneraccountstatus B4] (update learner account status after having payed) and [#E1 E1] (create the learner as a user in Blackboard). When these two processes signal finish (TODO: How do they do that?) the following two actions are started: |
| | 108 | - [#A6.Admissiontypeforcpcc A6]: "Handle the go-signal for this user to start learning" |
| | 109 | - [#E2 E2]: Enroll this user in the proper Blackboard course |
| | 110 | |
| | 111 | |
| | 112 | == B6. Register course admission status == |
| | 113 | |
| | 114 | This action registers the fact that the learner was formally admitted in the given cpcc |
| | 115 | |
| | 116 | == B7. Register course denial status == |
| | 117 | |
| | 118 | This action registers the fact that the learner was formally denied access to the given cpcc |
| | 119 | |
| | 120 | == B8 == |
| | 121 | |
| | 122 | This action branches off the parallel actions required to handle the fact that a learner was denied access to a cpcc. It starts the following actions: |
| | 123 | |
| | 124 | - Refund the learner (TODO: specify how this is done) |
| | 125 | - Consume bad news message: failed admission (by sending an e-mail to the learner) |
| | 126 | |
| | 127 | == B9. Register learner-course performance == |
| | 128 | |
| | 129 | This action registers the performance of a learner in a course |
| | 130 | |
| | 131 | == B10 == |
| | 132 | |
| | 133 | BUG: This part of the diagram looks buggy. Probably the teacher registers in Osiris first... |
| | 134 | |
| | 135 | # Digital offering registration system # |
| | 136 | |
| | 137 | This awful name is given to the database that holds the course-information, certification possibilities and their combinations. |
| | 138 | |
| | 139 | == C1 == |
| | 140 | |
| | 141 | BUG: The diagram looks wrong here. Probable action C1 should be "Record information for a new course", and the arrow coming in from above should go directly to C2. |
| | 142 | |
| | 143 | == C2. Yield CPCC information == |
| | 144 | |
| | 145 | This action handles the search and faceted search and retrieves cpcc's that match the filter/search-entry. |
| | 146 | |
| | 147 | # NetID # |
| | 148 | |
| | 149 | NetID is the Identity management system for TU Delft. A 'netid' designates the username a given user holds in the NetID system. |
| | 150 | |
| | 151 | == D1. Create a netid + password == |
| | 152 | |
| | 153 | After a user has payed he is entitled to receive a 'proper' netid. Since he was already known in the learning mall his data will be transferred from there and used to create this new netid-entry. |
| | 154 | |
| | 155 | # Blackboard # |
| | 156 | |
| | 157 | Blackboard is the digital learning environment currently in use by TU Delft. |
| | 158 | |
| | 159 | |
| | 160 | == E1. Provision a new user == |
| | 161 | |
| | 162 | Provisioning a user means creating her netid as a regular Blackboard-user. After the user is provisioned she can log on to Blackboard. |
| | 163 | |
| | 164 | == E2. Enroll user in course == |
| | 165 | |
| | 166 | Enrollment means that the given Blackboard-user is registered as a student in the given course. |
| | 167 | |
| | 168 | # Digital payment system # |
| | 169 | |
| | 170 | This system remains to be implemented. It will probably be supplied by Ogone. |
| | 171 | |
| | 172 | == F1. Handle course / program payment == |
| | 173 | |
| | 174 | This action will handle the payment of the cpcc by the learner and will provide the necessary data back to properly digest this at TU Delft. |
