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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Without this the check and the, through the 'install' target
triggered, incremental lint target triggered a full eslint run.
Makes it similar to what PBS did from the beginning of eslint
inclusion..
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
(cherry picked from commit 557c45056c)
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Not only into those with an xtype one, as we can either have a
implicit default xtype (e.g., in tbars for buttons, or set explicitly
via the `defaults` mechanism) or want to apply cbinds to stores or
other objects.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
(cherry picked from commit 5995eddcc4)
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
We do not want to trigger an autoSelect if there's a value set, even
if it isn't found in the store, as that hides the fact that an (now)
invalid valid is configured from the user, which can be confusing if
something is not working, as when editing an object it seems like a
valid value is selected.
Further, if a value is set we mark the field as invalid from the
start, at least if it's neither disabled nor allowed to have a
value which is does not exists in the backing store.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
So that users of this component do not necesacrrily need to add an
initComponent override and make the `me.add_XYZ_row()` there, but
instead can use something like:
gridRows: [
{
xtype: 'text',
name: 'http-proxy',
text: gettext('HTTP proxy'),
defaultValue: Proxmox.Utils.noneText,
vtype: 'HttpProxy',
deleteEmpty: true,
},
],
I avoid using `rows` as config key as that is internally used for
quite a few things, and potentially some existing users (did not
checked all). We can still switch to that easily if it is deemed to
be better...
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
If there is extended information, the variable is overwritten anyways.
Avoid appending an extra space if there is no extended information.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
Storage capacity and usage seems to prefer the base ten (SI unit) use
(makes the capacity a bigger number) while memory (RAM) is normally
preferred to use base 2.
So allow both, mostly to allow consistent displaying of metrics.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
60% is just way to low, this probably could be 80% or even 85% too,
in huge setups that normally means that there's still a lot of
resources left, but be conservative for now.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
we may want to replace them someday, at least with an intermediate
widget xtype for unified querying, but it's only going through the
local descendant, which is not that bad size-wise, so don't care..
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
PVE has 2 domain lists, PMG only 1 since it requires the
additional type.
In PBS I do not want to have 2 lists either, since it seems
rather inconvenient to have 2 different ways to access the
same list.
Currently we decide this based on whether we have multiple
certificate types, which in PBS we don't, so we need a
separate option for this.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
If an error is received upon expanding a node, chances are the rest of
the tree is still valid (i.e. opening a partition fails because it
doesn't contain a supported filesystem). Only show an error box for the
user, but don't mask the component in that case. Additionally, disable
the download button.
Also support an archive set to 'all' to expand all children, useful for
initializing a file-restore VM on initial load.
Signed-off-by: Stefan Reiter <s.reiter@proxmox.com>
Denotes objects like disks ".img.fidx" files, which shouldn't be
downloadable, but should still approximate a directory entry.
Signed-off-by: Stefan Reiter <s.reiter@proxmox.com>
Call a function to decide if we want to mask the component. If the
callback returns true, we assume it has already handled the error (i.e.
shown a messagebox or similar) and skip masking.
Signed-off-by: Stefan Reiter <s.reiter@proxmox.com>
Looks like more change than it actually is, see
`--word-diff=color --word-diff-regex='\w+'`.
The single semantic change is the added space in the render_cpu,
between the maxcpu value and CPU/s text
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
with 2 minor fixups:
* one lint error
* binding of the 'updateValues' function in the event
(we want to avoid breaking this when used in a context where
a controller exists, in that case using a string will only look in
the controller and not in the component itself anymore, so use
the function directly)
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
To be replaced by generic additional items specified by the user of the window
or child class. AFAICS there are no existing users of this widget yet, so this
shouldn't break anything.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
The chart axis get initialized really, so changing the segmenter in
initComponent is not possible anymore, we can only alter the chart
base config in the constructor.
Luckily, the actual segmentation happens later, so we can pass a
flag to the y-axis and hook into the segmenter directly by creating
a new one derived from 'Ext.chart.axis.segmenter.Numeric'.
There we override the preferStep and exactStep methods to decide if
we want to calculate with base 10 or base 2.
So add a constructor to RRDChart and set the axis with the respective
segmenter, depending on the powerOfTwo config, up there initially.
Note: that makes overwriting the axes from a caller impossible, but
we do not use that anywhere, and we can control the more important
parts of the axes, like label or units already otherwise, so seems
not really required, and if, its not to hard to solve (either by
always using our new segmenter by default and handle the different
bases there directly, or by adding an explicit do not touch axes
config flag, or the like).
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>