• 28-10: Adding password reset as routes not automatically auth checking
• 29-10: 6.1 section updated with corrected types

1. Aims
2. Overview
3. Iteration 1: Basic functionality and tests
4. Iteration 2: Not yet released
5. Iteration 3: Not yet released
6. Interface specifications
7. Due Dates and Weightings
8. Other Expectations
9. Plagiarism

• To provide students with hands on experience testing, developing, and maintaining a backend server in python.
• To develop students' problem solving skills in relation to the software development lifecycle.
• Learn to work effectively as part of a team by managing your project, planning, and allocation of responsibilities among the members of your team.
• Gain experience in collaborating through the use of a source control and other associated modern team-based tools.
• Apply appropriate design practices and methodologies in the development of their solution
• Develop an appreciation for product design and an intuition of how a typical customer will use a product.

To manage the transition from trimesters to hexamesters in 2020, UNSW has established a new focus on building an in-house digital collaboration and communication tool for groups and teams to support the high intensity learning environment.

Rather than re-invent the wheel, UNSW has decided that it finds the functionality of Flock to be nearly exactly what it needs. For this reason, UNSW has contracted out Pineapple Pty Ltd (a small software business run by Hayden) to build the new product. In UNSW's attempt to connect with the younger and more "hip" generation that fell in love with flickr, Tumblr, etc, they would like to call the new UNSW-based product flockr.

Pineapple Pty Ltd has sub-contracted two software firms:

• Catdog Pty Ltd (two software developers, Sally and Bob, who will build the initial web-based GUI)
• YourTeam Pty Ltd (a team of talented misfits completing COMP1531 in 20T3), who will build the backend python server and possibly assist in the GUI later in the project

In summary, UNSW contracts Pineapple Pty Ltd, who sub contracts:

• Catdog (Sally and Bob) for front end work
• YourTeam (you and others) for backend work

Pineapple Pty Ltd met with Sally and Bob (the front end development team) 2 weeks ago to brief them on this project. While you are still trying to get up to speed on the requirements of this project, Sally and Bob understand the requirements of the project very well.

Because of this they have already specified a common interface for the frontend and backend to operate on. This allows both parties to go off and do their own development and testing under the assumption that both parties comply will comply with the common interface. This is the interface you are required to use

Besides the information available in the interface that Sally and Bob provided, you have been told (so far) that the features of flockr that UNSW would like to see implemented include:

1. Ability to login, register if not registered, and log out
2. Ability to reset password if forgotten
3. Ability to see a list of channels
4. Ability to create a channel, join a channel, invite someone else to a channel, and leave a channel
5. Within a channel, ability to view all messages, view the members of the channel, and the details of the channel
6. Within a channel, ability to send a message now, or to send a message at a specified time in the future
7. Within a channel, ability to edit, remove, pin, unpin, react, or unreact to a message
8. Ability to view user anyone's user profile, and modify a user's own profile (name, email, handle, and profile photo)
9. Ability to search for messages based on a search string
10. Ability to modify a user's admin permissions: (MEMBER, OWNER)
11. Ability to begin a "standup", which is an X minute period where users can send messages that at the end of the period will automatically be collated and summarised to all users

The specific capabilities that need to be built for this project are described in the interface at the bottom. This is clearly a lot of features, but not all of them are to be implemented at once (see below)

Complete. Please see commit history to view old iteration info.

Complete. Please see commit history to view old iteration info.

Iteration 3 builds off all of the work you've completed in iteration 2.

If you haven't completed the implementations for iteration 2, you must complete them as part of this iteration. The automarks for iteration 3 will test on a fully completed interface - i.e. the work you've had to do for iteration 1, 2, 3.

In this iteration, you are expected to:

1. Implement and test the HTTP Flask server according to the entire interface provided in the specification, including features that were added in iteration 3, including:

   • message/sendlater
   • message/react
   • message/unreact
   • message/pin
   • message/unpin
   • /user/profile/uploadphoto
   • standup/start
   • standup/active
   • standup/send
   • auth/passwordreset/request
   • auth/passwordreset/reset

   Part of this section may be automarked.

   Pylint is assessed identical to that of iteration 2.

   Branch coverage for all .py files that aren't tests is assessed identical to that of iteration 2.

   You can structure your tests however you choose, as long as they are appended with _test.py.

   A frontend has been built by Sally & Bob that you can use in this iteration, and use your backend to power it (note: an incomplete backend will mean the frontend cannot work). You can, if you wish, make changes to the frontend code, but it is not required for this iteration. As part of this iteration it's required that your backend code can correctly power the frontend.

   You must comply with instructions laid out in 4.2

