From 54102b7356913256b4a1c34834f8914f147b6761 Mon Sep 17 00:00:00 2001 From: nicolasbisurgi Date: Wed, 1 Jul 2026 17:22:26 -0300 Subject: [PATCH] Fix keyring template so `keyring.set_password` matches RushTI's lookup MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The example command stored the secret under service `'TM1py'` and account ``, but `tm1_integration.resolve_tm1_params` looks it up as `keyring.get_password(, )`. Users who copied the template verbatim got the fallback warning and an empty password. Also documents the missing `use_keyring=true` step — keyring is opt-in per section, and the previous template didn't say so. Code path unchanged; docs only. Co-Authored-By: Claude Opus 4.7 (1M context) --- config/config.ini.template | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/config/config.ini.template b/config/config.ini.template index a9aaf41..fb8be04 100644 --- a/config/config.ini.template +++ b/config/config.ini.template @@ -48,5 +48,8 @@ ssl=True # decode_b64=True # # Option 3: Keyring integration (most secure - password stored in OS keyring) -# Leave password empty and store in keyring: -# python -c "import keyring; keyring.set_password('TM1py', 'tm1srv01', 'mypassword')" +# 1. Add `use_keyring=true` to this section (RushTI only queries keyring when opted in). +# 2. Leave `password=` empty in this file. +# 3. Store the secret so the service/account match RushTI's lookup — +# service = section name, account = user: +# python -c "import keyring; keyring.set_password('tm1srv01', 'admin', 'mypassword')"