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

Which problem configuration fields should be edit-able in a library problem? #1317

Open
Tracked by #1086
jmakowski1123 opened this issue Sep 23, 2024 · 9 comments
Open
Tracked by #1086

Comments

@jmakowski1123
Copy link

When creating a problem in a library, I may not know which course the problem will be used in. Or the problem may be used in multiple courses, each with different grading parameters. Thus, I'd expect that the only configurable fields attached to a problem in a library are the generalized fields that apply to the problem content itself, and not the overall grading schema. Those fields are:

  • Type
  • Hints
  • Feedback

I would not expect to see the following configurable fields attached to a problem in a Library. Instead, I would expect to configure these fields within the course outline, such that my configurations are specific to the grading schema of that particular course:

  • Scoring - point weight
  • Scoring - number of attempts/unlimited attempts
  • Time between attempts
  • Show answer parameters
  • Show reset option
@bradenmacdonald
Copy link
Contributor

@jmakowski1123 Would you like me to go ahead and disable those fields? And/or display a note that they're not configurable in libraries? Or does this need some more work to figure out the best approach?

@kdmccormick
Copy link
Member

(following this since it affects the backend)

@bradenmacdonald
Copy link
Contributor

This will be post-Sumac.

@kdmccormick
Copy link
Member

@jmakowski1123 @bradenmacdonald For Sumac, what should happen if I make local edits to a block from a library, and then pull updates from a library? Options are:

  1. Local edits always stay.
  2. Local edits always get blown away.
  3. Certain local edits stay, certain local edits get blown away.

@bradenmacdonald
Copy link
Contributor

@kdmccormick I thought we had an allowlist of fields that make sense to override, like "max attempts", "max score' etc., and anything other than those would get blown away.

@kdmccormick
Copy link
Member

@bradenmacdonald Yep, just confirming that we haven't changed on that

@kdmccormick
Copy link
Member

In the UI, do we need a way to revert those "customizable" fields to their defaults?

@bradenmacdonald
Copy link
Contributor

@kdmccormick Up to @jmakowski1123 but I'd say it's not necessary for MVP.

@jmakowski1123
Copy link
Author

Nothing in this ticket will be part of the the MVP. Sorry for the confusion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Out of scope for MVP
Development

No branches or pull requests

3 participants