Users

[timalces]

Add local users and user management.

• Users can be assigned to multiple projects (note: this differs from visualiser logic)
• Users can be one of three types (applies to all their projects):
  • Standard: can view their projects, make change requests and update policies
  • Viewer: can view their projects, but cannot carry out any actions
  • Admin: can view all projects and make all actions
• Users must sign in using a username and password
• Must have ability to sign out
• Users must only be able to view and make actions for their project(s)
• Users must have a way to navigate between their projects (i.e. project sidebar)
• Must have a rake task or similar for simple creation and management of users. No user sign up or password reset, etc. (at this stage)
• Usernames must be unique
• Passwords must not be stored as plaintext in the db
• Must be able to disable a user (but do not delete)

[VoxSecundus]

Some thoughts of mine on the implementation details here:

We have:

• 'Project' entities
  • A project represents a single cluster/set of cloud entities to be tracked
  • The entity owning the project is obfuscated; a customer could have multiple projects, each project with its own nodes, users and details
• 'Event' entities
  • An event is a scheduled action to be taken on a project; users can switch nodes on/off, change CPU utilisation switch-off thresholds
  • Are always scheduled for the future (wanting an event to be executed "now" schedules it for 5 minutes)
  • Event history/schedule is displayed on project page

We want:

• Users to belong to one or more projects
• Both 'local' users (non-SSO entities) and SSO users
• Users belonging to one or more projects
• Different permissions for 'standard', 'viewer', and 'admin' users
• Events to belong to one user (possibly make the events cancellable/editable by other users)
• Rake tasks for creation of local users (not sure how it would work for SSO yet)

Jack's Approach Thoughts :tm: :

• Local/SSO users are likely best implemented via single table inheritance as all that will change between the types are authentication approaches
• Would be a good idea to borrow Flight Hub's concept of 'user roles'
  • Most advantageous aspect of this is being able to set a user's roles on a project-by-project basis
  • Would also make more complex permissions possible in the future (Tim says this is likely to happen)
• I should liaise with Ben to make sure SSO cookie magic is approached in the right way
  • Implementation used in old visualiser was bad
• User stories would be extremely helpful; happy to do this myself or with Stu for some business-level thought process

[timalces]

Resolved by #17, #19 and #28