Permissions Support 2.0#429
Conversation
* _PermissionsEndpoint to be used inside Endpoint that has the calls * Added a couple of classes related to permissions, followed naming convention of API
|
Thanks for tackling the permissions work! Here are my thoughts for the two questions above:
/cc @RussTheAerialist @gaoang2148 |
This comment has been minimized.
This comment has been minimized.
gaoang2148
left a comment
gaoang2148
left a comment
There was a problem hiding this comment.
Do the things!
(Make the update methods all consistent-like.
convert strings to constants
|
Aaaaand done. I've made the calls all consistent, and implemented the Reference pattern. I decided not to subtype things because they all need a tag_name that they take from the Item class, and they all need an ID passed in to the constructor... the subtypes added no value at all! Maybe someday they will, we can safely refactor this then, but for now, this implements the Ran a manual test and the few tests in the suite, I'll add more tests but wanted to get this out for review so I can start adding the other content types. /cc @RussTheAerialist @gaoang2148 @shinchris |
|
🚀 |
Release v0.9 ## 0.9 (4 Oct 2019) * Added Metadata API endpoints (#431) * Added site settings for Data Catalog and Prep Conductor (#434) * Added new fields to ViewItem (#331) * Added support and samples for Tableau Server Personal Access Tokens (#465) * Added Permissions endpoints (#429) * Added tags to ViewItem (#470) * Added Databases and Tables endpoints (#445) * Added Flow endpoints (#494) * Added ability to filter projects by topLevelProject attribute (#497) * Improved server_info endpoint error handling (#439) * Improved Pager to take in keyword arguments (#451) * Fixed UUID serialization error while publishing workbook (#449) * Fixed materalized views in request body for update_workbook (#461)
Add support for getting and setting permissions for all content types. This is accomplished with a few patterns, some new, some old. 1 - We now have a `_PermissionsEndpoint` much like tags, that gets composed into a permissions sub-endpoint for each type. Calls to the type endpoint pass through to the sub-endpoint, just like tags. Item models treat permissions like any populated property. 2 - Permissions are returned as a list of rules, where a rule is a grantee-capability pairing. 3 - We have another sub-endpoint for DefaultPermissions, for Projects and (in another PR), databases. 4 - We have a new `as_reference` and and `to_reference` method on `User` and `Group` types, that let's us create an id-only object for use in permissions parsing, and as a short-hand for those objects when you don't need all the other properties. I think this could expand to all item types, but I haven't yet hit a strong need for it so skipped that for this already giant PR.
Release v0.9 ## 0.9 (4 Oct 2019) * Added Metadata API endpoints (tableau#431) * Added site settings for Data Catalog and Prep Conductor (tableau#434) * Added new fields to ViewItem (tableau#331) * Added support and samples for Tableau Server Personal Access Tokens (tableau#465) * Added Permissions endpoints (tableau#429) * Added tags to ViewItem (tableau#470) * Added Databases and Tables endpoints (tableau#445) * Added Flow endpoints (tableau#494) * Added ability to filter projects by topLevelProject attribute (tableau#497) * Improved server_info endpoint error handling (tableau#439) * Improved Pager to take in keyword arguments (tableau#451) * Fixed UUID serialization error while publishing workbook (tableau#449) * Fixed materalized views in request body for update_workbook (tableau#461)
4 participants
This is an old massive PR that slowly works on getting permissions into tsc.
@DepthDeluxe contributed a lot (most) of the initial code, but I've forked and simplified a lot of the interfaces. I think we can still build the convenience functions they want but this is a simpler starting point.
I have two main open questions:
What do we do with Grantees? The GranteeUser/Group object only needs an 'id' to be passed into a PermissionsRule. However, the Group and User Item classes have a bunch of required (and non-nullable) properties. It's nice that we can just pass in a UserItem or GroupItem from a query, into PermissionsRules but I ALSO want to enable the ability to just create the users/groups you need based on ID. Currently I have this subtyped and overriding the problematic properties, but we could also just change UserItem/GroupItem to be more flexible. A middle ground is some kind of classmethod that constructs a UserItem/GroupItem out of only ID (a classmethod of some sort). What do you think?
How should we handle Default Permissions? Help Link
I have a few ideas, one is to just have a default permissions endpoint that's largely copy/paste from the permissions endpoint, and then have an update method on it that takes (ResourceType, List[PermissionsRule]). Alternatively I can reuse most of the existing code if I just make a
update_datasource_default_permissions,update_workbook_default_permissions, etc -- on to the permissions endpoint, and then somehow only enable that for projects (via an optional parameter in the init for the permissions endpoint? Via a classmethod? something else?) I need to prototype here more./cc @shinchris @RussTheAerialist @gaoang2148
If I can get answers to those two, I can implement the remaining stuff and start on the tests.