Skip to content
This repository has been archived by the owner on Nov 21, 2024. It is now read-only.

New necessary fields for the Study Documents #422

Open
michbaum opened this issue Jan 26, 2021 · 6 comments · May be fixed by #423
Open

New necessary fields for the Study Documents #422

michbaum opened this issue Jan 26, 2021 · 6 comments · May be fixed by #423

Comments

@michbaum
Copy link

michbaum commented Jan 26, 2021

To prepare for some QoL improvements in the frontend (displaying all documents sorted by their type from the get go) we require all data to contain a valid document type field. Thus the API should implement this requirement in the backend.
Additionally, new subfields for exams should be added for Spring and Autumn exams, so that they can be displayed sorted as well.

@michbaum michbaum changed the title Make the type of a document a necessary field for the Study Documents New necessary fields for the Study Documents Jan 26, 2021
@NotSpecial
Copy link
Contributor

NotSpecial commented Jan 26, 2021

Hey, and thanks for the suggestion.

Could you provide some additional detail on how you would imagine this? Studydocs can contain a list of files of any type, and they already provide their document types in the content_type field.

Let's say we have a study doc like this one (shamelessly plugging my own stuff haha). It contains multiple pdfs, and a zip file.

The current API response of this document looks like this (I have removed the metadata).

{
  "course_year": 2017,
  "author": "Alexander Dietmüller",
  "lecture": "Technische Informatik",
  "title": "PVK Skript mit Aufgaben",
  "professor": "Prof. L Thiele",
  "type": "study guides",
  "department": "itet",
  "semester": "4",
   "files": [
    {
      "file": "/media/5c812a40672f320001f02678",
      "name": "aufgaben.pdf",
      "content_type": "application/pdf",
      "length": 541080,
      "upload_date": "2019-03-07T14:27:12Z"
    },
    {
      "file": "/media/5c812a40672f320001f0267c",
      "name": "lösungen_1.pdf",
      "content_type": "application/pdf",
      "length": 456904,
      "upload_date": "2019-03-07T14:27:12Z"
    },
    {
      "file": "/media/5c812a40672f320001f0267f",
      "name": "script_1.pdf",
      "content_type": "application/pdf",
      "length": 1435215,
      "upload_date": "2019-03-07T14:27:12Z"
    },
    {
      "file": "/media/5c812a40672f320001f02686",
      "name": "tik_pvk.zip",
      "content_type": "application/x-zip-compressed",
      "length": 853946,
      "upload_date": "2019-03-07T14:27:12Z"
    }
  ],
  }
}

How would you imagine the result after your proposed change?

@michbaum
Copy link
Author

Good morning Alex :)
Thanks for the fast reply! What I meant was the requirement to fill out the "Type" field (Exam, PVK, Exercises, Lecture Documents) when uploading new documents. The only field required atm when uploading something is a title and the files themselves (https://api.amiv.ethz.ch/docs#tag/Study-Document/paths/~1studydocuments/post). We want to display the documents sorted by type, meaning first all exams, then all PVK materials, then all summaries etc., such that lazy students (which there are a lot of haha) find what they need more easily without including the type they're searching for in the query (which they obviously could, but I got some negative feedback that students couldn't find the exams they searched for, obviously not using the query feature).

@NotSpecial
Copy link
Contributor

NotSpecial commented Jan 27, 2021

Ah, so just to make sure: You don't want any extra field, you just want the type field to be required?

And one more question: How do you image the "sub-fields" for exams? We do not really have a concept of sub-fields. Should we remove the option exam and add spring exam and autumn exam? Or should we also keep the generic exam as well?

@michbaum
Copy link
Author

Yes exactly, same fields, just required instead of voluntary :)

For the exams, splitting them up into autumn and spring should work, as long as that does not interfere with the already uploaded documents. Would they still retain the basic exam type?

@NotSpecial
Copy link
Contributor

The existing exams would keep their type. The change would only affect new exams, which would then have to explicitly choose autumn/spring.

@michbaum
Copy link
Author

That should work. We can handle the existing data in the sorting solution :)

NotSpecial added a commit that referenced this issue Jan 27, 2021
We do not wish to allow studydocs without type anymore, so the `type` field is not not nullable and required.

Furthermore, we wish to differentiate between spring and autumn exams for better filtering, so the previous exam type is replaced.

Closes #422
@NotSpecial NotSpecial linked a pull request Jan 27, 2021 that will close this issue
temparus pushed a commit that referenced this issue May 25, 2022
We do not wish to allow studydocs without type anymore, so the `type` field is not not nullable and required.

Furthermore, we wish to differentiate between spring and autumn exams for better filtering, so the previous exam type is replaced.

Closes #422
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants