charlesjhill / ucbearcatbandsapp Goto Github PK

We don't yet have this functionality exposed anywhere in the frontend, but our backend supports linking assets to a PuchaseInfo object which records information like date, cost, vendor, invoice number, etc.

When you add an instrument to the application, and especially new instruments, we should prompt the user to optionally supply this information. One way to model this information could be using the Material Stepper component, which would also allow for splitting information up among several pages.

When an instrument is only assigned to one person, it appears like Test Student, and with multiple assignments, it appears as Test Student, Extra Person,. This is a quick hack that enables us to display multiple assignees with a spacer between entries, but it does look pretty weird when there is only one entry or the last entry has a comma.

The current database schema involves a one-to-one relationship between Asset and PurchaseInfo and many-to-one relationship with MaintenanceReport to Asset. The logic here is that each asset cannot be purchased more than once, but an asset can be maintenanced more many time.

This schema is defective however. In both cases, an invoice can surely be for multiple assets at once. If you purchase 10 Tubas, you will have 10 assets each with the same PurchaseInfo object associated with. As such, similarly you might send many things into the shop at once for repair. Therefore, it makes sense to move these relationships over to a FK on Asset for PurchaseInfo, and a Many-To-Many on MaintenanceReport to Asset.

Per guidance on the Django docs, the ManyToManyField should be on the model whom you'll be interacting with in the form. In my design ideas, typically you add a maintenance report to an instrument, but a more reasonable workflow is probably the opposite: A staff member gets the receipt, then punches it in the system in one place.

The Issue

The model can't handle per-asset information. An invoice records the price for the entire transaction, but not the price associated with each asset. With maintenance reports, you can write notes containing ALL the work performed, but that data cannot be delineated on a per-asset basis.

For purchases, the canonical solution would be to place the purchase price as a field of the asset itself, then the PurchaseInfo entity tracks the "total" price (computed) and shared data, like the date of purchase, receipt number, etc. However, I would be hesitant to say "purchase price" is a property of an asset speaking colloquially.

As for maintenance, it seems the solution is to introduce a "through" model to track the per item maintenance-performed and cost, the use the Maintenance object as the container.

Moving forward

For now, we'll be shifting the relationships as described in paragraph 2 above. However, deciding how we should handle the issue of per-asset knowledge in a receipt will need to occur before the application moves into production.

As far as I can tell, there is no way to remove an assignment from an enrollment? We really should.

Right now, there are two areas where one can assign things, so we should be able to unassign from those same places. These are the 'Assets' pages (Instruments, and Uniforms) and the 'Ensembles' page. We should especially be able to unassign from the latter.

For the assets pages, we could use chips with little a X on each one. For the ensembles page, we could do the same thing? I think that'd be pretty slick

Make sure can't assign to more than one student
Can only assign to an existing student.

It's pretty simple, there's a error message which popped up due to the server not running, and now there's no way to remove it.

Our students page currently is blank. This needs to display a table/list of students, along with each students information, such as:

• enrolled ensembles
• assigned assets
• locations of those assets

Use info gotten from Band Office, contact Chase or Erin for this.

Make sure can't assign to a non-existent user
Make sure can't assign to more than one user
Dropdown menu of student users?

At this point in time, our API endpoints remain open to whomever is interested and all verification happens on the client-side. This is vulnerable to really simple exploits that would allow more tech-savvy members of the band to do whatever they want. This should be rectified by adding server-side authorization of users to all our views.

To accomplish this, we can add permission classes to our API Views; the rough idea though is to create some custom permissions that check if a user has the is_student flag set to false or has the is_staff flag set to true, and if so allows access.

The following tables would benefit from a search bar for filtering:

• Instruments
• Uniforms
• Ensembles/Details

Currently, the only way to view the locker of an asset is through the ensembles page. It should be possible to view the locker of an instrument (for example) without going through the ensembles page. We have two options of doing this:

• Placing it directly in the table
  • We could allow users to specify what "extra" columns are visible?
• Tucking into the Details popup

Personally, I think the latter option makes more sense.

It would be desirable for an admin to directly view the contents of lockers outside of ensembles, just to see what is where and the combos for all the lockers. This should be created in addition to a StudentsDashboard page.

Such a feature would need to accomplish the following:

1. Some searchable/sortable list of all the lockers. It is unclear what a list item would look like, and it's also unclear what features it would nice to filter on
2. Each list item should contain the information about:
   • Locker Number
   • Locker Combination
   • List of Assets stored
3. The ability to add/remove assets from the locker

If we agree on these features, we need to ensure our API endpoints support said features. For example, to assign an asset to a locker, we need to modify the locker property of an asset to with the ID of the desired locker.

If the API supports all these features, we would need to create a locker service of sorts to handle pulling down the lockers, adding assets to the lockers, and so on. We'll also need to integrate the component into all the nav features.

In the top-left corner of the screen is a hamburger menu, regardless of the type of user logged in. If the user is admin, we expect the button to collapse the sidebar, but alas it doesn't do anything. If the user is a student, there is no sidebar to toggle. As such, this is really two separate issues.

The challenge with the current layout is that the sidenav element does provide a .toggle() method to collapse it, but it is difficult to propagate that callback upwards to the toolbar element.

As such, one solution could be to place the sidebar in the same "layer" as the toolbar, then hide it and the hamburger menu if the current user is a student (in the same way we hide the toolbar menu when no-one is logged in). This solution is complicated however by our usage of nested <router-outlet> tags to change components. If we place the sidenav in the same layer as the toolbar, we'd essentially be placing two separate <router-outlet> tags in the same component.

A second option is to create a service which has an observable indicating the current visibility of the sidenav, then allowing having the dashboard component subscribe to this observable.

A third option is simply to remove the hamburger menu from the toolbar and placing it in the sidenav component somewhere.

In a recent commit, 175ad6f, we added the ability to persist the currently expanded ensemble in the ensemble dashboard. This is done via an optional route parameter storing the currently selected ensemble's ID. This system appears to work when expanding an ensemble then collapsing it before opening another one.

The issue is that if one ensemble is selected, then another ensemble is selected without closing the previous one, the URL falls out of sync and ends in the "none selected" state, despite the newly opened ensemble being expanded on screen.

Example:

What should happen: The last step should have a url of /ensembles;selectedEnsemble=2

At this point, refreshing page causes all ensembles to be collapsed, since the URL doesn't record the CB being expanded.

The student page is kinda ugly, and I think it is for a couple of reasons;

1. There is no padding, so text appears on the edge of the screen
2. The text is just stacked on top of a depth-having accordian object, and that looks off.

Additionally, the page is just kinda barebones because its only features as of now are viewing ones ensembles and their assigned assets/locations. Finding additional features to "flesh out" the page could be good for making it seem more like a first-class citizen of thge app and less of an afterthought. For example, I can think of the following handy features off the the top of my head for this page:

1. Adding a ticket system to report asset maintenance.
2. Allowing students to view the details of their assigned assets

Per our demo in class today, we’ve discovered that not having the database act as a source-of-truth for available instrument kinds can be a bit of a problem, especially in our lovely strictly typed Swift app.

This should be pretty simple; we actually did something like this for AssetCondition under Assets already. For a fairly complete list of Instruments, both frontends should have them already somewhere. In the iOS app I’m pretty sure it’s under Instrument.swift.

_{Sent with GitHawk}