Making it possible to edit Sample Types that have Samples

[rabuono]

A recurrent request is to get the ability to edit an existing Sample Type even if there are Samples generated based on it.

Editing a Sample Type that has Samples however, can easily lead to Sample validation issues. The change in the Sample Type can make existing Samples not compliant (e.g. an optional Attribute is now marked as required).

Reasons to edit an existing Sample Type can be simple, to more complex.

• Mistakes like:
  • A misspelled word in Attribute title or description
  • Wrong Attribute PID
  • Wrong Attribute Type
• An optional Attribute should be a required one and vice versa
• Attributes are not sufficient and new ones should be added (optional and/or required)
• Attributes are wrong/redundant/unnecessary and should be removed

[rabuono]

The potential Sample validation issues can be complicated to solve if a Sample Type is used in multiple Projects.

In DataHub, Sample Types are only used in one Project and in one asset (a Sample Type is only used in a single Study or Assay). Because of this, resolving Sample validation issues that can come from editing a Sample Type becomes much simpler.

[stuzart]

a key principle of the Sample Types is that they are shared across projects to form a common standard, so restricting them to single projects I think would be a serious limitation. There are also cases where projects work together

[rabuono]

For sharing across Projects we have the Templates, which are essentially Sample Type Templates. Templates have sharing permissions and offer some other flexibility that Sample Types can't offer. We also keep track of which Template was used to generate a Sample Type, and thus Samples can be traced back to the original Template.
So the basic sharing of a common standard is kept, but with added flexibility.
One limitation we still have is that, after creation and Sample addition, one can't really edit a Sample Type anymore, even if there are mistakes in it.

[floradanna]

a key principle of the Sample Types is that they are shared across projects to form a common standard, so restricting them to single projects I think would be a serious limitation. There are also cases where projects work together

We had to restrict a Sample Type to a Study and/or to an Assay because the ISA model requires that all Samples in a Study and all Samples in an Assay MUST be described by the same set of attributes (in ISA, Study and Assay MUST have Samples and SOPs). On the contrary, in SEEK users can link Samples coming from different Sample Types to any Assay or not link any Samples at all. So, to be able to export an ISA-JSON we had to restrict Sample Types to Study and Assay.

We now have to figure out how to make this coexists with default SEEK Sample Type.

[floradanna]

Would it be possible to implement versioning in Sample Type?

[sslevine]

Within NExtSEEK, there are a couple of concepts that may be useful here:

• for sample types, we build them so there are a large number of fields expecting many of them to remain empty for many samples.
  -- example: DNA - a gDNA sample will have no value for DNA:index1 and DNA:index2 which would be used for NGS libraries (whether Illumina, Pacbio, ONT, etc).

• the corollary of this is we can add new fields to a sample type when needed for a new project (or expansion of an existing project). The older records simply do not have values for the new fields (which they presumably did not need).

• In NExtSEEK we also have a difference between a working space (pre-publication) and deposit space (eg Fairdomhub). The pre-publication space is, by definition, mutable. At deposition, we simply do not deposit the empty fields as they are immaterial.

[rabuono]

As discussed in the Samples Working Group, a strategy to have Sample and Sample Type versioning might be an important way to provide some of the extra flexibility discussed here.

For DataHub

For Samples:

Samples editing. Samples must have versions. Display:

• When a Sample was updated (already exists)
• By who at every update
• What’s changed: no time limit
• Restore any version. Restoring sample's version is limited to the current sample type version; to change to a new version of the sample type, first the sample type version need to be changed.
• New version created: when any value change is saved

Samples deletion.

• Inform User when a Sample is referenced elsewhere (Registered Sample) before deletion
• List the referencing Samples: greyed out if no access, sample name if access possible. Asking to confirm and continue deletion.
• Trashed Samples can be restored (“restore from the bin”)
• Adding a bin/trash step before complete deletion
• Instead of a 404 page, when a deleted Sample ID is accessed, show a “This Sample was deleted” message, including time of deletion and user who deleted.

[rabuono]

For DataHub:

For Sample Types.
Sample Type editing. Sample Types must have versions. Display:

• Sample Type creator and creation time
• When a Sample Type was updated
• By who at every update
• What’s changed: no time limit

New version:

• Changes to Sample Type description DO NOT lead to new version
• Changes to Sample Type Title lead to new version
• Changes to Attributes (name, type, description, PID, Unit, required, title) lead to new version
• Sample Type should have the same sharing permissions as the ones defined for the Study or Assay it is linked to. Relates to Hide sample types generated via single page from default view #1172

Sample Type deletion:

• Cannot be deleted if there are Samples Attached to them.
• If no Samples, can be deleted by users who have the correct permission level.
• Trashed Sample Types can be restored (“restore from the bin”)

Once a Sample Type is edited:

• The User should be offered the chance to migrate the Samples to conform with the new version of the Sample Type
• The User can decline the offer
• In the dynamic table, all Samples should follow the same Sample Type version

[rabuono]

Based on discussion created issues:

• Display Sample Type creator/submitter and creation date #1198
• Add sharing permissions to Sample Type #1199

[rabuono]

Added issues:

• Allow for addition of optional Attributes to existing Sample Types #1257
• Allow editing of Attributes in existing Sample Types #1258

[stuzart]

I've created a branch gh-pages-sample-updates for any sample documentation that needs adding or updating related to sample behaviour changes

[floradanna]

Hi all,

I was thinking that it could be necessary to apply sharing permissions to Controlled Vocabulary as well. Maybe the same as the Sample Type as default? Otherwise, although specific users will have defined permission on Sample Type, everyone will still be able to edit Controlled Vocabulary. Or will this not be the case?

Related to #54

[floradanna]

Editing association with Projects
Adding sharing permissions to Sample Type (ST) should be implemented in a way that does NOT change much the experience for the current users.

Note: currently, being able to View/download a ST mean being able to create samples in it. This seems to be an exception in SEEK, since Viewing a Study or an Assay does NOT mean being able to create assays in study, link samples or sop.

Sample type A (STA) is created and associated with Project1 (P1) and Project2 (P2);
All members of P1 and P2 can —> View, Download and Edit STA by default (same); No Manage rights.
P1 member creates 3 samples in STA, visible to P1 members. Even if samples are created in STA, members of P1 and P2 can still change projects associated with STA (same): P2 member then changes project association for STA by deleting association with P1. As a consequence, P1 members:

• Can still see the 3 samples → Viewers of samples linked to a ST get View/Download permission over the ST (same)
• Can still View STA via the link from the 3 samples → ST will be visible also via Browse (NEW!) to them
• Can Browse samples and then filter based on STA (same)
• Can still creates new samples in STA (same)
• If a linked sample is made public, the public can View/Download the ST (same)

The only issue I see so far is giving Managing rights over the ST to a user. This might change the current behaviour a lot, since a manager can:

• Revoke viewing rights from linked-samples viewers by making ST “No access”.