Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Supported by

Editing LabJS UUID for import to ensure overwriting existing study

LabJS appears to generate a unique UUID each time it exports files for importing as a package to JATOS. So the import always creates a new study when the intention is simply to update the existing one; with the associated data, links, etc.. This creates issues "downstream", in editing the MTurk file again, sharing links, and so on -- so it would be good to "force overwrite". I see advice in other posts about how to handle this: unzip, edit the UUID, rezip, import.

Question: Where to edit the UUID? In the .jas file, but editing only the toplevel one in the "data" list didn't do the trick. There are other UUIDs in this file in sublist -- are these to be edited as well? But they are all unique to each other. I also tried downloading the package from JATOS, replacing its .jas file into the new, edited package, after editing the filename to be identical to that in the package, but this also failed.

Thank you for any clarification and guidance.

Comments

  • UPDATE: I think I have a workaround -- to keep a copy of the .jas file from the original package created by labJS and for every new package, replace the new .jas file it creates with the original one -- and only then import that new package into JATOS.

    If you have any other suggestion, or can see issues with this workaround, please let me know.

  • Hi, I'm not terribly familiar with lab.js but yes, that would have been my suggestion too

  • unzip, edit the UUID, rezip, import

    This should work. I did it before. The .jas file is in JSON format (https://www.jatos.org/JATOS-Study-Archive-JZIP.html). The top/first UUID is the one from the study. The other UUIDs are from components or batches. I'm not sure if, for your purpose, you want to update them as well.

    When you import the altered .jzip (with the altered .jas) what fails, what's the error?

  • I should clarify -- the workaround I described in the "update" DID work -- substituting the original .jas generated with LabJS for the new ones it creates with each package, into that package, this has worked to no longer get a new study generated with each import, for each update; the "overwrite" function is available and the result is as intended. It was going the other way around--from JATOS export, using its .jas file as the one to replace the LabJS one with, and so on, that I got an error. But I only tried that once, and if it's supposed to work that way, too, I'm sure I must have mangled it some way. Thank you.

Sign In or Register to comment.