Participant Links

[lostcarpark]

Not sure whether this should be a discussion or an Issue, but Discussion might be good for general chat, so lets try that.

I would like to work on a Links section added to the "My Profile" page.

It has been suggested in the past that survey is adequate for this, but for me it fails in a couple of ways:

• There is insufficient validation.
• People are inconsistent in the way people format items. I've seen Twitter links formatted as username, with or without the @, and as URLs, with or without https prefix.
• Sometimes people want multiple links, and if you give them a free text field, they will enter multiple values.
• The Survey questions won't have consistent IDs, making it difficult to link up questions to an extract for KonOpas/ConClár.

I would like to resolve these issues by having dedicated links in profile.

Some requirements that spring to mind are:

• Support common link types. The minimum would be website, Facebook, Twitter. Others that could be considered include LinkedIn, Instagram, GoodReads. Feel free to remind me of ones I've forgotten.
• Make it clear what format is expected for each link type.
• Have strict validation, only allowing characters that are permitted for the specific link type.
• Only allow one value in a link.
• Allow multiple links of each type. If participants want to list 3 different websites, allow them, just ensure they enter each one as a separate link.

Internally, I think we should avoid having link fields on the Participants table, and add a new ParticipantLinks table, which would store, at a minimum the following:

• Link ID - a unique identifier for the link.
• Badge ID to link to the participant.
• Link Type - this could possibly be a foreign key to a LinkTypes table.
• Link Value - this would vary for the link type. It might be a URL for a website link, but just be a username for a Twitter link.
• Link Description - Description for websites. Might be more limited for other links.
• Probably some stuff to track updates.

[bcholmes]

I'm on board with that. In our current mobile app, we present a set of links associated with a participant's bio, like so:

In past cons, I've gone through people's bios and scraped all the links that folks have referenced in their bios to assemble that list of links; I'd love to give folks the ability to manage their own links so that I can skip that "data harvesting" exercise.

As I said in the Discussions area, I think we might want to give a little bit of thought to possible problematic cases. Should we prevent someone from linking to their OnlyFans, for example?

[lostcarpark]

That looks pretty slick! I was thinking something not dissimilar for ConClár.
I do think a certain amount of curation of people's links is required by the convention staff. I have to assume participant bios get reviewed, for example.
It would, of course be possible to have a "BannedLinks" table that links were checked against, but that might be overkill, and it seems simpler to just review links.

[lostcarpark]

Another thing I think would be useful, but not on the critical path, would be some JavaScript that checks links as they are entered, and displays the website title or account name, or a warning if the site returns a 404.

[bcholmes]

Another thing I've given a lot of thought to: at WisCon (and this is probably true of a lot of sff cons), many folks on panels want to have a way to link to their (most recent, or whatever) books. It's pretty tempting to drop in links to Amazon, but I confess that I've kind of avoided that because... well... Amazon. In the WisCon mobile app, I've tended to link to books on IndieBound.org, but that site often misses smaller presses and especially non-American presses.

[lostcarpark]

That is a good idea! I will admit at Octocon we've blatantly put Amazon Associate links on the website to make the con a little extra money.
It would be great to have it able to display the book cover images.
Ideally it should not be too tightly tied to any one bookseller, though fetching book covers would generally require calling an API.

[LVerhulst4321]

I like the idea of participant links. Multiple links of the same type even. And validation of them? That would be even better!

So many great ideas!

[bcholmes]

Any thoughts about timelines? (I'm basically wondering if this feature will be in place in time for me to steal it for this year's WisCon in late May).

[lostcarpark]

I've been tinkering with it, but I'm not going to be able to get as much time to work on it as I'd like until after Eastercon.
I would hope to have something viable in late April/early May.

[LVerhulst4321]

So, how much, if any, work have you done on this James? I would like to get participant links added for Capricon use.

How about I make a branch for this and we start work there? Any PRs for this issue should reference the branch.

