Sprint 1 Expectations

This sprint is about building out additional, high-value functionalities of your feature which involve writing to the database and serving another persona. Throughout this sprint, you should be following best practices on project management and documentation.

Expectation 1: Project Management & Documentation

Issues are kept up-to-date on project boards and closed out when completed. Changes are merged into stage exclusively via pull requests with meaningful code reviews. Commits merged into stage are descriptive following best practices of commit messages.

In addition to standard code documenting expectations (doc strings, etc.), in this sprint your team will need to make progress on documenting your feature.

In docs, your team will add a markdown file with your feature’s name, (e.g. student-organizations.md)

The doc should contain a well written:

Overview

• Short description of your feature, who it primarily serves, the value it provides to the community
• Description of its high-level functions.

Implementation Notes

• Description of database/entity-level representation of your feature
• Interesting design choices your team made (we choose to do X over Y, because…)

Development Concerns

• If a new developer wanted to start working on your feature, what kind of guidance or overview would you give them to get them started?
• What files would you point them at?
• Is there anything special they would need to do to get started?

Future Work

• What directions could this feature be taken in? Given more time, what would you hope was added or improved next?

Expectation 2: Project Standards Maintained

As discussed in Class 26 on March 22nd, Angular Material components are used anywhere there are inputs, tables, tabs, etc. If there is an Angular Material component that achieves what your user interfaces need, you should use it in the frontend rather than standard, or bespoke, native HTML controls.

Backend service classes should be tested using Pytest with mock data. Backend service classes and methods should be documented using docstrings following the Google Python Style Guide.

Stories merged in to stage should be of usable, production quality.

Expectation 3: Mutation Story

One user story should result in a change to the database’s state that is visible to at least one other persona. This story should be achievable by an interaction from the front-end (such as clicking a button, submitting a form, etc.).

Expectation 4: Admin-only Story

One user story should be possible only for a user with a specific administrative role for your feature, or root user, to perform. You are encouraged to put administrative features in the Admin tab visible to the root user and other admins, but if it makes more sense to have admin-only functionality directly within your feature itself, that is ok. This functionality should not be visible to users who do not have the correct role or permissions. You are encouraged to add a role and/or permissions to your feature to the reset data.

You are encouraged to add permissions to the staff role for your feature’s management in the dev_data script’s permissions.py.

For examples on how to check permissions in the backend, see examples such as the following two:

1. Listing users (in a paginated format) from the backend admin API. Notice the line where permission action of user.list on the resource of user/ is enforced.
2. Updating a user’s profile is a service method that has feature specific logic. A user is able to update their own profile. An admin with permission to update the user’s resource is also able to. Form a service method’s perspective, you can see how this style of access control logic is idiomatically implemented in the source.

From the frontend, you will find administrative concerns in the app/admin directory. Additionally, you can see how to check admin permissions using the permission service as shown in the NavigationComponent. These permissions can be checked from the HTML templates. Feature-specific permissions, such as what someone who is registered for a workshop can do, will need to be enforced by your own feature code’s logic.

Expectation 5: Third Story

Complete one additional user story, separate from expectations #3 and #4, that your team believes is most important to the success of your feature.

Looking Ahead

Aiming above and beyond the minimum story expectations of this sprint is OK and can be used towards satisfying the requirements of the next sprint. Ultimately, your final project feature is going to need to have minimum viable functionality for basic administrative needs (listing, creating, updating, deleting, and managing entities) for your feature, as well as the stories important to students using your feature from the frontend.