modifying static elements from the class, like done here with e.g.
me.items[0][key] = value;
is dangerous, since it directly modifies the class definition of those
arrays/objects.
Instead move the definition in initComponent, which uses a fresh
declaration each time the component is initialized.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
* instead of manually setting margin/paddings and the fieldLabel, just
use a FieldContainer instead of Container. That implements the
Ext.form.Labelable mixin, which correctly positions the label. This
also has the effect that the labels are now styled correctly.
* modify the margins to get a consistent spacing between fields
* reverse the order of grid/button, to be consistent with our other
grids with this input pattern
* make the label of the textarea a proper fieldLabel with a
FieldContainer, which gets rid of the ':' in the gettext and
styles the label correctly.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
This can be used to set the `onlineHelp` identifier in the schema as
opposed to in the panel directly. Needed e.g. to share a panel between
PAM and PBS realm.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
This patch adds a filter to identify services, which are reported as
'not-found' by the api. By default they will not be shown in the UI
anymore, but visibility can still be toggled using a new checkbox.
Signed-off-by: Daniel Herzig <d.herzig@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
The widgets for editing the headers/secrets were adapted from
the 'Tag Edit' dialog from PVE's datacenter options.
Apart from that, the new dialog is rather standard. I've decided
to put the http method and url in a single row, mostly to
save space and also to make it analogous to how an actual http request
is structured (VERB URL, followed by headers, followed by the body).
The secrets are a mechanism to store tokens/passwords in the
protected notification config. Secrets are accessible via
templating in the URL, headers and body via {{ secrets.NAME }}.
Secrets can only be set/updated, but not retrieved/displayed.
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
Tested-By: Stefan Hanreich <s.hanreich@proxmox.com>
Add helper functions to convert from a utf8 string to a base64 string
and vice-versa. Using the TextEncoder/TextDecoder we can support unicode
such as emojis as well [0].
[0]: https://developer.mozilla.org/en-US/docs/Glossary/Base64#the_unicode_problem
Signed-off-by: Gabriel Goller <g.goller@proxmox.com>
Reviewed-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
in the tag view, we have a custom 'full' style in a place where we
can have another tagstyle class above. to compensate for that, we have
to add another condition to those styles, namely that there is not the
'proxmox-tags-full' in between.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
We introduced the 'strict' setting when browsers warned about our
cookies not having any SameSite setting [0]. While this works in
general, it had an unforeseen side effect:
When opening a link to the web UI of Proxmox projects, any existing
cookie does not get sent on the initial page load due to coming from
another origin. This then leads to the username and CSRF prevention
token not being set in the index response.
The UI code interprets this as the user being logged out (e.g. because
the ticket is not valid) and clears the cookie, displaying the login
window, even if the cookie's ticket value was still valid.
The MDN reference[1] says that setting it to 'lax' is similar to
'strict', but sends the cookie when navigating *to* our origin even
from other sites, which is what we want when linking from elsewhere.
(This would have also been the default if we wouldn't have set any
attribute).
[0]: https://lore.proxmox.com/pve-devel/20230315162630.289768-1-m.carrara@proxmox.com/
[1]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#SameSite_attribute
Fixes: aec7e8d ("toolkit/utils: set SameSite attr of auth cookie to 'strict'")
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
since the header markup is different than what we use in pve, the
'spacer' elements in the pmg header get a (different colored) border by
default.
We already overwrite it for the first spacer, but when we show an EOL
notice, we have two of them, so add the second one to the rule too.
This also uses the 'css next sibling selector', just for the sibling of
the div with the 'eol-notice' class instead of the 'versioninfo' one.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Also introduce a local viewModel that is linked to a parent viewModel,
allowing us to move the formulas to the panel.
This should make the code more cohesive and easier to follow.
No functional changes.
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
Tested-by: Maximiliano Sandoval <m.sandoval@proxmox.com>
Reviewed-by: Max Carrara <m.carrara@proxmox.com>
Also introduce a local viewModel that is linked to a parent viewModel,
allowing us to move the formulas to the panel.
This should make the code more cohesive and easier to follow.
No functional changes.
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
Tested-by: Maximiliano Sandoval <m.sandoval@proxmox.com>
Reviewed-by: Max Carrara <m.carrara@proxmox.com>
This should make the code more cohesive and easier to follow.
No functional changes.
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
Tested-by: Maximiliano Sandoval <m.sandoval@proxmox.com>
Reviewed-by: Max Carrara <m.carrara@proxmox.com>
These changes introduce combogrid pickers for the 'field' and 'value'
form elements for 'match-field' match rules. The 'field' picker shows
a list of all known metadata fields, while the 'value' picker shows a
list of all known values, filtered depending on the current value of
'field'.
The list of known fields/values is retrieved from new API endpoints.
Some values are marked 'internal' by the backend. This means that the
'value' field was not user-created (counter example: backup job
IDs) and can therefore be used as a base for translations.
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
Tested-by: Maximiliano Sandoval <m.sandoval@proxmox.com>
Reviewed-by: Max Carrara <m.carrara@proxmox.com>
in that case, the type is already part of the url and we must not send
it additionally as an parameter
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Copied from PVE to use in PBS network configuration.
Signed-off-by: Stefan Lendl <s.lendl@proxmox.com>
Reviewed-by: Lukas Wagner <l.wagner@proxmox.com>
Tested-by: Lukas Wagner <l.wagner@proxmox.com>
Tested-by: Folke Gleumes <f.gleumes@proxmox.com>
In PBS, we obviously don't have "Proxmox VE" as a default sender, so
we need a mechanism to change the default author.
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
Tested-by: Maximiliano Sandoval <m.sandoval@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Allow the web UI to accept bridge interfaces with any valid interface
name, rather than being limited to the arbitrary "vmbr" prefix.
Limiting to at most 10 characters, since SDN possibly adds a .XXXX
prefix for Vlans. Since the hard limit for network interface names is
15 characters, limiting it to 10 characters here enables SDN to append
the VLAN prefix in any case.
Originally-by: Jillian Morgan <jillian.morgan@primordial.ca>
Reviewed-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
[ TL: avoid far away intermediate variable ]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
ignore the assembled widget toolkit, the CSS generated from SCSS and
some more packaging related files
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
argh, it's was a bit to late for the previous clean-up and I forgot to
drop a closing parenthesis after reworking the if expression (and did
test again...).
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Since the reset-form functionality got moved into the header tools in
commit 046ec35 ("fix #5277: move reset button into window header
toolbar") we can unconditionally set the initial buttons, as those
will always just contain the submit one now.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
One can get some smart-selection behavior when double clicking text in
browsers, e.g., whole-word selection, and the notes view is generally
for having some text that is often copied, like hostnames or IP
addresses.
Opening the notes editor on double click is interfering with that
select+copy workflow, so instead of hard-coding that make it opt-in,
controlled by a setting from the browser-local storage.
Add some handling to cope with live-changes to that setting, as having
to re-open a panel to make it take effect is annoying and might make
people believe that this is buggy.
This new setting has (currently) to be handled by the per-product UI.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
The gears one from the native tool with the same name is not really
telling and is normally rather used for options, not editing a
specific (notes) field.
So go for the edit pencil that indicates editing some field and use
that for both the edit button in the top bar and the tool one in the
title header bar.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
The 'Reset' button, which can be used to reset the form to its
original values when editing an existing resource or property, was
located at the right to the submit button since its initial addition
(before the git epoch started at Proxmox).
As it had the exact same form and color as the 'OK' submit button, it
is easy to press by accident, which then resets the pending changes
one wanted to submit – while not catastrophic it's just needlessly bad
UX.
As this UX-mishap is something one gets used too relatively fast,
especially as developer due to frequently opening such dialogues to
test changes, its something that mostly newer users will run into.
Luckily one took the effort to actually open an enhancement request,
providing ample resources to underline their point.
While there where quite a few proposals to improve this, most of them
had some (smaller) disadvantage (e.g., potentially jumping location,
confusion with other buttons like the help one).
Moving the reset functionality as as icon-only + tooltip button into
the window header title bar was the proposal that had no real
disadvantage and solved the underlying UX issue by cleanly separating
submit from reset. Having reset near the close-window tool has no
negative implications, as both have a similar effect, the discard the
current pending changes that the user did not yet submit, so if one
mistakenly hits close instead of reset, or vice-versa, nothing is
lost.
A nice side-benefit of that option is that the change is really small
code wise.
Closes: #5277
Reported-by: Tristan Harward <trisweb@gmail.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
The mask ExtJS uses to add a disabled look is using the general
default background color of panels as base color, i.e. white for light
mode and almost black for the dark mode.
But as the top header of windows uses a darker variant, having a mask
applied on some icons that is rendered directly in the header, without
any (button) element that provides its own background color, will make
that element show off.
This mostly happens for Tools, which we do not have many besides the
"Close" on, which is almost never disabled.
This was noticed when trying out to move the reset button inside the
window header tool bar, when that was disabled (e.g., form was not
dirty) it stuck out quite a bit in an odd way.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
The EOL message is positioned quite noticeable already in all our
products, being always visible. So use a notice-style for the icon
and its color until three weeks before EOL, when we switch to a
critical warning.
As it can be OK to run a, e.g., PVE 7 setup shortly before its EOL,
if, for example, one plans to replace it completely and decommission
the old one (so upgrade before EOL would be just extra work).
Using three weeks for the cut-off has no in-depth, heavily thought
out Good Reason™, but was rather chosen as it's likely to be noticed
before the actual EOL in somewhat actively maintained setups (e.g.,
admin checking in every week or two) and can give admins further
means to escalate things with higher ups. Also weeks are always 7
days, while months aren't uniform, so the former is easier to
communicate.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
add a class to the whole outer div to manage the CSS rules for the
EOL widget and use this to keep the original color for links even if
they got visited already.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
While the difference between Reset and Remove is a bit more subtle
this also leads to less jumping around of UI elements on the right to
it (we normally avoid such size-changes that cause layout changes
completely).
Also, the confirmation message is quite telling, so this is not too
bad.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
