Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expansion of Data Model and Meta Data Access #116

Open
niclasheun opened this issue Jan 27, 2025 · 0 comments
Open

Expansion of Data Model and Meta Data Access #116

niclasheun opened this issue Jan 27, 2025 · 0 comments
Labels
Component: Core Issues related to the prompt core

Comments

@niclasheun
Copy link
Contributor

niclasheun commented Jan 27, 2025

Refine Metadata Access for Course, Course Phase, and Course Phase Participation

Problem Description

We currently use meta_data fields for Course, Course Phase, and Course Phase Participation to store various information (e.g., mail settings, scores, seat assignments). Access to these fields is restricted:

  • Lecturers have read/write access.
  • Editors have read-only access.
  • Students have no access.

However, this setup has become too restrictive. For example:

  • Editors sometimes need write access (e.g., to record absences or add comments).
  • Students also need some level of access (e.g., to view seat assignments, fill out surveys, or provide other input).

Micro frontends could work around this limitation by storing data in an external service, but that creates additional problems:

  1. Data Fragmentation
    If student data (e.g., skill surveys) is stored externally, subsequent phases cannot easily access it unless an instructor 'manually' copies it over into the meta_data and allow other phases to access it.

  2. Security/Access Issues
    Granting a tool token for direct access to meta_data on behalf of a user who otherwise lacks permission introduces additional risks and complexities.


Proposed Solution

1. New Fields for Course and Course Phase

  • open_meta_data -> new name student_readable_data
    A new field accessible to students. This could store information such as a course logo or other public information.

  • Existing meta_data -> new name restricted_data
    Remains read/write-accessible to the course lecturer and possibly editors in read-only mode. This can store settings like mailing configurations, which students do not need to see and editors don’t need to modify.

2. Revised Fields for Course Phase Participation

Introduce three separate metadata fields (plus an editor restriction mechanism):

  1. meta_data (already exists) -> new name restricted_data
    Stores information students must not see (e.g., scores, private comments), read/write accessible to lecturers (and possibly editors).

  2. open_meta_data -> new name student_readable_data
    Stores information students can see but cannot modify (e.g., seat assignments).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Component: Core Issues related to the prompt core
Projects
Status: No status
Development

No branches or pull requests

1 participant