jquery/testswarm

Refactor users/clients relationship and add projects

Closed this issue · 3 comments

Krinkle commented

I talked about this with @jzaefferer on IRC the other day and it looks like the situation is suboptimal right now. Depending how one looks at it we're either:

  • Polluting the users table with unregistered guests
  • (ab)using users for what actually are "projects"

So I came to the conclusion that right now the only value to registering an account on a swarm is to be able to create jobs. However this ability is restricted to users who have been authorized to do so by having access to their authToken.

Change log for release notes

== Project system ==

The old situation lead to a user table containing a messy mix of
passwordless "client" accounts, unused accounts with passwords
from people using "signup", and "project" accounts that submit
jobs. This blurry distinction has been made strict now.
Nobody can sign up from the web anymore.
To join the swarm for test running, simply join directly
(which is how it was already), clients take a free form text
field as their "name", which doesn't have any account attached
to it (there is nothing clients can do other than run tests).
To create a "project" account for job submission, run the
manageProject.php script from the command line, which returns
the auth token (which you previously had to manually get from the db).

== Changes ==

Database:

  • Table 'projects' replaces old 'users' table.
  • Removed various SQL default attributes that were confusing
    and unneeded.
  • Removed foreign key restrictions.

API:

  • Query parameters for authentication changed from:
    • authUsername (users.name)
    • authToken (users.auth)
      to:
    • authID (projects.id)
    • authToken (projects.auth_token)
  • SignupAction: Removed, no longer used.

Pages:

  • ProjectPage: (NEW) Based on the "Recent jobs" section of UserPage.
    • New: Timestamp of each job.
    • New: Pagination.
  • ProjectsPage: Not changed much. Except that it can now really
    query all projects, instead of running a query against
    various tables and list all project-like user accounts.
    • New: Summary of latest job (a bit like Jenkins).
  • ClientsPage: (NEW) Shows online clients (sortable by name
    or latest ping, option to group by name).
  • ClientPage: (NEW) Information about a run client:
    • Browser info.
    • When it connected, last pinged.
    • Log of what it has done and/or is currently doing.
  • SignupPage: Removed, no longer used.
  • ScorePage: Removed, in favour of ClientsPage/mode=users.

Scripts

  • manageProject.php: (NEW) To create and alter projects in the
    database from the command line.

Misc:

  • Auth object is now managed inside TestSwarmContext (instead of
    being accessed globally directly from the session).
    This made it possible to fix #181, and cleaned up some duplication.
  • Fix various documentation comments for consistency
    • @param type $name
    • "authAction: Required"

References:

  • fixes #72: Implement ClientsAction (show online clients)
  • fixes #148: Refactor users/clients relationship and add projects
  • fixes #171: Add pagination to ProjectPage
  • fixes #181: Session continuation should validate that account
    still exists and is the same
  • fixes #248: Show status of latest job on ProjectsPage

== Migration log ==

  • SQL jobs.user_id > jobs.project_id
  • SQL client.user_id > (del)
  • SQL (new) > client.name
  • PHP UserAction > ProjectAction | ClientAction
  • PHP UserPage > ProjectPage | ClientPage
  • PHP SignupAction > manageProject.php | LoginAction
  • PHP SignupPage > (del) | scripts/manageProject.php
  • PHP ScoresAction > (del) | ClientsAction
  • PHP ScoresPage > (del) | ClientsPage
  • URL /user/$1 > /project/$1 | /client/$1
  • URL /signup > (del) | scripts/manageProject.php
  • URL /scores > (del) | /clients/?mode=users
  • API Project.userName > Project.info.display_title
  • API Job.ownerName > Job.projectID
  • API Job.creation > Job.created
  • API Job.name > Job.nameHtml | Job.nameText
  • API Projects.name > Projects.displayTitle
  • API Projects.jobCount > (del)
  • API User.recentJobs > Project.jobs
  • API User.uasInJobs > Project.userAgents
  • API User.recentJobs#url > Project.jobs#info.viewUrl
  • API User.recentJobs#uaSummary > Project.jobs#summaries
  • API Result.resultInfo > Result.info
  • API Result.client.userID > (del)
  • API Result.client.userName > Result.client.name
  • API Result.client.useragent > Result.client.uaRaw
  • API Result.client.userUrl > Result.client.viewUrl
  • JS SWARM.user > SWARM.auth

Original plan

Since there is no other use for an account, the idea is as follows:

  • Include "username" in clients
    • Update existing actions to no longer auto-create "users" rows and stuff. And ScoresAction to use clients.username instead of users.name (and add a note to ScoresPage that anyone can use any username (which is already the case, but oh well))
  • Drop the users table in favor of a projects table.
    • Drop SignupAction, SignupPage
    • Repurpose LoginAction and "session" variables to instead be for projectID and projectAuthToken.
    • Fix other db tables and Action classes to use the right fields
  • Create new projects table containing fields id, display_title, site_url, auth_token.
    For example:
    • id: jqueryui
    • display_title: jQuery UI
    • site_url: https://github.com/jquery/jquery-ui
  • Rename UserAction to ProjectAction, without the "active clients" section
    • While at it, add pagination (issue #65)
    • if site_url is not null, show a button link to that site
  • Write a script ./scripts/projectCreate.php that creates a new project, to be ran from the command-line with php
  • Implement ClientsAction (show online clients) with ClientsPage (issue #72). This page would show a table with usernames and active clients (layout similar to ScoresPages, except it only shows active clients and the second column showing browser boxes instead of scores)
jzaefferer commented

Also update URLs from /user/[username] to /project/[projectname]

Krinkle commented

updated initial post. I've started working on this a little bit locally. Will push a branch soon.

Hoping to get this into 1.0.0 so that we can save the trouble of db-migration (which will be an uneasy migration due to the foreign key restrictions to user IDs)

Krinkle commented

I plan to work on this during my 9-hour flight tomorrow. I'll push the branch at the end of the day.