From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id 5D5011FF380 for ; Fri, 19 Apr 2024 16:01:53 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 97FAEA9B1; Fri, 19 Apr 2024 16:01:53 +0200 (CEST) Message-ID: Date: Fri, 19 Apr 2024 16:01:49 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Fiona Ebner , Proxmox VE development discussion References: <20240415082614.2515677-1-l.wagner@proxmox.com> <20240415082614.2515677-9-l.wagner@proxmox.com> Content-Language: de-AT, en-US From: Lukas Wagner In-Reply-To: X-SPAM-LEVEL: Spam detection results: 0 AWL -0.002 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pve-devel] [PATCH manager v5 08/16] api: notification: add API for getting known metadata fields/values X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Proxmox VE development discussion Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" On 2024-04-19 15:45, Fiona Ebner wrote: > Am 15.04.24 um 10:26 schrieb Lukas Wagner: >> + >> +__PACKAGE__->register_method ({ >> + name => 'get_field_values', >> + path => 'values', >> + method => 'GET', >> + description => 'Returns known notification metadata fields and their known values', >> + permissions => { >> + check => ['or', >> + ['perm', '/mapping/notifications', ['Mapping.Modify']], >> + ['perm', '/mapping/notifications', ['Mapping.Audit']], >> + ], >> + }, >> + protected => 1, >> + parameters => { >> + additionalProperties => 0, >> + }, >> + returns => { >> + type => 'array', >> + items => { >> + type => 'object', >> + properties => { >> + 'value' => { >> + description => 'Notification metadata value known by the system.', >> + type => 'string' >> + }, >> + 'comment' => { >> + description => 'Additional comment for this value.', >> + type => 'string', >> + optional => 1, >> + }, >> + 'field' => { >> + description => 'Field this value belongs to.', >> + type => 'string', >> + optional => 1, >> + }, >> + 'internal' => { >> + description => 'Set if "value" was generated by the system and can' >> + . ' safely be used as base for translations.', >> + type => 'boolean', >> + optional => 1, >> + }, > > And wouldn't it be nicer to return already grouped by field? Then maybe > we also don't really need the dedicated fields API endpoint either as > those are just the top-level of the result (with empty array when there > are no values so we don't ever miss any fields). > The design of both endpoints was mostly driven by the intention of keeping the ExtJS side as simple as possible. Two comboboxes, each with their own api endpoint to fetch data from, one setting a filter for the other one. I tried using a single endpoint at first, but was quickly frustrated by ExtJS and its documentation and settled for this approach as a consequence. So I'd prefer to leave it as is :D Regarding the 'internal' flag: Yes, you are right, right now we only need it for 'type'. I'll leave it out then and handle everything in the UI. -- - Lukas _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel