I.e., for those that only got permissions on a sub namespace and
those that onlöy got BACKUP_READ, as both they could just list and
count themselves too after all, so not exactly secret info.
The UI needs some adaptions to cope with gc-stats and usage being
optional, will be done in a next commit.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
we can now use it for the error case and will further use it for the
can access namespace but not datastore case in a future patch
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
which is stable since rustc 1.32 but wasn't available in out
toolchain when this was originally written in commit 7bc1d7277
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
use the relatively new variant of ListAccessibleBackupGroups to also
allow pruning the groups that one doesn't own but has the respective
privileges on their namespace level.
This was previously handled by the API endpoint itself, which was ok
as long as only one level was looked at.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Not only check all owned backup groups, but also all that an auth_id
has DATASTORE_AUDIT or DATASTORE_READ on the whole namespace.
best viewed with whitespace change ignore (-w)
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
The "owner override" privs will skip the owner check completely if
the authid has a permission for any of the bitwise OR'd privs
requested on the namespace level.
The "owner and privs" are for the case where being the owner is not
enough, e.g., pruning, if set they need to match all, not just any,
on the namespace, otherwise we don't even look at the groups from the
current NS level.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
with namespaces the paths can get pretty complex, so make the path
column take some flex space too, but not too much to avoid making it
look odd for the short paths we have otherwise
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Without namespaces this had not much use, but now that we can have
permissions below we should allow so.
For convenience also query the namsepaces here and add them to the
list of available ACL paths, the read-dir shouldn't be that expensive
(albeit, we could cache them in the frontend)
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
We can have those in existing verify jobs configs, and that'd break
stuff. So, even while the "bad" commit got released only recently
with `2.1.6-1` (14 April 2022), we still need to cope with those that
used it, and using some serde parser magic to transform on read only
is hard here due to section config (json-value and verify currently
happen before we can do anything about it)
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
This reverts commit 7a1a5d206d.
We could already cause the behavior by simply setting ignore-verified
to false, aas that flag is basically an on/off switch for even
considering outdated-after or not.
So avoid the extra logic and just make the gui use the previously
existing way.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
else it's a lot of wasted space for the ordinary case, that hasn't
permanent maintenance modes activated, and even if, their admins
should be used to it, so not the best space/usability ROI there
either.
Just use the icon as visual clue and add a tooltip for the
maintenance mode info.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
matches what we do for (most) of such things in PVE since 7.0 there
and also what the disk management gui shows, further disks are sold
with SI units for their advertised capacity, so its more fitting
there too.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
commit bd21a63b only fixed sync, not verify, and we can do better by
using a display-edit field.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
causes trouble with UI and is inconsistent as its still missing in
file restore (daemon)
We probably want to use a separate property to safe this to avoid
confusion with size.
This reverts commit 66ad63bac2.
Not only can we remove a few lines of duplicated code, we also get
the "link to repo management" for free.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
only ask the name of the current NS, not the full NS path to avoid
too long input requirements on deep levels.
needs a few smaller hacks, ideally we would pull out the basic stuff
from Edit window in some EditBase window and let both, SafeDestroy
and Edit window derive from that, for better common, in sync
features.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
after all we couldn't delete all that got requested, ideally this
should become a task where we can log what got deleted and what
not...
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
no changes in interface for users of the crate as we re-export
anyway, so more for avoiding to crowd the datastore module to much
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
And make that opt-in in the API endpoint, to avoid bad surprises by
default.
If not set we'll only prune empty namespaces.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
it maybe should still simple get dropped and replaced with
(empty)Text 'Root' or 'Root Namespace'
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
never makes sense to clear the value due to remote or remoteStore
change as we weren't enabled then in the first place.
This fixes clearing the currently set namespace on editing an
existing job, which always made it seem like the Root namespace was
selected, even if the originalValue was correct (thus the dirty-form
reset/ok behaviour still worked, making it even more confusing)
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
to avoid making it "jump" in the users face by immediately opening
the picker on window open.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
This provides immediate feedback for adding the respective icon in
the navigation tree entry most of the time, and we can then increase
the query period of the datastore list store to the original 15
again, as it was lowered to 5 seconds for just this reason in commit
fbd6f54f39
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
we query that store to add the datastore specific ACL paths to
improve UX there, this failed a while due the StoreManager lookup
always failing as the store wasn't registered in the StoreManager due
to using storeid vs. correct storeId
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
for better re-usability in the future and it felt a bit odd to have
such specific logic in the sync job edit directly
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>