Allow user to search by task name

See Richard's follow-up. https://einsteinathome.org/content/implement-find-task-name#comment-168175

Oliver Behnke Is there a way the client would know the task id (result id)? Or is he correct that the id is server-side only?

I think we discussed that the technical implementation of such a search is easy: it is just a SQL SELECT. But that there may be externalities to having such a database search on our Web site. But what if the form was only available to logged-in users and had a re-CAPTCHA on it?

If you mean the BOINC client, not the website or user, then no. The client references WUs, tasks and file via their unique respective names, not our internal DB record IDs.

Should we go ahead and provide such a search facility, I think it must ensure the following:

• Use the replica DB only to avoid stressing the master
• Ensure the task name is indexed
• Allow equality searches only, incl. case (don't use lower() as MariaDB doesn't support function-based indexes)
• Ensure bullet-proof escaping/sanitization to prevent SQL-injections
• Make it available only to logged-in users and protected by a captcha to curb scripted access
• Respect user's privacy settings: don't return task details belonging to hidden computers, not even stripped-down details as this explicit stripping will eventually fail (due to an error in change management)
  • This is going to hurt performance as we need to join the result and user tables to filter on user.show_hosts = 0
    • user.show_hosts needs an index
    • We should probably provide a view that abstracts all of this
  • Alternatively: don't filter on user.show_hosts = 0 as this will allow us to return a message saying that the task is hidden, as opposed to simply not found - do we want that?
  • Which columns do we want to show of a returned task?
    • If the requesting user is the task owner...?
    • If the requesting user is someone else...?

To be continued...

Another data point: our Drupal page layout doesn't use BOINC's original unconstrained table because we wanted to be mobile friendly. Thus we constrain our tables to a digestible width, on purpose. Therefor we had to decide which columns to show and which to drop. The task ID, as opposed to its name, was one of them. Everyone still wondering what our internal DB record ID is, for what reason ever, can still hover over the link to it.

Respect user's privacy settings: don't return task details belonging to hidden computers, not even stripped-down details as this explicit stripping will eventually fail (due to an error in change management)

I believe one of the reasons our advanced volunteers, who help other users, are requesting this feature is because they want to be able to search for a task/result when a user has show_hosts=0, which is of course the default. The idea being the user pastes the output logs, which contain the task/result name and then the helper can search for it. If we choose to hide a user's tasks based on their {{user.show_hosts} flag, then this will make the search less useful, and perhaps eliminating the raison d'etre of this search feature.

I believe Richard wrote about a second use case for the task search, the 'anonymous' accounts/hosts that Science United creates have no way of determining user or host information. But since the task name is given to the users' BOINC client, he can search for the task name.

Does this justify us adding this new search feature? My answer would be no: if you can only search for users with show_hosts=1, there seems to be little point because there is already a way for people to know about their own tasks. I don't see the benefit of having users search for other users' tasks unless there is a troubleshooting question, which would require them toggling the show_hosts flag; but then you can search through a users' host to troubleshoot; i.e., the task search wouldn't add much.

I guess my point boils down to: If a (above proposed) task search respects show_hosts flag, what are its use cases?