Post-merge follow-up on #1811 -- the strict behavior it introduced
(create_user_from_line raises ValueError on any auth value not in
_AUTH_CANONICAL) would block CSV imports against newer servers as
soon as Tableau ships an auth type TSC's hardcoded list doesn't yet
know about. This is the same category of stale-list problem the
_set_values enum-guard bypass exists to avoid on the server-parse
path.

Both entry points now warn and pass the value through:

- create_user_from_line: unknown values raise a UserWarning naming
  the value and known set, then get assigned to auth_setting as-is.
  If the value really is a typo, the server rejects the row when
  the request posts -- a slightly-later error, but the import stays
  possible against forward-compatible servers.

- _validate_import_line_or_throw: same shape. Skips the allowlist
  check for the AUTH column when the value isn't in _AUTH_CANONICAL,
  so validate_file_for_import doesn't return the row as invalid.

Server-version-aware validation would be the cleaner long-term fix
here (and for the enum-guard bypass in _set_values); noted for
planning, not filing an issue.

Tests updated: two former "raises ValueError" cases now assert
pytest.warns(UserWarning) and confirm the raw value round-trips
onto UserItem.auth_setting.

… _evaluate_site_role (#1812)

* fix: CSVImport AUTH column, case-insensitive validation, username preservation; add find_by_name

Fixes for UserItem.CSVImport (issue #1809):
- MAX=8 (was 7=AUTH index): 8-column lines with auth type no longer
  rejected as "too many columns"
- create_user_from_line no longer lowercases the whole line before
  splitting — username case is preserved
- _validate_import_line_or_throw normalizes license/admin/publisher to
  lowercase and auth to canonical form before comparison, so 'Viewer',
  'Creator', 'SAML', 'tableauidwithmfa' etc. are all accepted
- Add TableauIDWithMFA to valid auth values in validation (was missing)
- 5 new tests covering each fix

Add QuerysetEndpoint.find_by_name(name) (issue #1810):
- Thin wrapper over .filter(name=name) returning a list
- Available on all content-item endpoints (workbooks, datasources,
  views, users, projects, groups)

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

* fix: add auth column to create_users_csv, fix create_from_file extension check and debug prints

- create_users_csv was producing 7-column CSV, silently dropping
  auth_setting; bulk_add roundtrip would lose auth type
- create_from_file extension check used filepath.find("csv") which
  evaluates as falsy only when "csv" is at index 0, letting all other
  paths through; fixed to "csv" not in filepath
- remove two debug print() calls left in create_from_file

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

* refactor: extract _decompose_site_role into CSVImport, symmetrical with _evaluate_site_role

Moves the ad-hoc site role → (license, admin_level, publish) logic from
create_users_csv into UserItem.CSVImport._decompose_site_role, making it
the explicit inverse of _evaluate_site_role.

Also fixes pre-existing bugs in the decomposition:
- ExplorerCanPublish was emitted as license="ExplorerCanPublish" (not a
  valid CSV license value); now correctly "Explorer" with publish=1
- SiteAdministrator (legacy role) was emitting license="" via
  str.replace; now maps to ("Explorer", "Site", "1")
- Non-admin roles now emit admin_level="None" (explicit CSV spec value)
  rather than "" (empty string); both are accepted by the server but
  "None" is consistent with the spec and _evaluate_site_role input

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

* fix: decompose unsupported site roles to license="Invalid" not "Unlicensed"

Legacy values in UserItem.Roles (UnlicensedWithPublish, ViewerWithPublish,
Guest, SupportUser) have never been accepted by the server-side CSV license
parser (workgroup: CsvLicenseRoleTypeConverter). The initial _decompose_site_role
default of ("Unlicensed", "None", "0") silently coerced these to a valid but
semantically wrong Unlicensed user, replacing an old server-side per-row
rejection with silent success.

Default to license="Invalid" instead so the server continues to reject rows
with USER_CSV_INVALID_LICENSE, preserving the pre-refactor observable
behavior for callers who inspect job results for per-row failures. Batch
resilience is unaffected: bad rows fail, good rows succeed, no client-side
throw takes down the whole bulk_add call.

Follow-up: deprecate UnlicensedWithPublish/ViewerWithPublish from
UserItem.Roles (never worked on any code path); see forthcoming issue.

* docs: clarify _decompose_site_role's asymmetric legacy-role handling

The role map handles legacy UserItem.Roles values in two ways depending
on whether the server has a modern equivalent. SiteAdministrator,
Publisher, Interactor, and ReadOnly map to their current-model
equivalents; UnlicensedWithPublish, ViewerWithPublish, Guest, and
SupportUser fall to license="Invalid" so the server rejects the row.

Reviewers otherwise read the code and see "why does Publisher get
mapped but Guest doesn't?" - the answer is server behavior, not
arbitrary choice. Docstring now says so.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* fix: accept "1"/"0" and "true"/"false" for publisher, add round-trip test

Two related changes to make `_evaluate_site_role` and
`_decompose_site_role` a real inverse pair:

- `_evaluate_site_role` now accepts "1", "true", and "yes" for the
  publisher column (and, symmetrically, treats anything else as "no").
  Previously only "yes" was accepted, which meant `_decompose_site_role`
  emitting "1" for Creator/ExplorerCanPublish would round-trip as
  Explorer. The set of publisher values mirrors what
  `_valid_attributes[publisher]` already documents as legal
  (["yes", "true", "1", "no", "false", "0"]), so this brings the two
  code paths in agreement.

- Added a parametrized `test_decompose_then_evaluate_round_trips`
  covering every entry in `_role_map` plus the two documented label
  asymmetries (ServerAdministrator -> SiteAdministrator on the way
  back; legacy roles Publisher/Interactor/ReadOnly/SiteAdministrator
  folded into their modern equivalents). If either function drifts,
  a specific input names the broken case rather than the whole loop
  dying on the first mismatch.

- `_decompose_site_role` docstring updated with a Round-trip note
  naming the two intentional asymmetries so readers do not have to
  reason about them from the mapping table.

Full suite still passes: 884 passed, 1 skipped.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* Address fresh-eyes review nits before un-drafting

- Strip five non-ASCII characters (arrow + em-dashes) from docstrings
  and comments; project convention is ASCII-only.
- create_user_from_line now passes an unknown auth value through
  unchanged (previously silently .get'd to None). _validate_import_
  line_or_throw on the same input raises, so the two entry points
  no longer disagree on what counts as valid.

Not addressed here (per fresh-eyes review, non-blocking):
- Deprecated create_from_file's "csv" substring check remains loose
  (matches report.csv.bak, rejects USERS.CSV); pre-existing on a
  @deprecated method, out of scope for this refactor.
- PR body test-plan checkbox that's actually complete: tick before
  un-drafting.

59 user tests pass.

* Warn (don't raise) on unknown auth values during CSV import

Post-merge follow-up on #1811 -- the strict behavior it introduced
(create_user_from_line raises ValueError on any auth value not in
_AUTH_CANONICAL) would block CSV imports against newer servers as
soon as Tableau ships an auth type TSC's hardcoded list doesn't yet
know about. This is the same category of stale-list problem the
_set_values enum-guard bypass exists to avoid on the server-parse
path.

Both entry points now warn and pass the value through:

- create_user_from_line: unknown values raise a UserWarning naming
  the value and known set, then get assigned to auth_setting as-is.
  If the value really is a typo, the server rejects the row when
  the request posts -- a slightly-later error, but the import stays
  possible against forward-compatible servers.

- _validate_import_line_or_throw: same shape. Skips the allowlist
  check for the AUTH column when the value isn't in _AUTH_CANONICAL,
  so validate_file_for_import doesn't return the row as invalid.

Server-version-aware validation would be the cleaner long-term fix
here (and for the enum-guard bypass in _set_values); noted for
planning, not filing an issue.

Tests updated: two former "raises ValueError" cases now assert
pytest.warns(UserWarning) and confirm the raw value round-trips
onto UserItem.auth_setting.

* Strip password-mask line: it belongs to #1862, not this PR

Inadvertently pulled the password-column mask
(safe_value = "***" if column == PASS else value) into this PR while
restructuring the validation loop for the warn-on-unknown-auth
change. The mask is #1862's core content and shouldn't sneak in
through the site-role decompose PR -- reviewers on either PR would
see mysterious overlap. #1862's full feature (log mask + INFO->DEBUG
downgrade + _redact_password_column helper for invalid_lines
sanitization) stays where it belongs, on jac/csv-import-privacy.

The `column = ColumnType(i)` local rename stays because it's used
by the log line's `{column.name}` format and by the AUTH branch's
comparison; that's plain cleanup and doesn't overlap with #1862.

---------

Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>