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

Feature request: grant access by consuming items #8

Open
Famondir opened this issue Aug 16, 2021 · 2 comments
Open

Feature request: grant access by consuming items #8

Famondir opened this issue Aug 16, 2021 · 2 comments

Comments

@Famondir
Copy link

Famondir commented Aug 16, 2021

It'ld like to see the possibility to restrict the access to an activity by "consuming an item". It would be similar to restrict the access by "having a specific item" (e.g. "key-for-second-attemt-of-activity-xy" and "key-for-second-attemt-of-activity-yz") but it would require the student actively to decide that he wants access to a specific activity by giving away a more generic item (e.g. use "key-of-second-attemps" with activity xy or yz).

The reason to request this feature is to provide the students with more meaningful choises for their learning process and reducing the workload teacher would have if they want to say: there is neither a master key that opens every activity forever nor am I willing to create a unique key for every activity and building a huge tradecenter where you can get all the keys.

As one possible solution a shortcode was mentioned here. This shortcode would have to be placed somewhere near to the locked activity.

Another posibility might be something like this availability plugin that works with a global credit field. One would have to alter the link to the credit so a field that holds the quantity of an item chosen during the restriction process.

Even less work for teachers would emerge in the following scenario: the shortcode would toggle the reopen attemt on a specific assignment / activity (like the teacher could do manually). In this case there would be no need to have copies of activities that you can restrict access to.

A little more work would (but maybe more safe / easier <-- dunno if a shortcode set up by the teacher has the permission to change the state of the assignment; has the executed short code the rights of the student, teacher, or something else?) be the following: The student asks the teacher for reattempt and the teacher checks for a key in studends Stach. Then the teacher subtracts one item and opens the reattempt. This needs the feature from this request.

@danielgoeller
Copy link

I may ask, if there is any future progress planned? The idea of a "consuming"-shortcode would be a great possibility for selforganized learning scenarios.

@abgreeve
Copy link
Owner

abgreeve commented Nov 9, 2023

The ability for students to lose items

This is a popular request and I really appreciate your feedback. I'm going to break it down into two categories and my findings for both.

The "trap" mechanic

This is the easier of the two features to implement. The student lands on a specified page and they lose a certain amount of one or more items. There are a few things that need to be considered in this situation:

  1. How does the teacher determine which page this trap is placed?
  2. What happens in the situation where the page is refreshed?
  3. What should happen if the student does not have the items that are to be removed?
  4. How does the student find out what has happened?
  5. How do we configure these traps?

I think something like this is possible, but the experience is likely to be a bit hit and miss through accidentally being penalised more times than anticipated through unexpected navigation around the course and activities, with the real possibility of students finding ways to avoid these traps.

The purchase of access to an activity

This is much more involved. The feature here is that the student can pay with items to get access to an activity again. Using the trap mechanic listed above to gain access to an activity, while possible, has some drawbacks. The main hurdle is that students do not reliably enter and then complete an activity in one sitting. To not detract from the general experience of using stash, I think it is important that we have a robust system that does not unduly punish the student. So I think that we need a system that will remove items to gain access to an activity and will maintain that access until the student has completed it.

This could be achieved by using the events system. All core activities have an activity viewed event that can start the student's access to the activity. Completing the activity is more challenging. It is not guaranteed that there is an event that matches the completion of an activity. A list of each activity's events could be listed for the teacher to configure and try and find something that matches what they want.

This feature has similar questions to the trap mechanic mentioned above.

  1. How does the teacher pick the activity to apply this cost of access?
  2. Is the student notified of losing items? and how is that displayed?
  3. How do we configure the start and end of activity access?

This sort of event watching is a complex system. It's a project that would take a full time developer multiple weeks of full time work to complete, and I do not currently have time to work on something so complex.

I invite anyone with an interest in these features with the ability to help to feel free to send a pull request.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants