corresponding to resourceType / resourceTypeGeneral to indicate whether it is a Dataset, Software, Model, DataPaper, etc.

• Git version:
• Operating system: Lubuntu 16.04, Firefox 62.0

Committing after editing a file on the GIN webUI makes the webpage to refresh. However, it takes too long to actually refresh and report success.

It would be good if the Explore link in the header also indicated (perhaps with a magnifier icon) that it also provides the search functionality.

The pager in the explore section of the gin webpage keeps on going even if there are no more repositories listed resulting in a completely empty page.

Respective GIN issue: https://gin.g-node.org/G-Node/Info/issues/35

The current plan is to keep WebDAV access disabled while we work on bringing our fork up to date with upstream GOGS. The update will bring file content access through the web API which can serve similar purposes.

In the future, we may provide WebDAV access to repositories using a separate service.

Our git clone URLs, for the default port, are in the form:

[email protected]:/user/repo

This differs from most git services and also introduces some issues with git module linking on the web frontend.
I'd like to revert the change that caused this and slowly phase out supporting this form.

The references field in the datacite file should be more general with respect to the reference ID.

references:
    - 
       id: "xxxxxx"
       reftype: "IsSupplementTo"
       description: "Publication name or description"

The explanation text should explain that ID could be a DOI, URL, ISBN, arXiv, or PMID. They should be provided in the form type:ID e.g., doi:10.xxx/zzzz, pmid:xxxyyy, etc.

Update the validator in G-Node/gin-doi to accept this form.

Psychological simplification of data collaboration features.

Situation: When a researchers uses the GIN services and decides to share his/her data with others. Traditionally, other collaborators would be required to 1. Visit the GIN homepage 2. Create & verify an account. 3. Use GIN online or set it up locally. 4. Collaborate with the researcher.

Problem: This process is seen as tedious, as the researchers aims to minimise any potential hurdles for the collaboration with others.

Solution: Implement an 'Invite others via email' feature. The researcher can invite other collaborators via email. These will receive a link to the GIN data via email and are prompted with a log-in screen with their email already filled in as their username. What remains to do is only to decide and enter a password. After doing so, they are directly forwarded to the desired collaboration repository.

Advantages: This eliminates the first step of the situation and thereby a huge step of a potential psychological collaboration hurdle. The collaborator no longer needs to decide on whether or not he/she wants to sign up and collaborate. The decision is already made for them. It is only required to decide on a password. This solution therefore enhances collaboration without the risk or compromising security.

After PR #76 is merged, we'll be able to support repositories with multiple DOIs, so we should also make it easier for users to register new versions of already-registered repos.

The DOIfy button should still be hidden (or disabled) when the latest valid DOI matches the master commit though, so it should appear once the user makes changes to the repository.

• Red Warning
• Show the number

Its own test fails like this:

$ git annex init --debug       
...
[2018-09-26 11:53:56.198970849] Request {
  host                 = "web.gin.g-node.org"
  port                 = 443
  secure               = True
  requestHeaders       = [("Range","bytes=0-"),("Accept-Encoding","identity")]
  path                 = "/INT/multielectrode_grasp/config"
  queryString          = ""
  method               = "GET"
  proxy                = Nothing
  rawBody              = False
  redirectCount        = 10
  responseTimeout      = ResponseTimeoutDefault
  requestVersion       = HTTP/1.1
}

download failed: Not Found

I was recently talking to a professor about hosting the data of his lab on GIN. While discussing rights management, he opined that it would be good if all people added to an organization could create repositories in the organization. Without this, every time a lab member wants a new repository, either the professor or a designated lab member with admin rights would have to create a repository and set appropriate member rights for it. Currently, the only way to allow everyone to create repositories in the organization is to add everyone to the "Owners" team, which gives everyone admin rights to all repositories, which could lead to someone messing things up. If individual non-owner members could create repositories, they would get admin rights to the repository in addition to the owners of the organization. They can then continue to push and share the data of that repository without requiring the involvement of anybody else.

Following PR #88 the configuration and app.ini have been overhauled. We need to review our app.ini before deploying.

Make an email address lower case before comparing it against an email whitelist hash.

I am going through the https://web.gin.g-node.org/G-Node/Info/wiki/InHouseWithoutDocker . Thank you for the nice documentation -- it seems has worked out for me quite splendidly! Here I want to outline a few points which I have observed and which you might (or might not) want to address or just explain (decided not to separate into separate issues for now, added empty checkboxes to signal "something to address"). Some issues might relate more to upstream gogs .

