You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would expect to only see the custom adventures that are used in the shared class, would that be possible?
Everything is possible 😆, it's just a matter of time. On first glance it seems like it shouldn't take too long, but I don't have the data model super clear in my head so it might be that there are dragons.
Can we remove the link behind the name of the adventure that goes to the customization page, and disable the remove button. Then the only thing one can do is preview the adventure?
I haven't checked, but I think the current explicitly implemented behavior is that if you share a class with someone, you can do everything to their adventures, including editing and deleting. (The reason I'm saying this is because I've seen calls to get_second_teacher_adventures() in many different places in the for_teachers file, including in the "deleting" code path).
While I agree with you that it seems unexpected, it seems to have been "expected behavior" by someone, because it was explicitly implemented that way. It might make sense as well: if you share a class with someone, you trust them to teach with you, and they might want to make a small improvement to some adventure. It would be annoying if they then had to wait for you to make the change.
These are good questions, that we might need to ponder a bit. Also, I don't think the current PR makes anything worse, you would just like to see more improvements. I propose we do the following:
If you think this PR makes the situation better, merge it as-is
Create 2 new issues for the 2 changes you would like to see (showing only adventures that are used in a class, second teachers only allowed to preview an adventure and nothing else)
Have a discussion on the additional issues and see if this is what we really want, and what the reason is for the current behavior being what it is
This could be a Discord discussion, and it could be informed by going back into the pull request history of the project, finding the PR that in introduced the current behavior, and seeing who made it (ask them) and seeing if there's any discussion on it
The current status is that when teachers share a class, they can see all the custom adventures from one another and thus choose from all custom adventures to add to the shared (!) class (it is not possible to add custom adventures from the second teacher to a class that is not shared with that specific teacher)
The behavior was confusing for me, @MarleenGilsing what do you think on this?
Everything is possible 😆, it's just a matter of time. On first glance it seems like it shouldn't take too long, but I don't have the data model super clear in my head so it might be that there are dragons.
I haven't checked, but I think the current explicitly implemented behavior is that if you share a class with someone, you can do everything to their adventures, including editing and deleting. (The reason I'm saying this is because I've seen calls to
get_second_teacher_adventures()
in many different places in thefor_teachers
file, including in the "deleting" code path).While I agree with you that it seems unexpected, it seems to have been "expected behavior" by someone, because it was explicitly implemented that way. It might make sense as well: if you share a class with someone, you trust them to teach with you, and they might want to make a small improvement to some adventure. It would be annoying if they then had to wait for you to make the change.
These are good questions, that we might need to ponder a bit. Also, I don't think the current PR makes anything worse, you would just like to see more improvements. I propose we do the following:
Originally posted by @rix0rrr in #6134 (comment)
The text was updated successfully, but these errors were encountered: