Look into the idea of several project folders on GDK

[K-Beicher]

Find out whether GDK would prefer one large folder with all analysis projects within, or they are ok with them being separate folders.

There may be a question about security and data access.

[K-Beicher]

Restriction of access to folders

https://genome.au.dk/docs/projects-and-accounting/#data-access-in-project-folders

[danielibsen]

Wouldnt it be best if we could have subfolders with data access for specific projects? That way we can link the subproject requests that are approved by the Publications Panel to a specific folder.

[lwjohnst86]

Yea, I think something like:

sdca-onlimit-study/
├── pilot-data/ # restricted access
├── data/ # main data, restricted access
└── subprojects/ # everyone has access?
    ├── analysis1/
    │   ├── data/ # subproject-specific data
    │   ├── docs/
    │   └── R/
    └── analysis2/
        ├── data/ # subproject-specific data
        ├── docs/
        └── R/

Might be very doable this way. Then code can also be shared easily between (should ideally use Git for tracking and sharing). And easier to manage and review the subprojects.

[lwjohnst86]

This is the documentation related to hiding folders in a project folder:

https://genome.au.dk/docs/projects-and-accounting/#data-access-in-project-folders

This is about assigning admin access:

https://genome.au.dk/docs/projects-and-accounting/#managing-a-project

And this is the PR that I added some explanation:

https://github.com/GenomeDK/genomedk-docs/pull/11/files

Me and Signe tested during the workshop that if I hide the folder from everyone, if she isn't an admin, she can't see the folder. But when I make her admin, she can see it. So that is one way of keeping all the analyses in the same folder, that only admin users can see the data.

Like I said, there are pros and cons to both. We only need one project folder and don't have to deal with managing two. But depends on what @danielibsen and others might want when it comes to analysing the data.

So the two options are:

1. Have one sdca-onlimit-study/ project folder with everything, both data and analysis projects.
2. Have a sdca-onlimit-study/ project folder with only the full dataset and a sdca-onlimit-study-analyses/ project folder with the analysis projects with data necessary for only a given project in each sub-folder.

In both cases, we would need to use gdk-project-promote-user to assign specific users to admin status (e.g. us and Daniel?). We would also need to add new analysis users to the project with gdk-project-add-user. We would need to also copy the relevant data into the analysis users folder regardless.

One project folder

This would involve using chmod to restrict access to the data folders (feasibility-data/ and data/) to only admin users.

The folder structure might look like would look like:

sdca-onlimit-study/
├── feasibility-data/ # restricted access, only admin
├── data/ # main data, restricted access, only admin
└── subprojects/ # everyone has access
    ├── analysis1/
    │   ├── data/ # subproject-specific data
    │   ├── docs/
    │   └── R/
    └── analysis2/
        ├── data/ # subproject-specific data
        ├── docs/
        └── R/

• Pros: Only one folder to manage and administrate.
• Cons: Need to use chmod two times (there's docs in GenomeDK about it), once for the feasibility-data/ and once for the data/.

Two project folders

This would be a project folder for data and for analyses.

It would look like:

sdca-onlimit-study/
├── feasibility-data/ 
└── data/
sdca-onlimit-study-analyses/
├── analysis1/
│   ├── data/ # subproject-specific data
│   ├── docs/
│   └── R/
└── analysis2/
    ├── data/ # subproject-specific data
    ├── docs/
    └── R/

• Pros: Don't need to use chmod.
• Cons: Need to use gdk-project-promote-user and gdk-project-add-user double for the admin group (e.g. us and Daniel), once for the data project folder and another time for the analysis project folder. Will need to manage two projects rather than one, so will need to be careful not to accidentally add a user to the wrong project folder.

Summary

Personally, I like less admin work than more, and the one project folder route has slightly less admin work. Having said that, both routes are realistically not a lot of work either way. So up to what the others want.