In your project folder, run:

./run

This will start a server for the frontend and a server for the backend.

• 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.

Rather than re-invent the wheel, UNSW has decided that it finds the functionality of Slack to be nearly exactly what it needs. For this reason, UNSW has contracted out Rayden Pty Ltd (a small software business run by Rob and 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 slackr.

Rayden Pty Ltd has sub-contracted two software firms:

• BananaPie 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 19T3), who will build the backend python server and possibly assist in the GUI later in the project

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

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

Rayden 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 front end 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

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

1. Ability to login, register if not logged in, and log out
2. Ability to reset password if forgotten it
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 privileges: (MEMBER, ADMIN, OWNER)
11. Ability to begin a "standup", which is a 15 minute period where users can send messages that at the end of the period will automatically be collated and summarised to all users

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.

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, you can check if a token is valid, and determine the user ID.

If you return the following from a route, the frontend will successfully display the error as intended.

dumps({
    "code": 400,
    "name": "ValueError",
    "message": "This is the text displayed",
})

You should create your own custom ValueError (differnet from the built in type) and AccessError and use the sample code myexcept.py to see how you can program flask to automatically handle and send back all ValueErrors and AccessErrors caught.

Note: For this to work successfully, you'll need to import these errors in any file that throws errors, or any pytest file that catches these errors

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)

• Members in a channel have two permissions.
  1. Owner of the channel (the person who created it, and whoever else that creator adds)
  2. Members of the channel
• Slackr user's have three permissions
  1. Owners, which have the same privileges as an admin (permission_id 1), except they can also modify other owners' permissions.
  2. Admins, who have special permissions that members don't (permission_id 2), including modifying other admins' permissions.
  3. Members, who do not have any special permissions (permission_id 3)
• All slackr members are by default members, except for the very first user who signs up, who is an owner

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

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

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 all functions except auth_register, auth_login
• Error thrown when token passed in is not a valid token

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. Most 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 }