• There is no default FAQ page (http://localhost:3000/G-Node/Info/wiki/FaqTroubleshooting gives 404 page)
• no options to initialize git-annex while creating a repo In above FAQ I was hoping to find on how to initialize "git annex" repository. I could not find an obvious setting somewhere while initializing a new repo or after to invoke "git annex init" on the server side. If such settings group existed (during creation) would be nice to be able to state desired backend for the annex (e.g. MD5) to partially mitigate those problems under windows. E.g. in datalad, by default, we just now use md5 backend:

$> datalad create /tmp/test; cat /tmp/test/.gitattributes
[INFO   ] Creating a new annex repo at /tmp/test 
create(ok): /tmp/test (dataset)                                                  
* annex.backend=MD5E

which should be sufficient for any scientific needs.

• incomplete ssh urls I have configured to not use builtin ssh. ssh urls provided by web interface "aren't complete" and rely on ssh account having entering the shell at the level of ~/gogs-repositories. I guess, whenever no internal ssh server is configured, I guess ssh urls need to be adjusted to reflect that . Anyways, I guess I better need to try the deployment with builtin ssh server, since I guess otherwise no multiple users would be able to push data
• http://... does not support git-annex I "git annex init"ed server side repo by adding an ssh remote, and letting git annex sync to init it, which doesn't work since

[Macaron] 2018-01-23 11:15:16: Started GET /yarikoptic/test1.git/config for [::1]
[Macaron] 2018-01-23 11:15:16: Completed GET /yarikoptic/test1.git/config 404 Not Found in 4.42299ms

i.e. git-annex trying to access that /config but it is not "interfaced" by the http/web interface. I wondered if it might become sufficient to make /config provided for git-annex so it could deduce uuid of that remote repo and request content straight via http?

I guess some of those issues are addressed via custom handling in gin cmdline client, but I thought it might be nice if GIN could work via native "git-annex" commands

If no objections, I will keep adding notes here as I go along. And please take those above points not as a critic of some kind, and just as my humble attempt on feedback to make GIN even better ;)

The issue will be closed without any reasons if it does not satisfy any of following requirements:

1. Please speak English.
2. Please ask questions or config/deploy problems to our gitter channel: https://gitter.im/gnode-gin/Lobby
3. Please take a moment to search that an issue doesn't already exist.
4. Please give all relevant information below for bug reports; incomplete details considered invalid report.

You MUST delete above content including this line before posting; too lazy to take this action considered invalid report.

• Git version:
• Operating system:

Description

...

When exploring a repository, having breadcrumbs somewhere at the top of the page can be help in keeping track of the current position in the folder structure of the repository and easy relative navigation.

When there is a (valid) datacite.yml but no README, the datacite info isn't rendered.

Provide per Repo access via access keys.
Probably via. system users with access to a single repository

Transferring ownership of a private repository from my personal account to another personal or organization account results in a 404 error. As result, the repository is neither in the sender's account nor the receiver's. Nonetheless, the Dashboard has an entry " username transfered repository username/repo_name to receiver/repo_name".
My application version is: 0.11.91.0811

Viewing an annexed file refers the user to
https://web.gin.g-node.org/G-Node/Info/wiki/Annexed+Files
which does not exist.

On local gin server, the entire G-Node/Info/wiki does not exist

fwd:

https://toolbox.google.com/datasetsearch

Is it possible to prepare the GIN repo pages or DOI landing pages to be included?

https://developers.google.com/search/docs/data-types/dataset

Best,
Thomas

Some settings such as CAPTCHA for viewing and downloading files (see below) doesn't map to any functionality any more and should be removed from the sample.

Introduced in 949813e, deploy keys don't work because the the git service returns an error when a key does not belong to a user:

Relevant issue on GIN: https://gin.g-node.org/G-Node/Info/issues/33

See https://gin.g-node.org/G-Node/Info/issues/38#issuecomment-635

With my datalad hat on, I find it very useful to know how many data files I do serve from http://datasets.datalad.org for any sub-directory/dataset -- thePROVIDED/TOTAL indicator in Size column. It would be nice if I could see in GIN/gogs also similar information -- currently I have no clue about total size of the dataset or for which subdirectories I did upload data (and for which forgot), see e.g. https://web.gin.g-node.org/yarikoptic/ds000001 and try to answer above question ;-)

