Closed Abdulla-Alkhulaqui closed 2 years ago
@Abdulla-Alkhulaqui Regarding adding a student by the admin, should a random password be generated? or what is the deal there exactly? In a more sophisticated application, we need to send an email. However, since no emails will be included in the platform, creating a new student must generate a new random password, then the student can update it...?
Moreover, regarding changing a user from a student to a teacher will not be implemented in the backend! Me and @the4t4 discussed this issue few days ago, and settled on not doing that. We will have demonstrators, students, admin roles only and they are assigned when the users are created in KeyCloak. Therefore, for a beginning, we assume that the admin created the users and assigned them to roles beforehand (Using the Keycloak UI at localhost:8081
) . And later we can integrate that into the platform when creating a user. So when creating a user through the React Platform, the admin needs to give the user a role. And maybe later, the admin can also have the ability to change the user role. But the user roles are not group dependent
UPDATE
[GET] Doneapi/section/all
[POST] Done. api/section/add?sectionName=midterm
sectionName
should be sectionid
[GET] Endpoint added but duedate does not exist yetapi/section/tasks/all
If the task is finished, then the student grade should be provided as well.
This endpoint will not get the grades because the tasks table does not contain grades. Another endpoint should be created for this. Also the grade will exist only when the task is graded, they won't have a 'null' value before that.
[PUT] api/account/password
Not done yet
[PUT] api/section/edit
All the functionality requested in this endpoint is too complex for a single endpoint. First of all, a PUT request should not delete data for instance and etc. An endpoint has been added to update section information in the db.
[PUT] api/task/edit
same issue as above, an endpoint has been added to update task information in the db.
[POST] api/correct"taskId=
Not done yet
[PUT] Done. The list of students should be given like: {student1 : { data }, student2 : {data}, ...}api/student/add
[PUT] Done, also added [DELETE] api/group/assign
api/group/unassign
All of the endpoints (except get) require most if not all parameters of the respective tables. None of the endpoints handle authorization yet.
I just want to clarify some stuff: @Abdulla-Alkhulaqui @RealGorandos @the4t4
[PUT] api/account/password
Not done yet is not a simple one to implement. I don't think we have a realm-manager access from the backend to keycloak. Therefore, it might not be easy. I am not sure if the user can change their passwords in keycloak without some certain role maybe. I will have to dig into that.
[PUT] api/section/edit
gives the ability only to change the section name. If deletion must be implemented it must be in another endpoint. [DELETE] api/section/delete
.
[PUT] api/student/add
each student must be created in keycloak as well. Creating it in the database without keycloak is meaningless to some extent. Now when we say create it in keycloak multiple issues appear to the surface. (The password creation is the largest concern).
For now, we assume that the one who deploys our project will create the users manually through the keycloak UI and in the DB through the pgadmin. Therefore, we always assume that they exist and they are equivalent. The connection between the Keycloak DB and the CAP DB is the user's "username". I would highly recommend focusing on the management part of the project rather than spending time on the user creation part. Therefore, we assume that "users" exist in both our keycloak and CAP database!
[PUT] api/section/edit
does not only change the name, you can change anything, you can even make it a completely new section. In both cases the old section which is being edited will be deleted.
[PUT] api/student/add
is it really not possible to call some keycloak api to add a new user?
@the4t4
1) Regarding the section edit... What part of the section we would need to edit rather than the name? the section resembles only a category tag. Or that is what I think of it. Maybe also the maximum grade? I don't remember if sections holds the grade data...
2) The problem not adding the student, the problem comes from handling the creation and distribution of passwords the right way. As discussed in the "teams" private channel, we can do it the easiest way in which we create users on the fly and return their usernames and their correspondence passwords. The admin needs to handle the distribution of these passwords and deliver them to students.
@Mohido correct, only a name change is needed for our use case but I'm just pointing out that anything can be changed. In the request, all of the parameters need to be given still even if we want to just change the name.
@Abdulla-Alkhulaqui @the4t4 @RealGorandos : User endpoints are done for now. We only don't have users/update/password
endpoint yet. I will rather focus on handling the database functionalities a bit with @the4t4. And maybe file uploading and handling.
@Abdulla-Alkhulaqui @the4t4 @RealGorandos I think this issue can be closed since all the discussed features have been added in { #55 #58 #54 } Pull Requests. Maybe changing the students' password is still missing.
@Abdulla-Alkhulaqui @the4t4 @RealGorandos I think this issue can be closed since all the discussed features have been added in { #55 #58 #54 } Pull Requests. Maybe changing the students' password is still missing.
@Mohido after testing all the endpoints, this issue will be closed.
This task should be closed. If any bug appears regarding a certain endpoint, it should be in a separate issue.
Required API Endpoints
The user should be able to get all the sections so that it is rendered in their home page: Note: groupId should not be a parameter, since the backend can decide what group the user is in based on the session ID.
[GET]
api/section/all
The admin should be able to add a new section to a group: Note: the teacher assigned to the group can also add a new section. Also not sure if the section name is the only parameter that should be provided, but you can investigate that.
[POST]
api/section/add?sectionName=midterm
The user should be able to get all the tasks for a specific section: Note: the meta data of the each task should be available, namely:
[GET]
api/section/tasks/all
(the id of the section should be the parameters)The user should be able to change their password: [PUT]
api/account/password
(the user neptun code and new password should be the parameters)The admin should be able to edit a section: Note: the teacher assigned to the group can also edit a section. This edit will include several types of edits. The user admin/teachers can:
As the parameter body we can have several API endpoints or one the will be able to update everything based on the provided object [PUT]
api/section/edit
The admin should be able to edit as particular task in a section: Note: the teacher assigned to the group can also edit the a task. The point here is to edit the details of the task, that is:
[PUT]
api/task/edit
(the ids of the section and the task should be the parameters)There should be an endpoint that will trigger running the script on a specific task: [POST]
api/correct"taskId=
(the task ID should be a parameter)Only the admin should be able to add students to the website (i.e. register students in the DB): [PUT]
api/student/add
(The parameter should be a list of strings which will be the neptun code of the students)Only the admin should be able to assign a user to group (i.e. change a normal user into a teacher and assign them to the group): [PUT]
api/group/assign
(The parameter should be the group id and the teacher neptun code)(for now this is all what I can think of)