2. Continue demonstrating effective project management and effective git usage

   Part of this section may be automarked.

   You will be heavily marked for your use of thoughtful project management and use of git effectively. The degree to which your team works effectively will also be assessed.

3. Document the planning of new features.

   You are required to scope out 2-3 problems to solve for future iterations of flockr. You aren't required to build/code them, but you are required to go through SDLC steps of requirements analysis, conceptual modelling, and design.

   Full detail of this can be found in 5.3.

Continue working this project by making distinct "features". Each feature should add some meaningful functionality to the project, but still be as small as possible. You should aim to size features as the smallest amount of functionality that adds value without making the project more unstable. For each feature you should:

1. Create a new branch.
2. Write tests for that feature and commit them to the branch.
3. Implement that feature.
4. Make any changes to the tests such that they pass with the given implementation. You should not have to do a lot here. If you find that you are, you're not spending enough time on step 2.
5. Create a merge request for the branch.
6. Get someone in your team who did not work on the feature to review the merge request. When reviewing, not only should you ensure the new feature has tests that pass, but you should also check that the coverage percentage has not been significantly reduced.
7. Fix any issues identified in the review.
8. Merge the merge request into master.

For this project, a feature is typically sized somewhere between a single function, and a whole file of functions (e.g. auth.py). It is up to you and your team to decide what each feature is.

There is no requirement that each feature be implemented by only one person. In fact, we encourage you to work together closely on features, especially to help those who may still be coming to grips with python.

Please pay careful attention to the following:

Your tests, keep in mind the following:

• We want to see evidence that you wrote your tests before writing the implementation. As noted above, the commits containing your initial tests should appear before your implementation for every feature branch. If we don't see this evidence, we will assume you did not write your tests first and your mark will be reduced.
• You should have black-box tests for all tests required (i.e. testing each function/endpoint). However, you are also welcome to write whitebox unit tests in this iteration if you see that as important.
• Merging in merge requests with failing pipelines is very bad practice. Not only does this interfere with your teams ability to work on different features at the same time, and thus slow down development, it is something you will be penalised for in marking.
• Similarly, merging in branches with untested features is also very bad practice. We will assume, and you should too, that any code without tests does not work.
• Pushing directly to master is not possible for this repo. The only way to get code into master is via a merge request. If you discover you have a bug in master that got through testing, create a bugfix branch and merge that in via a merge request.

Software development is an iterative process - we're never truly finished. As we complete the development and testing of one feature, we're often then trying to understand the requirements and needs of our users to design the next set of features in our product.

For iteration 3 you are going to produce a short report in planning.pdf and place it in the repository. The contents of this report will be a simplified approach to understanding user problems, developing requirements, and doing some early designs.

N.B. If you don't know how to produce a PDF, you can easily make one in google docs and then export to PDF.

Find 2-3 people to interview as target users. Target users are people who currently use a tool like flockr, or intend to. Collect their name and email address.

Develop a series of questions to ask these target users to understand what problems they might have with teamwork-driven communication tools that are currently unsolved by flockr. Give these questions to your target users and record their answers.

Once you've elicited this information, it's time to consolidate it.

Take the responses from the elicitation and express these requirements as User Stories. Document these user stories. For each user story, add User Acceptance Criteria as notes so that you have a clear definition of when a story has been completed.

Once documented, generate at least one use case that attempts to tell a story of a solution that satifies the requirements elicited. You can generate a visual diagram or a more written-recipe style, as per lectures.

With your completed use case work, reach out to the 2-3 people you interviewed originally and inquire as to the extent to which these use cases would adequately describe the problem they're trying to solve. Ask them for a comment on this, and record their comments in the PDF.

Now that we've established our problem (described as requirements), it's time to think about our solution in terms of what capabilities would be necessary. You will specify these capabilities as HTTP endpoints, similar to what is described in 6.2. There is no minimum or maximum of what is needed - it will depend on what problem you're solving.

Now that you have a sense of the problem to solve, and what capabilities you will need to provide to solve it, add at least one state diagram to your PDF to show how the state of the application would change based on user actions. The aim of this diagram is how to a developer understand the different states the user or application.

For this and for all future milestones, you should consider the other expectations as outlined in section 8 below.

You are not required to store data persistently in this iteration. However, you are welcome to implement basic persistence if you find it convenient.

This iteration is due to be submitted at 8pm Sunday 15th November (week 9). You will then be demonstrating this in your week 10 lab. All team members must attend this lab session, or they will not receive a mark.

At the due date provided, we will automatically collect and submit the code that is on the master branch of your repository. If the deadline is approaching and you have features that are either untested or failing their tests, DO NOT MERGE IN THOSE MERGE REQUESTS. Your tutor will look at unmerged branches and may allocate some reduced marks for incomplete functionality, but master should only contain working code.