Fall back to known README format when multiple readmes exist in the repository root but some of them aren't in a known format.

A zip function that reads annexed data already exists in libgin/archive. It might be possible to write the output of the zip function to the web response writer, feeding the data to the response without creating it on disk and without waiting for the zip to finish.

The downsides will be that the download can't be resumed on interruption and there's no way of knowing the final size beforehand, so no progress.

Add Team management API endpoints for repository owners. Currently, only site admins are allowed to create and assign organisation teams through the API.

Normally, I would add this upstream and merge down, but a current project requires this quite fast so we'll have to do it the other way around this time.

From https://gin.g-node.org/G-Node/Info/issues/31

G-Node settings don't have an option for "merge and squash" a pull request (only rebase or merge). I'd like to see this option, I find it very useful. Moreover, I'd make it default for merging the pull requests.

Upstream equivalent: gogs/gogs#3387

Opening the preview page of an annexed file on gin@home shows html/template: "repo/download" is undefined instead of a useful message or error.

If a git push is also followed by an upload of annexed data, any hooks that rely on annexed files being present will get triggered and then fail.

This is important for gin-valid, gin-proc, and the (upcoming) upload service for meta.g-node.org.

The top level sections for some public odml files are displayed twice.
Eg https://web.gin.g-node.org/INT/multielectrode_grasp/src/master/datasets/i140703-001.odml is displayed as

The upside of this is that keeping up to date with upstream is simpler, since it won't create merge conflicts. The downside is that if something changes in the upstream templates with respect to the information they have (variable name change, for instance), it will break our templates without warning.

One solution to the downside is to keep up to date with GOGS more regularly and follow the changes closely, instead of merging blindly.

We could also write tests that check if all pages render properly.

Basically to where the new page button is

The issue will be closed without any reasons if it does not satisfy any of following requirements:

1. Please speak English.
2. Please take a moment to search that an issue doesn't already exist.
3. Please give all relevant information below for bug reports; incomplete details considered invalid report.

yoh@hopa:~/gocode/src/github.com/G-Node/gogs> git show v0.11.34 | head
commit 6f2347fc71f17b5703a9b1f383a2d3451f88b741
Author: Unknwon <[email protected]>
Date:   Wed Nov 22 14:46:14 2017 -0500

    locale: sync from Crowdin
    
    Fixes #4811

diff --git a/conf/locale/locale_fr-FR.ini b/conf/locale/locale_fr-FR.ini
index c04c931c..4754f168 100644

yoh@hopa:~/gocode/src/github.com/G-Node/gogs> git describe --tags 
v0.11.19-187-ga37c1225

Previously we had a gin@home fork and container image that was modified for on-premise deployments of GIN. The modifications disabled features and UI elements that require extra (micro)services that we run ourselves:

• Data search (gindex)
• Dataset publication (gin-doi)

Maintaining a fork with these changes is cumbersome. Instead we should hide the UI elements (e.g., the Request DOI button) when the service is not configured.

When a page requires a login, the target page of a redirect still shows up in the address bar before a login, but the redirect is not resolved after the login is done.

ATM registered releases of the datasets get a DOI based landing page (like https://doi.gin.g-node.org/10.12751/g-node.70e11f/), which links to a dataset under https://gin.g-node.org/doi (like https://gin.g-node.org/doi/AIDA_dataset), which is a fork of the original dataset (like https://gin.g-node.org/pallastn/AIDA_dataset). But neither in the original dataset or the one under doi/, there is a tag for that specific DOI. I wondered if it is just that nobody thought to add it yet, or there is some tech limitations of bogs etc? At least locally git would be happy to tag with that DOI, e.g.

$> git tag -m "describe the release/DOI'ed version" 10.12751/g-node.70e11f doi/master

$> git describe master
10.12751/g-node.70e11f-11-geb9ce5c

I think that the download button for the repo should actually download the full repository with the annex data. Currently it seems to only download the repo with the linkers to the file, and I can't find any way to download the full content without going file by file.

An example of this that we did recently is the repository header (see PRs #78 and #81), where we created header_gin.tmpl and import it into header.tmpl

The template at templates/repo/view_file.tmpl in particular should be cleaned up.

Related to #60, but a different strategy. This approach might also be a good way to start towards implementing #60 at a later date.

Since PR #47 the API endpoints for search and suggest no longer work. The web search uses internal functions for searching and filtering with the user's cookie. The API endpoints should be rewritten to use access tokens and reuse functionality.