Implement custom view objects #1195
Conversation
Also added custom view operations to the workbook sample
I removed the user_model tests because I already removed the requirement for user.name to be populated. The custom view owner might only have an id.
| @@ -74,6 +74,10 @@ def main(): | |||
| if all_workbooks: | |||
| # Pick one workbook from the list | |||
| sample_workbook = all_workbooks[0] | |||
| sample_workbook.name = "Name me something cooler" | |||
| sample_workbook.description = "That doesn't work" | |||
There was a problem hiding this comment.
To confirm, updating the description doesn't work?
There was a problem hiding this comment.
Yes - it's an open bug, hopefully fixed soon.
| if not view_item.id: | ||
| error = "Custom view item missing ID." | ||
| raise MissingRequiredFieldError(error) | ||
| if not (view_item.owner or view_item.name or view_item.shared): |
There was a problem hiding this comment.
I don't see anything about updating the shared property in the REST API docs. Is the check on view_item.shared necessary?
There was a problem hiding this comment.
It's aspirational. Actually sending a value now wouldn't work, but this means that it will work in tsc as soon as the REST API supports it.
There was a problem hiding this comment.
Gotcha. But might this condition prevent someone from changing a shared CV to be not-shared?
There was a problem hiding this comment.
No - this condition is just saying that if the user hasn't set any values on the view_item, don't bother sending an update request. Currently we'll send a request if they change the shared attribute, but that will fail.
There was a problem hiding this comment.
Hmm, if a user did not specify a value for either owner or name but set shared to False, we'd still not bother to send an update request? Does Python distinguish between None and False in conditional statements?
| if parsed_views and len(parsed_views) > 0: | ||
| cv_item._view = parsed_views[0] | ||
|
|
||
| if workbook_id: |
There was a problem hiding this comment.
For my knowledge, what is the reasoning behind favoring this workbook_id override instead of always parsing the XML response?
There was a problem hiding this comment.
This is matching the behavior in view_item.py, where I believe the reasoning was
a) our Fields implementation means a View response doesn't have to contain a workbook element, but the user quite likely has the workbook id available
and b) if both the parameter and the xml element are available, we want a consistent priority order and chose this order as least likely to surprise a user: if they pass in a value, they will know where it came from when it shows up.
* Implement custom view objects (#1195) * Fix bug in update-datasources before 3.15 (#1203) (fixes #1072) * catch exceptions from ServerInfo (#1204) * add query-tagging attribute to connection (#1202) (add explanation for why it doesn't work on hyper) --------- Co-authored-by: Marwan Baghdad <mrwanbaghdad76@gmail.com> Co-authored-by: jorwoods <jorwoods@users.noreply.github.com> Co-authored-by: Brian Cantoni <bcantoni@salesforce.com> Co-authored-by: TrimPeachu <77048868+TrimPeachu@users.noreply.github.com> Co-authored-by: Stu Tomlinson <stu@nosnilmot.com> Co-authored-by: Jeremy Harris <jercharris89@gmail.com>
They are not quite the same as normal views so they got their own class.
You can
Note that you can only export as image(png) - no csv or pdf export is available.
This will enable the feature to be added to tabcmd - yay!