When you demonstrate this iteration in your week 10 lab, it will consist of a 15 minute Q&A in front of your tutorial class via zoom. Webcams are required to be on during this Q&A (your phone is a good alternative if your laptop/desktop doesn't have a webcam).

​ Hangman on Frontend ​ After a game of Hangman has been started any user in the channel can type /guess X where X is an individual letter. If that letter is contained in the word or phrase they're trying to guess, the app should indicate where it occurs. If it does not occur, more of the hangman is drawn. There is a lot of flexibility in how you achieve this. It can be done only by modifying the backend and relying on messages to communicate the state of the game (e.g. after making a guess, the "Hangman" posts a message with a drawing of the hangman in ASCII/emoji art). Alternatively you can modify the frontend, if you want to experiment with fancier graphics.

The app should use words and phrases from an external source, not just a small handful hardcoded into the app. One suitable source is /usr/share/dict/words available on Unix-based systems. Alternatively, the python wikiquote module is available via pip and can be used to retrieve quotes and phrases from Wikiquote.

Note that this part of the specification is deliberately open-ended. You're free to make your own creative choices in exactly how the game should work, as long as the end result is something that could be fairly described as Hangman. ​ admin/user/remove full implementation (frontend and backend) ​ admin/user/remove DELETE (token, u_id) {} ​ InputError when:u_id does not refer to a valid user AccessError whenThe authorised user is not an owner of the slackr ​ Given a User by their user ID, remove the user from the slackr. ​

​ Implementing persistence using a form of database. Ways to do this in python include: * Using the sqlite3 or peewee or psycopg2 modules to run SQL queries on a local .db file, for people studying/have studied COMP3311 may find this integrates well * Using the sqlite3 or peewee or psycopg2 to run SQL queries on a local .db file OR a remote database (using Postgresql or MySQL) ​

​ Refactor your code so it is stored in objects instead of dictionaries (if it's not already) and make use of OO concepts taught in lectures to pass data around the backend. ​

​ Deploying your project using heroku or something similar (not sure if this is possible/allowed)

These interface specifications come from Sally and Bob, who are building the frontend to the requirements set out below.

Either an InputError or AccessError is thrown when something goes wrong. All of these cases are listed in the Interface table.

One exception is that, even though it's not listed in the table, for all functions except auth/register, auth/login, auth/passwordreset/request and auth/passwordreset/reset, an AccessError is thrown when the token passed in is not a valid token.

Many of these functions (nearly all of them) need to be called from the perspective of a user who is logged in already. When calling these "authorised" functions, we need to know:

1. Which user is calling it
2. That the person who claims they are that user, is actually that user

We could solve this trivially by storing the user ID of the logged in user on the front end, and every time the front end (from Sally and Bob) calls your background, they just sent a user ID. This solves our first problem (1), but doesn't solve our second problem! Because someone could just "hack" the front end and change their user id and then log themselves in as someone else.

To solve this when a user logs in or registers the backend should return a "token" (an authorisation hash) that the front end will store and pass into most of your functions in future. When these "authorised" functions are called, those tokens returned from register/login will be passed into those functions, and from there you can check if a token is valid, and determine the user ID.

Passwords must be stored in an encrypted form, and tokens must use JWTs (or similar).

The behaviour in which channel_messages returns data is called pagination. It's a commonly used method when it comes to getting theoretially unbounded amounts of data from a server to display on a page in chunks. M0ost of the timelines you know and love - Facebook, Instagram, LinkedIn - do this.

For example, if we imagine a user with token "12345" is trying to read messages from channel with ID 6, and this channel has 124 messages in it, 3 calls from the client to the server would be made. These calls, and their corresponding return values would be:

• channel_messages("12345", 6, 0) => { [messages], 0, 50 }
• channel_messages("12345", 6, 50) => { [messages], 50, 100 }
• channel_messages("12345", 6, 100) => { [messages], 100, -1 }

• Members in a channel have one of two channel permissions.
  1. Owner of the channel (the person who created it, and whoever else that creator adds)
  2. Members of the channel
• Flockr users have two global permissions
  1. Owners (permission id 1), who can also modify other owners' permissions.
  2. Members (permission id 2), who do not have any special permissions
• All flockr users are members by default, except for the very first user who signs up, who is an owner

A user's primary permissions are their global permissions. Then the channel permissions are layered on top. For example:

• An owner of flockr has owner permissions in every channel they've joined
• A member of flockr is a member in channels they are not owners of
• A member of flockr is an owner in channels they are owners of

There is a SINGLE repository available for all students at https://gitlab.cse.unsw.edu.au/COMP1531/20T3/project-frontend. You can clone this frontend locally. The course notice said you will receive your own copy of this, however, that isn't necessary anymore since most groups will not modify the frontend repo. If you'd like to modify the frontend repo (i.e. teach yourself some frontend), please FORK the repository.

If you run the frontend at the same time as your flask server is running on the backend, then you can power the frontend via your backend.

A working example of the frontend can be used at http://flockr-unsw.herokuapp.com/

The data is reset daily, but you can use this link to play around and get a feel for how the application should behave.

For errors to be appropriately raised on the frontend, they must be raised by the following:

if True: # condition here
    raise InputError(description='Description of problem')

The descriptions will not be assessed, they are just there for the frontend to help users.

The types in error.py have been modified appropriately for you.

The only React ID currently associated with the frontend is React ID 1, which is a thumbs up. You are welcome to add more (this will require some frontend work)

Once standups are finished, all of the messages sent to standup/send are packaged together in one single message posted by the user who started the standup and sent as a message to the channel the standup was started in, timestamped at the moment the standup finished.

The structure of the packaged message is like this:

For example:

hayden: I ate a catfish
rob: I went to kmart
michelle: I ate a toaster
isaac: my catfish ate a toaster

Standups can be started on the frontend by typing "/standup X", where X is the number of seconds that the standup lasts for, into the message input and clicking send.

For outputs with data pertaining to a user, a profile_img_url is present. When images are uploaded for a user profile, after processing them you should store them on the server such that your server now locally has a copy of the cropped image of the original file linked. Then, the profile_img_url should be a URL to the server, such as http://localhost:5001/imgurl/adfnajnerkn23k4234.jpg (a unique url you generate).

Note: This is most likely the most challenging part of the project. Don't get lost in this, we would strongly recommend most teams complete this capability last.

• Each message should have it's own unique ID. I.E. No messages should share an ID with another message, even if that other message is in a different channel.

There is no late penalty, as we do not accept late submissions.

While it is up to you as a team to decide how work is distributed between you, for the purpose of assessment there are certain key criteria all members must.

• Code contribution
• Documentation contribution
• Usage of git/GitLab
• Attendance
• Peer assessment
• Academic conduct

The details of each of these is below.

While, in general, all team members will receive the same mark (a sum of the marks for each iteration), if you as an individual fail to meet these criteria your final project mark may be scaled down, most likely quite significantly.

During your lab class, in weeks without demonstrations (see below), you and your team will conduct a short stand-up in the presence of your tutor. Each member of the team will briefly state what they have done in the past week, what they intend to do over the next week, and what issues they faced or are currently facing. This is so your tutor, who is acting as a representative of the client, is kept informed of your progress. They will make note of your presence and may ask you to elaborate on the work you've done.

All team members must contribute code to the project. Tutors will assess the degree to which you have contributed by looking at your git history and analysing lines of code, number of commits, timing of commits, etc. If you contribute significantly less code than your team members, your work will be closely examined to determine what scaling needs to be applied.

All team members must contribute documentation to the project. Tutors will assess the degree to which you have contributed by looking at your git history but also asking questions (essentially interviewing you) during your demonstration.

Note that, contributing more documentation is not a substitute for not contributing code.

You will be required to complete a form in week 10 where you rate each team member's contribution to the project and leave any comments you have about them. Information on how you can access this form will be released closer to Week 10. Your other team members will not be able to see how you rated them or what comments you left.

If your team members give you a less than satisfactory rating, your contribution will be scrutinised and you may find your final mark scaled down.

It is generally assumed that all team members will be present at the demonstrations and at weekly check-ins. If you're absent for more than 80% of the weekly check-ins or any of the demonstrations, your mark may be scaled down.

If, due to exceptional circumstances, you are unable to attend your lab for a demonstration, inform your tutor as soon as you can so they can record your absence as planned.

The work you and your group submit must be your own work. Submission of work partially or completely derived from any other person or jointly written with any other person is not permitted. The penalties for such an offence may include negative marks, automatic failure of the course and possibly other academic discipline. Assignment submissions will be examined both automatically and manually for such submissions.

Relevant scholarship authorities will be informed if students holding scholarships are involved in an incident of plagiarism or other misconduct.

Do not provide or show your project work to any other person, except for your group and the teaching staff of COMP1531. If you knowingly provide or show your assignment work to another person for any reason, and work derived from it is submitted you may be penalized, even if the work was submitted without your knowledge or consent. This may apply even if your work is submitted by a third party unknown to you.

Note, you will not be penalized if your work has the potential to be taken without your consent or knowledge.