- It is still possible to share histories without having a public
name. ( maybe rev 3255:ea652508497a doesn't catch all possible cases ? ) the shared history gets a URL of "http://localhost:8080/u//h/unnamed-history " (which gives a "404 not found").
No, a history has to have a public name to be shared. However I'm not sure that is the problem in this case. This history has the name "unnamed-history". Have you enabled import for this history?
- The URL of a shared history contains the name of the history as
the last part (e.g. "http://localhost:8080/u/gordon/h/unnamed- history"). But changing the history name (and unsharing + sharing again) does not update the URL. It will always use the original history name - very unfriendly if I publish first and then notice the bad name.
A fix for this is planned -- it will be possible to edit the identifier used in the URL for histories (and workflows, and pages) from the sharing management page.
- The opposite of 2: changing the "public user name" will cause a
change in the shared history's URL. Since there's nothing preventing users from changing their public names, the published URLs are very volatile. If some day I will want to change my public name from "Gordon" to "Dr. Gordon", all the URL that I've sent or published (except on the "published histories" page) will become invalid (come to think about, the "Dr." part will never happen, so it's not critical (: ).
I don't think that preventing people from ever changing this is a reasonable option. However, we don't expect people to change the public username except in very special cases. We need to display a clear warning message that changing the public username will break all stable urls.
- What stops a user from using somebody else's public name ? On my
local galaxy I was able to give the same public name to two different email accounts. Worse: I was able to create two accounts with the same public name, and have them both public histories with the same name. Both histories got the same URL, and both appeared in the "published histories" view (but clicking on both got my to the same history). I'm not sure with public name take precedence, but if it's the last one set, then somebody can hijack all the published histories of a user by setting his public name to the other user's public name.
Definitely a bug, it should be checking the public usernames are unique.
- Taking items 2,3 and 4 together, I really dislike any public URL
system that relies on user changeable information. I think the previous way (of using a hashed history ID) was much more robust.
I think we can address these issues. You are right however that it *is* now possible for a user to change the url to a history. This is deliberate. There are a number of problems with the ID hashing approach we were using, primarily that ID stability relies of a secret key.
- Annotation feature:
I was able to set annotations) for histories, workflows and workflows-steps, but not view them anywhere. Maybe that's just an alpha feature.
Yes, it is, these and the following issues are being addressed. Thanks!