-
Notifications
You must be signed in to change notification settings - Fork 979
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create Page from Invocation Report #10241
Conversation
803851c
to
9c6e05d
Compare
content = "" | ||
content_format_hide = False | ||
content_hide = True | ||
if "invocation_id" in kwd: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All this is great but this part makes me a little uneasy, it is on some level what I was trying to avoid since there isn't an API endpoint for generating the page from the invocation but I suppose it is more or less all staying on the backend minus a quick trip in a hidden textarea.
I'll approve this PR but I would be more excited if you just stuck the invocation_id
in the form here and then passed it to the page creation API as a parameter - maybe like this "content_from": {"src": "workflow_invocation", "id": invocation_id}
. And then did this generation in this if block in the page manager on the backend during page creation.
I think the resulting API would be more usable use non-client uses. Since all the API consumer would need would be the invocation ID and they wouldn't need to know how to use the API that generates the report and they wouldn't need to download it and re-submit it in the request.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand and I see your point. Thanks for the detailed explanation. I think we might need both i.e. an augmented API endpoint (which takes the Invocation ID
and populates the Markdown) and this API-like controller endpoint, since fully automated generation of a page from the Invocation ID
can fail if the report Markdown contains errors. Those errors cannot be caught by the Workflow editor but become apparent after completing the invocation. I chose this strategy since it displays a potential error with an alert in the page creation form and allows users to modify the imported Markdown content before creating the page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Adding this feature to the page manager such that it becomes available in the regular page api endpoint would probably look like this: 89f90d3
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Excellent point about catching error! I like 89f90d3 also.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great, I added it to this PR and adding a test case for the API now. Thanks for your comments.
fec87bc
to
ce22bba
Compare
67857c8
to
ae2c192
Compare
Awesome - thanks so much! |
Invocation reports are not mutable but we can use their markdown content to create a page which can then be edited. This PR redirects the edit button in an Invocation Report to the Page creation form. The Page creation endpoint has been modified such that parsing an Invocation ID will populate the form with details from the corresponding Invocation Report. This PR also removes a temporary mako introduced in a recent changeset.
Resolves #10238.