For tapes with many snapshots/group, a simple list of them is too
big. Instead, add a level for just the groups, this makes searching
for a specific backup much easier.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
but auto-expand them, so no additional click is necessary
this shows the user which tapes are involved for the media sets
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
if a catalog is missing (or the loading otherwise throws an error), show
the error message in a msg box instead of a mask. this way a user can
still navigate the tree
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
instead of showing the snapshots directly under the pool and then the
media-sets, list the media-sets under the pool and only after the
snapshots
this has several advantages:
* we only have to read one set of tape catalog data on expand and not all of
them everytime (which does not scale)
* we can show media-sets without snapshots, this can happen when we
inventoried a set of tapes from another pbs instance, or lost the
catalog data somehow
the disadvantage is that one has to go look for the media set where the
snapshot is included, but we can solve this by implementing a search
function in the future (in the backend)
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
instead of grouping by tape (which is rarely interesting),
group by pool -> group -> id -> mediaset
this way a user looking for a backup of specific vm can do just that
we may want to have an additional view here were we list all snapshots
included in the selected media-set ?
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
shows all tapes with the relevant info
* which pool it belongs to
* what backups are on it
* which media-set
* location
* etc.
This is very rough, and maybe not the best way to display this information.
It may make sense to reverse the tree, i.e. having pools at top-level,
then media-sets, then tapes, then snapshots..
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Dominik Csapak
Dietmar Maurer