Creating team and user accounts in batch mode
Hi, I would like to create teams and user accounts in batch (e.g. from a spreadsheet). I'm using DOMjudge 4.0.5 and I see that there is an "Import / export" option, but I can't find much documentation on this. I have also somewhat successfully crafted my own SQL statements to insert tuples into the tables directly, but the problem is that I have to ask for the current id for the auto_increment fields of various tables and match them up. It's not a big deal, but if there is an easier option then I would like to know about it. Thanks. Howard -- Howard Cheng e-mail: howard.cheng@uleth.ca Dept of Math and CS URL : http://www.cs.uleth.ca/~cheng/ University of Lethbridge Phone : (403) 329-2182 Alberta, Canada Fax : (403) 317-2882
Hi Howard, On 30-09-15 14:10, Howard Cheng wrote:
Hi,
I would like to create teams and user accounts in batch (e.g. from a spreadsheet). I'm using DOMjudge 4.0.5 and I see that there is an "Import / export" option, but I can't find much documentation on this.
You're right, the documentation on the import/export format is missing. We're using the file formats as documented here: https://clics.ecs.baylor.edu/index.php/Contest_Control_System#Appendix:_File... There is a small difference wrt. that documentation though: instead of the first field of the first line of each TSV file containing "label", it should contain the literal string "File_Version" (without quotes), i.e. the first line of teams.tsv should look like: File_Version 1 This is due to some previous inconsistencies in that documentation. Also, I now notice that in the 4.0 branch we do not support importing accounts.tsv, only teams and groups. In 5.0 accounts can also be imported.
I have also somewhat successfully crafted my own SQL statements to insert tuples into the tables directly, but the problem is that I have to ask for the current id for the auto_increment fields of various tables and match them up. It's not a big deal, but if there is an easier option then I would like to know about it.
Unfortunately, (assuming DOMjudge >= 5.0) the above import method allows you to create teams and accounts, but *not* to automatically couple them. You could create and import teams.tsv and accounts.tsv files with the team "external ID" field (note that DOMjudge accepts strings, not just integers) matching the user "username" field. Then you can write a simple SQL query to create entries in the DOMjudge userrole table to couple these. Creating a better interface for this is still on our todo list... Jaap
Jaap Eldering wrote:
Unfortunately, (assuming DOMjudge >= 5.0) the above import method allows you to create teams and accounts, but *not* to automatically couple them. You could create and import teams.tsv and accounts.tsv files with the team "external ID" field (note that DOMjudge accepts strings, not just integers) matching the user "username" field. Then you can write a simple SQL query to create entries in the DOMjudge userrole table to couple these.
I am working on importing that data now. Does this mean I can use the accounts.tsv file to create accounts for teams, as opposed to the CLICS standard which uses the file for non-team accounts? If so, is the role "team"? I assume the password is cleartext? Marc
Hi, On 11/13/15 09:46, Marc Furon wrote:
Jaap Eldering wrote:
Unfortunately, (assuming DOMjudge >= 5.0) the above import method allows you to create teams and accounts, but *not* to automatically couple them. You could create and import teams.tsv and accounts.tsv files with the team "external ID" field (note that DOMjudge accepts strings, not just integers) matching the user "username" field. Then you can write a simple SQL query to create entries in the DOMjudge userrole table to couple these.
I am working on importing that data now. Does this mean I can use the accounts.tsv file to create accounts for teams, as opposed to the CLICS standard which uses the file for non-team accounts? If so, is the role "team"? I assume the password is cleartext?
Jaap was wrong. We follow the CLICS standard and do only support accounts for non-teams in the accounts.tsv. In these cases, the password is cleartext. (Although you might hack team password import into that function.) However, you might do it the other way around: use the "manage team passwords" page to export a userdata.tsv for all teams (or teams without password) and use that file to set your passwords for the machines. Tobi
Tobias Werth wrote:
Jaap was wrong. We follow the CLICS standard and do only support accounts for non-teams in the accounts.tsv. In these cases, the password is cleartext. (Although you might hack team password import into that function.)
However, you might do it the other way around: use the "manage team passwords" page to export a userdata.tsv for all teams (or teams without password) and use that file to set your passwords for the machines.
I worked around it another way--I imported all the accounts as jury accounts to get the account information in with passwords, then went into MariaDB and changed the account type to team. I then separately mapped the accounts to the teams inside MariaDB as well. That did the trick. I believe that team user import capability should be provided as a standard feature. I will also contribute my other modifications to the code base. The Southern California regional contest was held yesterday and DOMjudge generally ran very well. There were just a couple of instances where a judgedaemon halted, generally after reporting that the chroot environment still had processes running when it was being stopped. I made sure the daemon was stopped, restarted it, and it seemed to recover properly in each case. The rest of the package worked flawlessly. Thanks again to the team for this contest control system! I hope to see the development team in Phuket... Marc
Hi Marc, On 15-11-15 21:55, Marc Furon wrote:
Tobias Werth wrote:
Jaap was wrong. We follow the CLICS standard and do only support accounts for non-teams in the accounts.tsv. In these cases, the password is cleartext. (Although you might hack team password import into that function.)
However, you might do it the other way around: use the "manage team passwords" page to export a userdata.tsv for all teams (or teams without password) and use that file to set your passwords for the machines.
I worked around it another way--I imported all the accounts as jury accounts to get the account information in with passwords, then went into MariaDB and changed the account type to team. I then separately mapped the accounts to the teams inside MariaDB as well. That did the trick.
I believe that team user import capability should be provided as a standard feature.
Indeed, this is on our todo list.
I will also contribute my other modifications to the code base.
Patches are always welcome!
The Southern California regional contest was held yesterday and DOMjudge generally ran very well. There were just a couple of instances where a judgedaemon halted, generally after reporting that the chroot environment still had processes running when it was being stopped. I made sure the daemon was stopped, restarted it, and it seemed to recover properly in each case. The rest of the package worked flawlessly. Thanks again to the team for this contest control system!
This typically happens when a judgedaemon crashes on some issue. Were there any particular reasons, or did this seem to happen randomly?
I hope to see the development team in Phuket...
We hope to be there too! ;-) That's not confirmed yet, but we have good hope. Best, Jaap
The Southern California regional contest was held yesterday and DOMjudge generally ran very well. There were just a couple of instances where a judgedaemon halted, generally after reporting that the chroot environment still had processes running when it was being stopped. I made sure the daemon was stopped, restarted it, and it seemed to recover properly in each case.
This often happens when the apport service is running on the system.
On 15-11-15 23:11, Malcolm Corney wrote:
The Southern California regional contest was held yesterday and DOMjudge generally ran very well. There were just a couple of instances where a judgedaemon halted, generally after reporting that the chroot environment still had processes running when it was being stopped. I made sure the daemon was stopped, restarted it, and it seemed to recover properly in each case.
This often happens when the apport service is running on the system.
Ah, indeed, that's one known culprit on Ubuntu systems, see: https://www.domjudge.org/docs/admin-manual-8.html#ss8.8 I recall having seen this problem also infrequently in other cases, so I'd be interested to find out if the cause can be determined. Jaap
participants (5)
-
Howard Cheng -
Jaap Eldering -
Malcolm Corney -
Marc Furon -
Tobias Werth