Project

General

Profile

Actions

Feature #1060

open

Need store manager web UI

Added by Hammel 8 months ago. Updated 2 days ago.

Status:
In Progress
Priority:
Immediate
Assignee:
Target version:
Start date:
30 Oct 2023
Due date:
% Done:

90%

Estimated time:
Severity:
01 - Critical

Description

Although the touchscreen is useful for general drive data, it's not user-friendly for managing the stores.

Each store needs to be configurable with
  • Directories (add, remove, rename, write-enable, read-enable)
  • ACLs
  • Enable as PiSentry store
It should also display (but not configure)
  • Data usage per directory

Don't make it complex. Use simple CSS layout with few UI components.

Web server directly accesses mount points and makes changes, so it must run as root. Touchscreen UI should NOT access this metadata - only low level drive data should be displayed.

Actions #1

Updated by Hammel about 2 months ago

  • Severity changed from 03 - Medium to 01 - Critical
Actions #2

Updated by Hammel 15 days ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 20

The pistoreweb application is now stubbed out fully given the API definition (see pistoreweb.c) and expected UI.

The first API implemented is the monitor request for status - get.c:pistoreStatus(). This now needs a unit test. To do this, the jarvis.c/h code needs to be updated to make monitor requests to pistoreweb, but it needs to act like a monitor now and not like Jarvis.

Actions #3

Updated by Hammel 15 days ago

pistoreweb needs to register with the monitor. This must happen before we allow processing by mongoose. Or the mongoose handlers should ignore all requests if registration isn't complete.

Registration is sending the multicast request and getting back the UUID generated by the monitor. Once the UUID is received, it must be stored and used for API transactions.

See piboxd registerDevice() for how registration works. pistoreweb will need to support "/register?uuid=<>". This function also shows possible responses.

Actions #4

Updated by Hammel 12 days ago

Next up:

  1. Save registration UUID.
  2. Disable further registrations.
  3. Test front end UI
Actions #5

Updated by Hammel 12 days ago

Need to handle if more than one ironman responds. For now, just accept a single ironman, re: the first to respond.

Actions #6

Updated by Hammel 12 days ago

Registration and default index.html are now working.

Next:
  1. Retrieve storage stats.
    1. Ready to test but must be tested on PiStore system.
  2. Generate png graph of stats.
    1. This is basically a version of gtk_graph_paint() in pistore:graphwidget.c that just writes the graph to a file.
  3. Create index.tmpl template.
  4. Build image map from png graph.
    1. Generate index.html from index.tmpl and just add links to each drive. An image map can't (easily, keeping it KISS) be sync'd with png write, index gets and graph image gets.
  5. Add code to replace template tags with generated code.
  6. Add CSS to template (embed it to reduce secondary calls).
Actions #7

Updated by Hammel 2 days ago

This essentially works. There is some cleanup I could do to make it pretty.

  • Make the side links for mount points top or bottom justified.
  • Add css like I have on my source directories to make the directory listings more interesting looking.
Actions #8

Updated by Hammel 2 days ago

  • % Done changed from 20 to 90
Actions

Also available in: Atom PDF