IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Fixes:
warning: unresolved link to `seccfg`
--> proxmox-section-config/src/typed.rs:18:71
|
18 | /// If the [`SectionConfig`] returned by the [`section_config()`][seccfg] method includes the
| ^^^^^^ no item named `seccfg` in scope
|
= help: to escape `[` and `]` characters, add '\' before them like `\[` or `\]`
= note: `#[warn(rustdoc::broken_intra_doc_links)]` on by default
warning: unresolved link to `seccfg`
--> proxmox-section-config/src/typed.rs:22:10
|
22 | /// [seccfg] ApiSectionDataEntry::section_config()
| ^^^^^^ no item named `seccfg` in scope
|
= help: to escape `[` and `]` characters, add '\' before them like `\[` or `\]`
Signed-off-by: Maximiliano Sandoval <m.sandoval@proxmox.com>
The original typed section config data would insert and remove the
type properties. With the introduction of `.with_type_key()` this is
done on the parse/write side instead, so we need to be able to opt out
of this.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
For when the underlying datatype is supposed to contain the type
property and the schema does not mark it as optional.
The use case here is to support flat `Remote` type where the "type" of
pve/pmg/pbs is a property which is present in the `Remote` struct
while being derived from the section type.
This will implicitly include and strip the type of the json object
after/before de/serializing.
Alternatives would be
- to mark the type as optional and just fill it out later when loading
the data, but that is technically wrong...
- have a 2nd version of the struct with the type field removed and
From/Into implemented, but that's even more unwieldy.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Fixes the clippy lints:
warning: unnecessary use of `get("lo").is_none()`
--> proxmox-network-api/src/config/parser.rs:603:30
|
603 | if config.interfaces.get("lo").is_none() {
| ------------------^^^^^^^^^^^^^^^^^^^
| |
| help: replace it with: `!config.interfaces.contains_key("lo")`
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#unnecessary_get_then_check
= note: `#[warn(clippy::unnecessary_get_then_check)]` on by default
Signed-off-by: Maximiliano Sandoval <m.sandoval@proxmox.com>
these two functions don't actually use the `type_name` parameter, but the
interface including custom formatters require it.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
HashMaps are not ordered, so each package build containing a section config
dump would have the documentation ordered randomly.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Mostly relevant when the config is written out again after parsing it
with unknown sections. Previously, with duplicate keys, only the last
value would be saved. Now, duplicate keys are assumed to be part of
an array schema and handled as such.
Because the unknown section parsing does not know if a certain
property does actually have an array schema, it's not possible to
detect duplicate keys for non-array-schema properties, and if a
property with array-schema shows up only once, it will not be saved as
a Value::Array, but a Value::String.
Writing, or to be precise the format_section_content methods, already
handle Value::Array, so don't need to be adapted.
Fixes: 0cd0d16 ("section config: support allowing unknown section types")
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Similar to commit c9ede1c ("support unknown types in section config")
in pve-common.
Unknown sections are parsed as String-JSON String key-value pairs
without any additional checks and also written as-is.
Suggested-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
we already expose the raw sections which are sometimes
easier to use, but we don't expose the order at all this way
otherwise
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Additional properties will be parsed according to the default string
schema.
This is relevant for use cases when the full schema is not known for
some reason or another. In particular this allows support for parsing
older/newer versions of configuration files. One example of this is
the proposed proxmox-mail-forward helper binary, which currently
doesn't have access to the PBS API types for dependency reasons and
is only interested in the email field for the root user. If it can
only use a minimal schema with additional_properties set to true, it
will be robust against changes.
Writing already works, because the ObjectSchema's verify_json()
already handles additional_properties correctly and
format_section_content() handles them like all other properties
(method doesn't depend on the schema).
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
