Add related URL label for Oral History Collection

[yonyitz]

Within Oral History Collection (https://digital.sciencehistory.org/collections/gt54kn818) please update "Related URL" to read "View Oral History catalog" instead.

[eddierubeiz]

@yonyitz -- let's discuss this on Monday. I think this is a great idea, but it might be worth broadening the scope of this to include more than collections. Also, I'm pretty sure there are other related feature requests which we might want to consider before starting work.

[yonyitz]

Sounds like a plan! Thanks!

[jrochkind]

@yonyitz Thanks for filing the issue, filing an issue is always good and fine!

@eddierubeiz I'm trying to keep us to a general procedure of not dropping whatever we're working on to look at every issue that gets filed -- and not needing to talk on Monday about every issue that gets filed either -- but instead relying on @HKativa to prioritize issues and decide when/if we should talk about/plan/implement them.

I think that's what keeps us sane as a development team -- not always interupting our work for everything new that comes in -- as well as ensures we are spending our time on what brings business value to the organization.

I see this one has been marked with a "please triage" label, which is great, probably useful to @HKativa and @yonyitz in keeping track of issues that haven't yet been brought to the table. Which is great.

[eddierubeiz]

Duly noted!

[HKativa]

Just following up on the thread above: per a conversation with @jrochkind re Github prioritization and workflow, I've asked @yonyitz to file any issues in "backlog" and label them "please triage." I'll regularly review both the "prioritized work" and "backlog" milestones and prioritize/move issues accordingly. As confirmed with @jrochkind, the development team will continue to actively work off of issues in the "prioritized work" milestone, which should match up with what we discuss in our weekly meeting.

[jrochkind]

We will plan to do this based on re-using the HTML-enabled description fields we have for items.

This code "sanitizes" HTML to only allow certain tags, on both form editing, and on display (to be double extra safe). The code used for items can be re-used for Collections.

[HKativa]

As discussed at the Tech check-in on 11/12/18, this issue specifically applies to the Collections form and desire to provide added context when linking to the homepage of the oral history microsite. See #1184 for related issue involving adding more context/description when linking to individual oral histories on Works form.

[yonyitz]

I'm reopening this after a conversation with Hillary and Eddie about enabling target="_blank" for collection descriptions so users aren't taken away from our site right away. Thanks for working on this, @eddierubeiz !

[eddierubeiz]

Yup! No problem at all; not a big change.

[eddierubeiz]

Per discussions on Slack, we're amending how we want this to work: For both collection description and item description, all links, regardless of where they point to, shall be automatically decorated with a target-"_blank" attribute.

Practically speaking, all link attributes will be stripped on the way into the database; the HTML will be decorated with the target attribute on the way out, just before the description is shown to the user.

[eddierubeiz]

I need a bit more guidance; we should discuss:

• the automatic process that turns bare URLS typed into the description into links
• the little blue "new window" icon (an arrow inside a square <span class="glyphicon glyphicon-new-window"></span>) that gets added to links thus created.

Should we keep either or both of these features? If so, for what class of URLs ?

[jrochkind]

Me and @eddierubeiz had a brief chat about above.

I had forgotten or not known about that existing functionality, nice find. Looking at it, I believe that existing functionality just came with sufia, and we've always had it but maybe never known or paid attention to having it.

The existing functionality automatically makes a link of a bare URL you include in a description, like if you just write http://example.com. Actually just like github does: http://example.com . As you can see there, it's a linked URL as text, but doesn't let you specify the text that should appear on screen, it's just the URL.

So the existing functionality doesn't meet the current requirements given here (with target blank, and the assumption of specifying the on-screen link text) -- we have to implement new functionality anyway, as a separate thing.

I don't think we need to add additional work by changing the existing func, which came from sufia -- it's probably fine just to leave it there, rather than adding more work to remove it, since it doesn't interfere with the new func.