Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Asset Management #11

Open
flwyd opened this issue Feb 9, 2013 · 0 comments
Open

Asset Management #11

flwyd opened this issue Feb 9, 2013 · 0 comments

Comments

@flwyd
Copy link
Member

flwyd commented Feb 9, 2013

Create model, controller, and basic views for asset management. Focus on RESTful activities; requirements for advanced asset handling and streamlined UI haven't yet been gathered.

An Asset represents an object tracked by HQ during operations. Assets include radios (the most numerous asset and the most frequently handled), vehicles (limited in number, high value), bikes (used by Intercept), and keys to various buildings. Some Assets (radios and vehicles) require Authorization, typically handled operationally as a signed form. Radios have optional add-ons: shoulder mic, headset, surveillance kit (CIA style), helicopter headset. Amber lights might be a vehicle add-on or they might be a separate asset type. Assets are tied to an Event.

Data model:

  • Asset
    • type (Radio, Vehicle, Bicycle...)
    • belongs_to Event
    • name (e.g., "C-17" for a truck, "2516" for a radio)
    • assignment_type (permanent vs. temporary)
    • note (e.g. type of vehicle, radio that doesn't work with attachments)
    • has_many AssetAssignments
  • Radio, Vehicle is-a Asset
    • Validates uniqueness of (event, name)
    • Requires authorization
  • Bicycle, BuildingKey, DeepFreeze(?), MiscAsset(?)
    • Don't require authorization
    • Might not enforce name uniqueness
  • AssetAuthorization
    • asset_type
    • belongs_to Event
    • belongs_to Involvement (each person must renew authorizations each year)
    • authorized_by (which User made the authorization)
    • revoked (if true, this person can't check out this asset type any more)
    • revoked_by
  • AssetAssignment
    • belongs_to Asset
    • belongs_to Involvement
    • checked_out (Timestamp, not nullable)
    • checked_in (Timestamp, nullable)
    • checked_out_by (User, not nullable)
    • checked_in_by (User, nullable)
    • add_on (for radios)
    • note (e.g., "Returned broken" or "Needs oil change")

Start with REST/resourceful views which treat all asset types equally. Allow check in and check out. On an asset's page, show its assignment history. AssetAssignment should show only checked-out assets by default, maybe an option to show the whole assignment history for the event.

A future task will go into optimized workflow for radio and vehicle checkout and checkin.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant