Hi all, trying out the latest and greatest, here are couple of minor UI issues. All were tried on a recent clone (upto rev 3315:ac6e08aed7d4), without any modifications (just "sh setup.sh" and "sh run.sh"). 1. 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"). 2. 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. 3. 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 (: ). 4. 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. 5. 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. 6. 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. but please note that I can put HTML code in the annotations, and it will be used without escaping/sanitzing. Example: create an empty history. Click on "Edit Tags and Annotation/Notes". Paste the following code in the annotation edit-box: <iframe src="http://cnn.com"></iframe> Press ENTER to save the annotation. The immediate refresh is probably done by AJAX or Javascript, so you see the HTML code. but click "refresh" and you'll see CNN inside an <iframe>. If you're going to display annotation/notes as part of published histories (where one user can publish his malicious history and other users will just view it without being able to block it) - it will be dangerous. 7. The "Edit Workflow Attributes" button is mis-placed on Firefox 3.0.6/Linux, see attached image. 8. Not UI issue, but still a bug: After uploading a wiggle file, I noticed a new file conversion option saying "Index Wiggle for Track Viewer" - obviously I clicked it ;) and got: Traceback (most recent call last): File "/home/gordon/temp/uitest/lib/galaxy/datatypes/converters/wiggle_to_array_tree_converter.py", line 8, in from bx.arrays.array_tree import * ImportError: No module named array_tree That's all for today, keep up the good work, -gordon
