public inbox for pdm-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Proxmox Datacenter Manager development discussion
	<pdm-devel@lists.proxmox.com>,
	Dominik Csapak <d.csapak@proxmox.com>,
	Shannon Sterz <s.sterz@proxmox.com>
Subject: Re: [pdm-devel] [PATCH yew-comp 2/2] token_panel: implement a token panel
Date: Sat, 27 Sep 2025 19:07:43 +0200	[thread overview]
Message-ID: <9cc35cf3-208b-4bcf-b24a-3544221e1f8c@proxmox.com> (raw)
In-Reply-To: <5d896cd1-2e37-463b-aafd-a9eb833fd254@proxmox.com>

Am 26.09.25 um 10:50 schrieb Dominik Csapak:
>> +async fn load_api_tokens() -> Result<Vec<ApiToken>, Error> {
>> +    let url = "/access/users/?include_tokens=1";
>> +    let users: Vec<UserWithTokens> = crate::http_get(url, None).await?;
>> +    let mut list: Vec<ApiToken> = Vec::new();
>> +
>> +    for user in users.into_iter() {
>> +        list.extend(user.tokens)
>> +    }
>> +
>> +    Ok(list)
> 
> could also be written as
> 
> Ok(users.into_iter().map(|user| user.tokens))

That misses a collect and that tokens is a list too, but while it cannot
be written that way, one can do it almost like this using:

Ok(users.into_iter().flat_map(|user| user.tokens).collect())

I made a follow-up commit doing so.

Am 26.09.25 um 10:50 schrieb Dominik Csapak:
>> +        Dialog::new(tr!("Token Secret"))
>> +            .with_child(
>> +                Column::new()
>> +                    .with_child(
>> +                        InputPanel::new()
>> +                            .padding(4)
>> +                            .with_large_field(
>> +                                tr!("Token ID"),
>> +                                DisplayField::new()
>> +                                    .value(AttrValue::from(
>> +                                        secret["tokenid"].as_str().unwrap_or("").to_owned(),
>> +                                    ))
>> +                                    .border(true),
>> +                            )
>> +                            .with_large_field(
>> +                                tr!("Secret"),
>> +                                DisplayField::new()
>> +                                    .value(AttrValue::from(
>> +                                        secret["value"].as_str().unwrap_or("").to_owned(),
>> +                                    ))
>> +                                    .border(true),
>> +                            ),
>> +                    )
>> +                    .with_child(
>> +                        Container::new()
>> +                            .style("opacity", "0")
>> +                            .with_child(AttrValue::from(
>> +                                secret["value"].as_str().unwrap_or("").to_owned(),
>> +                            ))
>> +                            .into_html_with_ref(self.secret_node_ref.clone()),
> 
> does this actually work as a copy input?
> 
> AFAICS: copy_to_clipboard wants to cast the noderef to a
> HtmlInputElement, and i don't think a container qualifies for that?

Would probably be better to rename it to something like
copy_input_element_to_clipboard then, and add a new function
copy_text_content_to_clipoard that simply takes the noderef's
textContent [0]. As of is this rather confusing, doesn't help
that the copy_to_clipboard fn silently ignores if it fails to
cast the element.

[0]: https://developer.mozilla.org/en-US/docs/Web/API/Node/textContent

> 
> couldn't we simply show the secret in a disabled textfield and use that for copying? then we don't have to add some extra 'hidden' container with the secret?

There is already a field displaying the secret above, which should
be usable? The whole thing seems like a useless indirection.

Btw. I know this mirrors the original and I added the copy button there,
but nowadays I'd prefer having a icon-only+tooltip button to the right of
the input field for both fields.


_______________________________________________
pdm-devel mailing list
pdm-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pdm-devel


  reply	other threads:[~2025-09-27 17:07 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-24 14:51 [pdm-devel] [RFC datacenter-manager/proxmox/yew-comp 0/8] token support for pdm Shannon Sterz
2025-09-24 14:51 ` [pdm-devel] [PATCH proxmox 1/3] access-control: refactor api module to be more hirachical Shannon Sterz
2025-09-26  8:26   ` Dominik Csapak
2025-09-24 14:51 ` [pdm-devel] [PATCH proxmox 2/3] access-control: move `ApiTokenSecret` to types module Shannon Sterz
2025-09-26  9:14   ` Fabian Grünbichler
2025-09-24 14:51 ` [pdm-devel] [PATCH proxmox 3/3] access-control: add api endpoints for handling tokens Shannon Sterz
2025-09-26  9:14   ` Fabian Grünbichler
2025-09-24 14:51 ` [pdm-devel] [PATCH yew-comp 1/2] utils/user_panel: factor out epoch_to_input_value helper Shannon Sterz
2025-09-27 16:57   ` [pdm-devel] applied: " Thomas Lamprecht
2025-09-24 14:51 ` [pdm-devel] [PATCH yew-comp 2/2] token_panel: implement a token panel Shannon Sterz
2025-09-26  8:50   ` Dominik Csapak
2025-09-27 17:07     ` Thomas Lamprecht [this message]
2025-09-27 16:57   ` [pdm-devel] applied: " Thomas Lamprecht
2025-09-24 14:51 ` [pdm-devel] [PATCH datacenter-manager 1/3] ui: add a token panel and a token acl edit menu in the permissions panel Shannon Sterz
2025-09-24 14:51 ` [pdm-devel] [PATCH datacenter-manager 2/3] server: access: use token endpoints from proxmox-access-control Shannon Sterz
2025-09-24 14:51 ` [pdm-devel] [PATCH datacenter-manager 3/3] server: clean up acl tree entries and api tokens when deleting users Shannon Sterz
2025-09-26  9:18   ` Fabian Grünbichler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9cc35cf3-208b-4bcf-b24a-3544221e1f8c@proxmox.com \
    --to=t.lamprecht@proxmox.com \
    --cc=d.csapak@proxmox.com \
    --cc=pdm-devel@lists.proxmox.com \
    --cc=s.sterz@proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal