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: [email protected] _______________________________________________ Soc-coordination mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/soc-coordination
