From af11754981f8c914130a606de2b3653d7b2a8e52 Mon Sep 17 00:00:00 2001 From: Arun Isaac Date: Tue, 14 Mar 2023 19:11:46 +0000 Subject: Add gmi extension to issue files without one. --- issues/add-collection-import | 13 ------------- issues/add-collection-import.gmi | 13 +++++++++++++ issues/adding-traits-from-mapping | 3 --- issues/adding-traits-from-mapping.gmi | 3 +++ issues/sample-data-caching-problem | 19 ------------------- issues/sample-data-caching-problem.gmi | 19 +++++++++++++++++++ issues/search-hyphen-issue | 3 --- issues/search-hyphen-issue.gmi | 3 +++ 8 files changed, 38 insertions(+), 38 deletions(-) delete mode 100644 issues/add-collection-import create mode 100644 issues/add-collection-import.gmi delete mode 100644 issues/adding-traits-from-mapping create mode 100644 issues/adding-traits-from-mapping.gmi delete mode 100644 issues/sample-data-caching-problem create mode 100644 issues/sample-data-caching-problem.gmi delete mode 100644 issues/search-hyphen-issue create mode 100644 issues/search-hyphen-issue.gmi diff --git a/issues/add-collection-import b/issues/add-collection-import deleted file mode 100644 index 90ce92d..0000000 --- a/issues/add-collection-import +++ /dev/null @@ -1,13 +0,0 @@ -## Add Collection Import/Export - -## Tags - -* assigned: zsloan -* type: bug -* priority: medium -* status: closed -* keywords: collections - -## Description - -One feature from GN1 that is still missing from GN2 is the ability to export/import collections (so they can be shared with other people). This is being added here https://github.com/genenetwork/genenetwork2/pull/701 diff --git a/issues/add-collection-import.gmi b/issues/add-collection-import.gmi new file mode 100644 index 0000000..90ce92d --- /dev/null +++ b/issues/add-collection-import.gmi @@ -0,0 +1,13 @@ +## Add Collection Import/Export + +## Tags + +* assigned: zsloan +* type: bug +* priority: medium +* status: closed +* keywords: collections + +## Description + +One feature from GN1 that is still missing from GN2 is the ability to export/import collections (so they can be shared with other people). This is being added here https://github.com/genenetwork/genenetwork2/pull/701 diff --git a/issues/adding-traits-from-mapping b/issues/adding-traits-from-mapping deleted file mode 100644 index d565b10..0000000 --- a/issues/adding-traits-from-mapping +++ /dev/null @@ -1,3 +0,0 @@ -There appears to be a bug where adding marker traits to a collection from the mapping results page isn't working properly. - -It might have something to do with HMAC creation, since I'm getting the "Data Tampering?" error, but not sure why yet. diff --git a/issues/adding-traits-from-mapping.gmi b/issues/adding-traits-from-mapping.gmi new file mode 100644 index 0000000..d565b10 --- /dev/null +++ b/issues/adding-traits-from-mapping.gmi @@ -0,0 +1,3 @@ +There appears to be a bug where adding marker traits to a collection from the mapping results page isn't working properly. + +It might have something to do with HMAC creation, since I'm getting the "Data Tampering?" error, but not sure why yet. diff --git a/issues/sample-data-caching-problem b/issues/sample-data-caching-problem deleted file mode 100644 index bf3078c..0000000 --- a/issues/sample-data-caching-problem +++ /dev/null @@ -1,19 +0,0 @@ - -# sample data caching bug - -When we cache sample data (mainly for features like correlations), it doesn't take into account changes in the sample list (which is derived from the .geno file). - -While this isn't frequently a problem, it was recently encountered with the BXD-Longevity group (which has had a number of recent changes to its .geno file, including changing the order of cases/samples, which basically rendered the cached sample data completely wrong) - -The fix to this is probably just to include the last updated time-stamp for the .geno file when caching. I'll probably do this in the next few days (maybe later today). - -The relevant caching code is here - https://github.com/genenetwork/genenetwork2/blob/2c22e593c59a9b4f9129a2e669443709d9c5154a/wqflask/base/data_set.py#L1288-L1317 - - -# Tags - -* assigned: zsloan,alex -* priority: medium -* type: bug -* status: open -* keywords: correlation,caching \ No newline at end of file diff --git a/issues/sample-data-caching-problem.gmi b/issues/sample-data-caching-problem.gmi new file mode 100644 index 0000000..bf3078c --- /dev/null +++ b/issues/sample-data-caching-problem.gmi @@ -0,0 +1,19 @@ + +# sample data caching bug + +When we cache sample data (mainly for features like correlations), it doesn't take into account changes in the sample list (which is derived from the .geno file). + +While this isn't frequently a problem, it was recently encountered with the BXD-Longevity group (which has had a number of recent changes to its .geno file, including changing the order of cases/samples, which basically rendered the cached sample data completely wrong) + +The fix to this is probably just to include the last updated time-stamp for the .geno file when caching. I'll probably do this in the next few days (maybe later today). + +The relevant caching code is here - https://github.com/genenetwork/genenetwork2/blob/2c22e593c59a9b4f9129a2e669443709d9c5154a/wqflask/base/data_set.py#L1288-L1317 + + +# Tags + +* assigned: zsloan,alex +* priority: medium +* type: bug +* status: open +* keywords: correlation,caching \ No newline at end of file diff --git a/issues/search-hyphen-issue b/issues/search-hyphen-issue deleted file mode 100644 index fc87adc..0000000 --- a/issues/search-hyphen-issue +++ /dev/null @@ -1,3 +0,0 @@ -Currently search terms involving hyphens don't work properly, because the hyphen is treated like a special character, with the characters to both sides of it being treated as separate terms. - -The regular expression in parser.py probably needs to be changed to account for this. diff --git a/issues/search-hyphen-issue.gmi b/issues/search-hyphen-issue.gmi new file mode 100644 index 0000000..fc87adc --- /dev/null +++ b/issues/search-hyphen-issue.gmi @@ -0,0 +1,3 @@ +Currently search terms involving hyphens don't work properly, because the hyphen is treated like a special character, with the characters to both sides of it being treated as separate terms. + +The regular expression in parser.py probably needs to be changed to account for this. -- cgit v1.2.3