We only used this for the privileges for now, and there it's a
nuisance to alter all bit definitions manually if something is added.
This change makes it count the bits up automatically.
Rename the macro to indicate that this is not a generic name map but
a more specific named bit mapping.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
while we probably do not add much more to them, it still looks ugly.
If this was made so that adding a World readable API call is "hard"
and not done by accident, it rather should be done as a test on build
time. But, IMO, the API permission schema definitions are easy to
review, and not often changed/added - so any wrong World readable API
call will normally still caught.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Causes a panic if last_update is smaller than RRD_DATA_ENTRIES*reso,
which (I believe) can happen when inserting the first value for a DB.
Clamp the value to 0 in that case.
Signed-off-by: Stefan Reiter <s.reiter@proxmox.com>
by disallowing [] around ipv4 adresses (which is not very common)
we did not use this anywhere, so there should not be any compatibility
problem
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
after benchmarking (again), i found that doing a simple find instead
of saving the inidices for the ident strings in a hashmap has
no real performance impact (the max list size for the properties
are max ~25 at the moment, so this should not be impacting compile
times much) but it is much simpler
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
to safely differentiate between checking
- the current user matches some static string
- the current user matches the value in some (path) parameter.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
by replacing more characters ('.','+') by '_' and prefix them when
it starts with a number
we sometimes need to parse such fields, e.g in serde attributes like
#[serde(rename = "802.3ad")]
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
the 'properties_' list is sorted by the the literal string of a
fieldname, but we binary-search for the 'ident_str' (which may be
different, since we map '-' to '_' for example)
by creating a hashmap to map from ident to index, we can do a simple
lookup in that case that will work
benchmarks showed no measurable performance difference
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
mainly so we notice if this assumption does not hold for some platform
or changes in the future.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
strftime(3) does not mention this explicitly, but years before 1000 have
their leading zero(es) stripped, which is not valid according to either
ISO-8601 or its profile RFC3339.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
- remove chrono dependency
- depend on proxmox 0.3.8
- remove epoch_now, epoch_now_u64 and epoch_now_f64
- remove tm_editor (moved to proxmox crate)
- use new helpers from proxmox 0.3.8
* epoch_i64 and epoch_f64
* parse_rfc3339
* epoch_to_rfc3339_utc
* strftime_local
- BackupDir changes:
* store epoch and rfc3339 string instead of DateTime
* backup_time_to_string now return a Result
* remove unnecessary TryFrom<(BackupGroup, i64)> for BackupDir
- DynamicIndexHeader: change ctime to i64
- FixedIndexHeader: change ctime to i64
- remove chrono dependency
- depend on proxmox 0.3.8
- remove epoch_now, epoch_now_u64 and epoch_now_f64
- remove tm_editor (moved to proxmox crate)
- use new helpers from proxmox 0.3.8
* epoch_i64 and epoch_f64
* parse_rfc3339
* epoch_to_rfc3339_utc
* strftime_local
- BackupDir changes:
* store epoch and rfc3339 string instead of DateTime
* backup_time_to_string now return a Result
* remove unnecessary TryFrom<(BackupGroup, i64)> for BackupDir
- DynamicIndexHeader: change ctime to i64
- FixedIndexHeader: change ctime to i64
