Deprecate UserItem.Roles.UnlicensedWithPublish and .ViewerWithPublish (never accepted by the server)
還沒有人認領這個 Issue。
評估
研究方向
Start by locating UserItem.Roles and how its class attributes are resolved; compare a class_getattr approach with a Roles.getattribute shim. Review _decompose_site_role and the behavior introduced by PR #1812. Done means accesses to both constants warn, their docstring records historical compatibility and server incompatibility, and existing invalid-user handling remains intact.
由索引模型根據 Issue 內容生成。
描述
UserItem.Roles.UnlicensedWithPublish and UserItem.Roles.ViewerWithPublish are in the public API but have never worked as site role values against the Tableau server:
POST /users(XML path used byusers.add):RestApiSiteRole.fromStringaccepts the modern site roles plus a handful of v2 legacy names (Publisher,Interactor,Guest,SupportUser,SiteAdministrator,ReadOnly). NeitherUnlicensedWithPublishnorViewerWithPublishis in that enum on any REST API version I can see in monolith git history (back to 2023 Perforce snapshot).POST /users/import(CSV path used byusers.bulk_add):CsvLicenseRoleTypeConverteraccepts onlycreator/interactor/explorer/viewer/unlicensed/empty; any other value throwsUSER_CSV_INVALID_LICENSE. There is no site role → license translation before the license converter runs.UnlicensedWithPublish/ViewerWithPublishas literallicensecolumn values are rejected outright.
They've been in UserItem.Roles since the first commit of the library (2016-09-02) and have almost certainly been broken since Tableau Server 8.x/9.x-era licensing was replaced with the current Creator/Explorer/Viewer model.
Proposed fix:
- Emit a
DeprecationWarningwhen either is accessed as a class attribute (via__class_getattr__on a metaclass, or aRoles.__getattribute__shim). - Update the docstring to note the constants are retained for historical compatibility but do not correspond to any accepted server-side site role.
- Remove in a future major version.
Alternatively, if there is any historical or planned server behavior that would accept these strings that I have not found, please point at it and this issue can be closed.
Related
- PR #1812 refactored
_decompose_site_roleand initially defaulted unmapped site roles toUnlicensed, silently coercing these two roles to a valid-but-wrong user creation. That was changed to emitlicense="Invalid"(commit ac84fd3) so the server continues to reject the row instead of silently succeeding. This issue is the longer-term followup to properly deprecate the offending constants.
- 主要語言
- Python
- 星號
- 716
- 分支
- 444
- 平均合併
- 1 天 2 小時
- 30 天內合併 PR
- 1
環境準備
- 沒有 Dockerfile 或 Docker Compose 檔案
- 有 Pull Request 範本
- 閱讀貢獻指南
從這裡開始
- 先讀完整個 Issue，再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫，在一個分支上完成修改。
- 送出 Pull Request，並在描述裡引用這個 Issue 編號。
tableau/server-client-python 的其他 Issue
-
WorkbookItem.update() always sends an empty <dataAccelerationConfig/> even when never set可能已有人在做 @jacalata 於 15 天前認領。 未關閉in-progress
難度 2/5 1-3 小時 新手友好度 78/100
tableau/server-client-python#1884 ·
-
難度 2/5 1-3 小時 新手友好度 70/100
tableau/server-client-python#1865 ·
-
security: _validate_import_line_or_throw logs credential fields at DEBUG level可能已有人在做 @jacalata 於 55 天前認領。 未關閉in-progress
難度 2/5 1-3 小時 新手友好度 78/100
tableau/server-client-python#1829 · 1 則留言 ·
-
enhancement gap needs investigation stale
難度 2/5 1-3 小時 新手友好度 68/100
tableau/server-client-python#1322 · 2 則留言 ·
-
[Type2] Allow Incremental Refresh type schedules to be added via `server.schedules.add_to_schedule`未關閉help wanted Server-Side Enhancement ui-exists
難度 2/5 1-3 小時 新手友好度 68/100
tableau/server-client-python#1101 · 3 則留言 ·
查看 tableau/server-client-python 的全部 Issue
相似的 Issue
-
area: desktop area: website priority: P2 type: feature
難度 2/5 1-3 小時 新手友好度 62/100
appandflow/stim#3411 · 1 則留言 ·
維護者通常 1 天內回覆
-
bug
難度 2/5 1 小時以內 新手友好度 88/100
baptistehamon/lsapy#185 ·
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 82/100
PolicyEngine/policyengine-us#10073 ·
維護者通常 2 天內回覆
-
難度 2/5 1-3 小時 新手友好度 72/100
syedhamidali/radarx#277 ·
維護者通常 1 天內回覆
-
bug
難度 2/5 1-3 小時 新手友好度 68/100
Arekkazu/sgpmp-backend#549 ·
維護者通常 1 天內回覆