Replies: 3 comments 1 reply
-
Hello, Thank you for opening this discussion. I know eLab is being used successfully for teaching, but you are correct, it is not the primary usage focus, so some things might be more complicated to achieve that they need to be.
Use the API. See for example: https://github.com/elabftw/elabapi-python/blob/master/examples/06-create-users.py
Same answer, this can be automated, as long as you have the information in a usable format, such as xls/csv or json or something.
If the "student groups" are "TEAMS", then it's closed by default, meaning user in team A cannot see what happens in team B. Unless someone decides to make it visible to others users/teams. Maybe what you're looking for here is a way to actually prevent this action entirely. But as I already said to other teachers: if students want to cheat, they'll cheat. They can send information between themselves using end-to-end encrypted messages with screenshots very easily, and you'll never know about it. So preventing sharing in eLab is moot. The important point is that if something is not shared, then it is not visible by others.
Why? Just create more teams.
Bad idea. Having a fork and trying to maintain it would be a terrible decision. I can guarantee you that it won't be maintained and you'll be stuck at some version forever. The better approach is to identify the missing pieces to make your life easier, and adding them to eLab. For instance, having a way to upload a CSV to create users could be easier to work with than using the API. What you would need to do is describe very precisely and concretely what exactly you feel is missing. So far, you've listed your needs, but didn't mention how eLab could or couldn't adress them. AFAIK, the current permission and user management system is enough to get it to work. A group of student is in a team. The supervisor is Admin in every team they need to be. Each team is compartimentalized by default. |
Beta Was this translation helpful? Give feedback.
-
Are you planing to use local accounts for this or do you want to use LDAP/SAML later (or hybrid etc..)? It's great that you explain your use case - what would you say are the exact requirements lacking? - is it "mass add/edit of users over the UI?" From what you explained there is nothing that "screams" fork to me. I would counsel forking only as an ultimate ratio when your needs/wants run counter to core upstream and there are irreconcilable differences needed because of that. |
Beta Was this translation helpful? Give feedback.
-
Thanks for your replies @NicolasCARPi and @alexander-haller. I totally agree, that forking code is not the first way to adress challenges. In the future we will use the API and scripts to prepare a training course and to We will not organize student groups into teams to prevent them for sneaking on other groups experiment. If they want to, they will find a way anyways. We have experienced one "incident" which is of general interest. ElabFTW adresses this to some extend with a warning. As I understand the feature, the warning message is related to the timestamp of the last saved (can be auto-save) edit of another user and not to the fact that the doc is in edit mode by another user. We recommend to change the behaviour to show a warning I am aware of the challenges to have realtime collaborative edits, not asking for it. I would like to see a clear message, that the experiment is currently under edit by someone else to avoid overwritting data. |
Beta Was this translation helpful? Give feedback.
-
Dear community and Dev Team,
I would like to open a discussion and collect your feedback and experience when it comes to the application of elabFTW in teaching at universities. We are involved in several projects which aim to foster the application of ELN in academia for communities in chemistry, material science and engineering.
Within these projects we utilize elabFTW in teaching and in lab courses to introduce ELNs to students as early as possible.
Embedding elabFTW into establised lab courses we experienced several requirements which elabFTW currently doesnt cover, probably because the use cases have not been in the main focus so far.
Our use case.
Within a lab course students conduct up to 6 experiments. They are organized in groups up to 6 students, supported by a tutor. They aim to learn how to prepare and conduct experiments and document these with elabFTW, learning how to write protocols. Student groups should not be able to see the activities of the other groups, especially not share, copy/paste experiements across groups. On the othter hand tutor accounts need to see experiment across student groups they are assigned to. We are currently running a first test lab course with 250 students also testing the protocoll submission / correction in elabFTW.
Further details
We have large amounts of user accounts to be created, managed during the lab course and archived afterwards
We need to organize students into groups, define tutor accounts and handle permissions
We have reoccuring experiments to be conducted by student groups
We have specific requirements on permissions to limit access to protocols between student groups
We will soon face the challenge to run more than one course within one elabFTW instance bringing more challenges with user account management
Our current brainstorming is pointing into the direction of having something like "elabFTW Edu" which adresses features to cover the specific needs in teaching environments. We are interested in a joint discussion and may also provide dev resources to work on specific implementations for elabFTW.
We do see a high demand on discussing these question as we see a constant rise of ELN systems across universities, which is a great development!! We need to train the new generations of researchers as early as possible.
Beta Was this translation helpful? Give feedback.
All reactions