Problem
When tabcmd createsiteusers fails on rows in the CSV, the summary just prints the exception class name — the actual server response (error code, detail message) never reaches the user, even at -l DEBUG or -l TRACE.
Repro
Any CSV that causes rows to fail. Example: a site that requires email-format usernames, given a CSV with non-email usernames like jsmith.
Output:
Lines processed: 4
Lines skipped: 4
Number of users added: 0
Error details:
['ServerResponseError', 'ServerResponseError', 'ServerResponseError', 'ServerResponseError']
The user can't tell whether the failures are invalid-license-level, invalid-email, duplicate-user, missing-permission, etc.
Root cause
tabcmd/commands/user/create_site_users.py:57-66 catches TSC.ServerResponseError and calls logger.debug(e) — but the underlying logger for CreateSiteUsersCommand has an effective level of INFO, so DEBUG calls are dropped. Even passing -l DEBUG doesn't surface them (verified — 21-line trace log shows no exception detail lines).
Additionally, only the exception class name is added to the error_list that's summarized at line 73. The commented-out fragment # + ": " + e.__cause__ or "Unknown" suggests someone previously considered including cause detail and pulled it out.
Suggested fix
At create_site_users.py:65, format the error's HTTP status / code / detail into the error_list entry alongside (or instead of) the class name. TSC's ServerResponseError exposes .code, .summary, and .detail — including these in the summary would make row failures actionable.
Optionally, bump the logger.debug(e) call at line 58 to logger.warning or logger.error so the exception surfaces without needing to increase log level.
Impact
Anyone hitting a row-level failure with createsiteusers (or the underlying UserCommand.add_users) currently has to open the source and inject their own logging to figure out what went wrong. Common failure modes (invalid email format on Cloud sites, wrong site role, duplicate user) all look identical in the output today.
Problem
When
tabcmd createsiteusersfails on rows in the CSV, the summary just prints the exception class name — the actual server response (error code, detail message) never reaches the user, even at-l DEBUGor-l TRACE.Repro
Any CSV that causes rows to fail. Example: a site that requires email-format usernames, given a CSV with non-email usernames like
jsmith.Output:
The user can't tell whether the failures are invalid-license-level, invalid-email, duplicate-user, missing-permission, etc.
Root cause
tabcmd/commands/user/create_site_users.py:57-66catchesTSC.ServerResponseErrorand callslogger.debug(e)— but the underlying logger forCreateSiteUsersCommandhas an effective level of INFO, so DEBUG calls are dropped. Even passing-l DEBUGdoesn't surface them (verified — 21-line trace log shows no exception detail lines).Additionally, only the exception class name is added to the
error_listthat's summarized at line 73. The commented-out fragment# + ": " + e.__cause__ or "Unknown"suggests someone previously considered including cause detail and pulled it out.Suggested fix
At
create_site_users.py:65, format the error's HTTP status / code / detail into theerror_listentry alongside (or instead of) the class name. TSC'sServerResponseErrorexposes.code,.summary, and.detail— including these in the summary would make row failures actionable.Optionally, bump the
logger.debug(e)call at line 58 tologger.warningorlogger.errorso the exception surfaces without needing to increase log level.Impact
Anyone hitting a row-level failure with
createsiteusers(or the underlyingUserCommand.add_users) currently has to open the source and inject their own logging to figure out what went wrong. Common failure modes (invalid email format on Cloud sites, wrong site role, duplicate user) all look identical in the output today.