So that users can filter these quarantine views, e.g. useful if they
have many mails there.
Replaced the emailSelection config with a quarantineType configs
since we want to have different behaviour for different quaratine
types. E.g., we want to show 'all' mails by default for the
virus/attachment quarantine, but not for the spam one.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
just better ergonomics and I don't think a lot of people will care
about the parts list, especially if the raw email is already visible
anyway.
Also note that while yes, the content-disposition is user
controllable, most (all?) MUAs only show it if set so even
spammers/attackers have it in their interest to set it.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Normally, attachments are given the 'content-disposition: attachment'
mime attribute, so we use that to filter the attachments.
But since we're dealing with spam & virus mails here, and that field
is client controlled, give the user a way to toggle the remaining parts
of the mail too.
Added the checkbox in the header part, but that made it necessary to
manually implement the expand/collapse toggle (since the tools are on
the wrong side of the default toggle)
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
arguments needs to be an array, often we call with all of ours, iow.
using `arguments` which itself is an array already.
Both, manual construction and just a passing `arguments` have their
advantage and disadvantage, e.g., if either the inheriting or
bequesting class becomes more specialized, but most of the time using
`arguments` is more future proof.
Fixes: e66c888 ("quarantine: refactor spamquarantine controller")
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
format_size is the "lower" level helper and is not fit (anymore) to
be set as renderer directly, as its parameter signature may clash
with the extra, different ones, that renderers get passed.
For example, the useSI param always gets evaluated as true due to
the metaData "truthy" value that calls to a renderer get passed along
most of the time.
Use the render_size instead, a wrapper which only passes along value
to format_size.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
A separate header and docked at the bottom reduces crowding at the
top and make the whole view(s) a bit clearer.
This also better mirrors where most mail clients show attachments
(e.g., thunderbird) and allows to avoid the extra button (UX benefits
most of the time from reduced inputs, if it doesn't takes away
features).
Make the panel collapsible for the spam and virus quarantine, and
hide the download button there; note that this isn't done for
security purpose but just wasn't requested and some users may do
better if they only decide deliver/delete here and let their MUA
handle attachements.
Disable collapsing in the Attachement quarantine, it doesn't really
makes sense there and we got a maxHeight already anyway.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
avoid overly repetition, we can still override them if we get a use
site that really requires different values here.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
So that admins can easily see which attachments exist for a mail,
without parsing the 'raw' mail content. Disable the download button
for these quarantines though, since it should not be necessary
to download the attachments for these.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
one cannot set the different borders seperately in panels/grids and
docked items don't have a bottom border in extjs, but we want to remove
all borders except the ones between the toolbar and the grids/content
below that.
to achieve that, set a custom 'border-bottom-width' with '!important'
(extjs has a rule with !important as well) for the toolbar, and
everywhere else remove the border.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
The rule names ain't _that_ long and it looks a bit better if name
and value are closer together
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
based on the color of the recent patch add a darker and lighter level
for both, good and bad.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
sorting the matching spam rules, e.g. by score, makes it easier to see
which rules have more weight in determining spam.
Additionally, color code the scores with colors akin to the rationale
in commit:
365f84c ("quarantines: color code deliver and delete buttons")
(red for positive spam scores, blue for negative ones)
and increase the font-weight for large spamscore contributing rules.
i chose a different blue tone that is more muted than what we use in
'info-blue' but is different from both the 'hover' color and the
'selected' color
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
By making use of the optional chaining operator, we don't need to
override the 'onSelectMail' in both the attachment quarantine and the
spam quarantine. Instead, we opportunistically call lookup(id)?.setID
in the common handler for both, the attachments and the spaminfo
references.
As that was the single change from the parent class we can now drop
the specialized controller classes.
While at it, remove the stray 'xtype' property of the quarantine
controller, which make only sense for component derived classes.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
[T: fix typos and reword message a bit]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
fixes#1674 (the comment about multiselect for the virus quarantine)
fixes#3947 (multiselect for attachment quarantine)
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
over the time the spam quarantine has gained quite a few nice
usability improvments and features, which would be useful in
the virus and attachment quarantines as well - e.g.:
* multi-mail selection
* keyboard actions
* context menu
* download mail as .eml
this patch splits the controller part into a file of its own, while changing
'var' to 'let' and removing the parts only relevant for the spamquarantine
and adapts the current SpamQuarantine.js to use it.
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
left over from initially trying out different stuff
meh, would be a lot simpler if there weren't a 5 copies or so from
that stuff.
Reported-by: Stoiko Ivanov <s.ivanov@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
In some languages, e.g. widely used English, "Delete" and "Deliver"
are looking rather similar without too much eye squinting required.
Add an accent on their icons using for, at least in the western
hemisphere, the respective associated color, like red for trash can.
To 1) avoid to much messing with those cultures that got it switched
and 2) some more common color blindness use blue for the delivery
button, just to make it stand out.
Keep the white/black list as is, as such accents work best if not
everything uses them, i.e., so that they more common options actually
stand out.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
extends on the improvements from the previous commit, reduces code
lines while (hopefully, as slightly subjective) not reducing
readability
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
the attachment and virus quarantines contain all quarantined mail for
all recipients - so we should display which mail is being
delivered/deleted - mostly if a mail is sent to multiple addresses
served by the same PMG.
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
The `ACME` panel may be rendered out of sight (overflow) when there
are enough SANs on the upper `Certificates` panel to push it down
enough and the browser/display height is too small.
Enable the `scrollable` config for the parent certificate view panel
in the y-axis (vertical) to make ExtJS automatically add a scrollbar
if the content overflows. Avoid enabling it for the x-axis too as
that breaks reflow of the layout if the browser window gets resized.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
[T: fix commit message to one from manager]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
by limiting the store of the day selector by the selected month
reported by a user in the forum:
https://forum.proxmox.com/threads/wrong-calendar.111631/
Reviewed-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
To have a visual feedback about the actions, similar to the swipe
buttons in the quarantine list view. Single difference is that the
default color is grey for swipe buttons and blue for the "normal"
ones, so the whitelist one got different colors, but each fit in
their context somewhat...
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
the change to the rust based subscription code change the case of the
status field, so do the same change as in the desktop ui
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
mostly by s/Regular Expression/Regex/ and transforming some
checkboxes' fieldLabel into boxLabels
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
restructure the existing field positions a bit to make it more
balanced with the new NS field.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
similar in spirit of PVE's storage entries for PBS, changing those
after create can make backups disappear and just shouldn't be done,
user should add a new remote instead.
Same for user name, changing it will make backup almost definitively
fail the owner check, so only keep the password field, for PW
rotations (we should disable it for tokens though).
For UX it's better to check if params are correct and the repo is
accessible on create and to add scan datastore and namespace
endpoints to allow a friendlier selection of those, avoiding typos.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Ext.util.Sorter does not have an 'order' property, so 'order: DESC'
didn't have an effect. The default is 'ASC' and it is arguably the
preferred direction for all affected sorters anyways.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
Allows an user to actually see what the current state is and wastes
less space for the actual header view.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Showing the sender and subject is sufficient in the case of the
spam-quarantine - when viewed by a single user.
If an admin views any of the quarantines the information of the
recipient should be helpful in general, but is needed in case a mail
was sent to multiple recipients.
Reported in our community forum:
https://forum.proxmox.com/threads/.103276/
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
