[Soc-coordination] [Package Tracking System rewrite] Week 12 - September 6 - Status Report

[Marko Lalic]

Hello,

The previous week went as planned with the following user stories
being implemented:

- Create a user account. There is a register link found in each page
which allows the user to register (only the email is required). Once
the user has confirmed the registration by clicking a URL sent in an
email, the account is activated.

- Log in. There is a log in link in each page, which the user can use
to authenticate with the system. After logging in, the user is
redirected to a profile page which offers access to all user-account
related features.

- List account subscriptions. Displays the list of all package
subscriptions the user is subscribed to. It is possible to see the
list of keywords for each subscription by opening a dropdown-style
"details" part of each subscription. This feature also already assumes
that users can have multiple emails associated with their accounts and
displays a list of subscriptions for each of the emails (if more than
one). These features are equivalent to using the ``which`` and
``keywords <package-name>`` email interface commands.

- Log out. After the log out, the user is redirected either to the
previous page if it is publicly accessible, or back to the home page
otherwise.

- Subscribe to a package. Two different ways are supported. The first
one is clicking a button found at the top of the package page. If the
user has only one email associated with the account, he is immediately
subscribed (no confirmation emails are required). If there are
multiple emails associated to the account, a popup is displayed
offering the user to choose which email he would like to use. The
other option is to subscribe via the subscriptions profile page by
providing a package name to a textbox (which supports autocompletion
for source and pseudo packages) and choosing which email(s) should be
subscribed to it. As expected, this is equivalent to the ``subscribe``
email control command.

- Unsubscribe from a package. Again, a few different options are
implemented. If the user is already subscribed to a package, in place
of a "subscribe" button, an "unsubscribe" button is placed allowing
him to unsubscribe all emails from the package with a single click.
Alternatively, in the subscriptions-list profile page, the user can
choose to remove individual subscriptions. Finally, there is a button
allowing the user to drop all subscriptions related to a particular
email. This is the equivalent of the ``unsubscribe`` and
``unsubscribeall`` email control commands.

- Change password and name. When changing the password, the user needs
to first enter the old password and then confirm the new one.

- Modify default and subscription-specific keywords for any of the
accounts associated emails. A popup is displayed which offers the user
to choose a new list of default/subscription-specific keywords.
Equivalent to the ``keywords`` command versions which modify the
keywords.

It is also worth mentioning that each feature which makes use of
Javascript has a fallback when JS is disabled. This usually means
taking the user to a dedicated page instead of displaying a popup or
fully refreshing the page after a form submit instead of an
asynchronous POST.

This is deployed on http://pts.debian.net. Bear in mind that
associating additional emails with the account is still not
implemented, so even though the features can work in that scenario,
this will be available to be tested after that story is done.

The largest part of the next week is reserved for stories regarding
creating PTS teams, something that has been in the wishlist for the
PTS for a long while. All planned stories are:

- Import old news to the test instance. A script which allows us to
import the existing news currently found in the PTS to the new
deployment.

- Create/delete/update a team. A team is associated to a set of
packages. The user that creates the team is considered the owner of
the team and can modify its visibility to other users
(public/private). He is also the only one that can update the team's
description fields.

- View/manage list of packages of the team. Each team has a URL
/team/<slug> which allows any member of the team to change the
associated packages. A notification is sent to the members of the team
after any such change.

- Join/leave a team. On a public team's page there is a "Join" button,
analogous to the subscribe button for packages. This button is
replaced with a "Leave" button in case the logged in user is already a
member of the team. In case the team is private, the owner has a
private form where he can add members by email.

- Receive updates for packages of the team. All members of the team
should receive package messages for packages that the team is
associated with.

- Manage a team subscription. The user can mute/unmute a the whole
subscription (while staying a member of the team) or only some
packages. He can also set a list of keywords for each package of the
team so that he only receives emails tagged with those keywords.

- View a list of teams the user is subscribed to. This is displayed in
the "subscriptions" profile page.

- View list of public teams. Allows browsing public teams so that a
user can discover teams he may be interested in. The list includes the
number of packages found in the team and the number of members of the
team, apart from the team's name.

- Email control commands related to teams. The functionality of
joining a team, leaving a team, listing a team's packages, listing all
teams, and listing all teams a user is subscribed to will be exposed
via corresponding email control interface commands.

This is it for another status report. Thank you for reading.

Cheers,
-- 
Marko Lalić

email: marko.lalic at gmail.com