generalize for sandbox
Closed this issue · 9 comments
[potentially make a branch if required]
- don't use
urn:class:lausdhardcoded in the class urn.
Here is a list of changes to generalize the class setup:
- class creation process
- Allow an unidentified subject (e.g. statistics, data science) or project name to be specified.
- individual class detail page:
- allow a teacher to create a single user. This will be a simple form asking for the same information that the batch user creation requires i.e., first_name, last_name, personal_id, and organization. Upon creation, this user should be added to the class.
- improve the batch user creation by providing a tooltip that contains instruction and a link to download a csv template with the required header and a few rows of examples.
- No filtering for class members. Right now we only display lausd-* users. This is no longer needed for the general version. The same rule applies for # of users associated with the class.
- deployment configuration
- the server allows the username prefix and number of digits to be specified. We might have to configure this per deployment.
- class setup privilege (extra)
- when a user click a class setup, if an error is reported due to lack of privilege, can we ask them to complete a simple form that asks for the detail of their projects and then submit that as a survey response to our server or send an email to support@mz? We can then manually review the detail in order to determine whether to give them the privilege..
That's all i can think of for now..
In the edu case, we have the concept of 4 class types and their associated campaigns (math, ids, science and generic). In the non-edu case, we don't have this concept. Perhaps we could have this area instead be a campaign selector with our common pre-fab campaigns that the coordinator can select from the list to have added to their class?
Another thought is that the "generic" class setup tool really should not be interacting with campaigns at all -- the area could be removed and some defaults could be added to the campaign manager to quickly create common campaigns?
Finally, we currently generate class urns from the user's last name, class subject and class period number. This is how we accomplish getting "unique" class urns. We should add a name/urn field to the creation process that generates something along this long, but allow the coordinator to set it as they wish.
So how does this interact with the requirement that when a class is deleted, it should automatically delete all campaigns that are associated with the class? I still have not implemented this due to concerns about accidentally deleting campaigns with responses.
Could we maybe look into doing this part on the server? For example have a flag in /app/class/delete like delete_associated_campaigns=true. That would make it a bit easier to generalize this tool.
Or alternatively like steven suggests we can make a generic class manager to create/delete classes and import/export users without making it automatically try to guess which campaigns to deploy/delete.
I forget exactly where @hongsudt and I landed when we talked about this, but I think the campaign deletion from the server-side is extremely bad practice. Campaigns and classes in ohmage are both top-level objects: trying to distinguish and delete one based on deletion of another should never be done in the server since they have no associated hierarchy. The only place this actual happens in the server currently is user/delete (which can only be called by an admin) and that use case makes a bit more sense as it deletes the survey_responses generated by that user (the "owner" of that data), but nothing more.
Given that, if it's a tool feature to clean up the campaigns, it should really only be done via the client. If it needs to be automatic, we have to deal with that limitation and assume that there could be some potential loss of data. However, I feel like similarly to the "user removal" step in the class setup tool: perhaps there could be a modal with the campaigns associated only with that class and their response count and a delete button to allow the coordinator to make this decision themselves?
Either way, that should definitely not be a feature in the "general" use case, as far as I know.
@jeroenooms I'm not sure if @hongsudt shared this with you specifically, but my thought for this was actually to just start fresh with a "classes" frontend, if you'd prefer to do it that way.
one more thing to note too: the "single user creation" item would actually hinder the ability to look up the user's password on a return to the page. You need first,last,org,pid to get the return from /user/setup, so it would be extremely awkward for the coordinator to have to perfectly re-type that every time they return to the page in order to get whatever the initial_password is...
Maybe single user creation should not use /user/setup then but regular registration with an email address?
That last thing I mentioned isn't actually a problem I dont think...since our current frontend doesn't require a teacher to upload a csv every time they visit the page. Only my misunderstanding of the api!
Another idea that came up is..... after a user clicks delete class, we
allow them to select which campaigns to be deleted. By default, all
campaigns should be checked, and then they can uncheck to leave them out.
This will make the class deletion more transparent..
For those campaigns that are checked, if they are other classes that are
associated with them, the client should just remove the campaigns from the
deleted class (campaign/update), otherwise, delete the campaigns
(campaign/delete).
On Sun, Sep 13, 2015 at 11:04 AM, Steve Nolen notifications@github.com
wrote:
That last thing I mentioned isn't actually a problem I dont think...since
our current frontend doesn't require a teacher to upload a csv every time
they visit the page. Only my misunderstanding of the api!—
Reply to this email directly or view it on GitHub
#45 (comment)
.
There is now a separate generic (non-lausd) class-setup tool. Please move issues there: https://github.com/mobilizingcs/classes.