[LVerhulst4321]

I added a change to the ParticipantLinks branch that would create 2 tables. I wasn't sure if I should make a PR for this yet. Can someone take a look at let me know what you think? Thanks.

[lostcarpark]

I've done a bit of work since I created the branch. I have a couple of hours to work on it this morning, so I'll check in my changes before I go.

[lostcarpark]

Not sure if you based your branch on the ParticipantLinks branch in my fork. Mine creates very similar tables, but not quite the same.

[LVerhulst4321]

LOL I should have looked at your fork to see if you had anything out there. I did not. I created the tables independently, but based on your original discussion message above.

[LVerhulst4321]

I liked your tables much better than mine, so I wiped my update file and grabbed yours.

I found a typo in the insert into permissions statement. The ce table should be singular to match the permission atom.

I would also like to propose changing the 'updated_date" field to actually be a timestamp and use this:
updated_date TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,

Maybe change the field name to 'updated_ts'

[lostcarpark]

Latest check-in to my ParticipantLinks branch has basic framework of React component for link editing, but it doesn't do anything useful yet.
I'm going to work on API stuff next

[LVerhulst4321]

Cool! I'll take a look!

[LVerhulst4321]

I can work on code to add the link_type table to the edit configuration tables code. I think it should be added to the Participant section.

[lostcarpark]

That sounds like a good idea.
Sorry for the late reply. I had hoped to work on it last night, but we got trapped at my Mum's house by a storm, and annoyingly I hadn't brought my laptop.
Back on it tonight.

[lostcarpark]

One thought: should we have an approval screen for links? Links attached to participants can potentially carry content that a convention might not want to be associated with. I could see circumstances where a participant might add links that the convention might consider inappropriate. This could be either malicious on the part of the participant, or unintentional, or they could be duped into sharing a link by a 3rd party.

It might be useful to have a page that lists links awaiting approval, and the participants they belong to.

I'm thinking of adding an is_approved flag to the participant_link table to facilitate this screen, even if it doesn't get added immediately.

[LVerhulst4321]

At minimum, I want to add the participant links to the Administer Participant page (AdminParticipants.php) so that staff can review them and edit them just like they can review and edit the participant bio.

Adding a way for staff to approve links (and bio!) before they are visible, would be a good future project, I think.

[lostcarpark]

Agreed. My intent is to have the same link editing on the participant Profile page and on the staff Participants->Administer. On the Administer one, I still need for figure out how we get the badgeid of the user being edited into the React app.

I could see a case for an Approvals screen that is a combined place for approving bios, links, photos and whatever else.

I've noticed that the current Participant Photos tends to get ignored a lot of the time, and at least one convention I had to remind they had about half of their participant photos awaiting approval a couple of days before the convention.

For now, I'll add a is_approved flag to the table, and worry about how we actually carry out approvals when the main functionality is a little further along.

[lostcarpark]

I have very rudimentary link editing and saving working. It currently loads links, lets you select link type and edit the link and save it.

I still need to add add and delete buttons so you can have more (or fewer) than 3 links.

I want to smooth off the rough edges a bit, but I hope to get a version pushed to my branch in the next day or two.

[LVerhulst4321]

Hi James. Have you made any progress on this link code?

[lostcarpark]

Hi,
Sorry for the delay. I have been making progress, but it's a little slower than I hoped. I had a committee meeting in the UK and a con in Poland over the last two weekends, and work has been busier than I hoped. Fortunately I have a bit more time now.
I have been perfecting the API calls, and improving the user interface.
I should be ready to share an initial version in the next day or two. It will probably need a couple of iterations before it's ready for end users, but hopefully in the next couple of weeks.

[LVerhulst4321]

No worries. Thanks for the update. :-)

[LVerhulst4321]

I added coded to my ParticipantLinks branch to allow the link_type table to be edited in the Configuration Tables section. I added it to the Participant config tables.