-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Annotation and Title detail #18762
base: dev
Are you sure you want to change the base?
Annotation and Title detail #18762
Conversation
@ElectronicBlueberry this commit will have negative downstream effects? |
I know this is WIP, but one tiny styling improvement could be made by placing the run and cog button in the same line as the wf name: as opposed to: One way to achieve this would be a On a somewhat related note, I always felt that using the same styled header as a
|
workflowInfoData.value = await workflowInfoDataPromise; | ||
} catch (e) { | ||
const error = e as AxiosError<{ err_msg?: string }>; | ||
messageVariant.value = "danger"; |
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.
Looks like messageVariant will only be used for "danger" when there is an error, so you can fix the variant to danger and safely remove the redundant ref.
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.
@davelopez very helpful comment - change made.
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.
Really cool, thank you! But please don't embed the published card there. Just a simple expand would be brilliant.
const expandAnnotations = ref(true); | ||
const workflowInfoData = ref(null); | ||
|
||
onMounted(() => { |
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.
onMounted runs after initial rendering and creation of the DOM. You don't need to wait for that.
loading.value = true; | ||
|
||
try { | ||
const workflowInfoDataPromise = getWorkflowInfo(props.model.runData.id); |
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.
This bypasses all stores and fetches the workflow even if we already have it. Can you use useWorkflowInstance instead ?
An even better alternative is to serialize the workflow annotation for the run request. This would be as simple as
diff --git a/lib/galaxy/managers/workflows.py b/lib/galaxy/managers/workflows.py
index 0d970de242..5921ad74f4 100644
--- a/lib/galaxy/managers/workflows.py
+++ b/lib/galaxy/managers/workflows.py
@@ -1051,6 +1051,7 @@ class WorkflowContentsManager(UsesAnnotations):
step_models.append(step_model)
return {
"id": trans.app.security.encode_id(stored.id),
+ "annotation": stored.annotation,
"history_id": trans.app.security.encode_id(history.id) if history else None,
"name": stored.name,
"owner": stored.user.username,
we only use the run endpoint here in the workflow run component, so if we always need the attribute I don't see a reason not to just serialize that as well.
You would then have this available in the runData object here.
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.
Follow-up questions related to the existing _workflow_to_dict_run() method in Workflows.py (eg. maybe some refactoring needed as a separate ticket).
(1) Blocker: I am assuming the purpose of @mvdbeek 's code suggestions is to not make an additional database call, correct? However, using the VSCode Debugger to find already-available values, I have not yet been able to find the following variables for the WorkflowInformation.vue component to be fully displayed. Specifically, creator
, email_hash
. and license
. Although, the License may not be appearing because there is no value for it in my dev-qa use-case, but email_hash
should display (since there is an avatar selected) and creator
should always have a value. I am assuming that Email Hash can be created from the non-hashed email string parameter: stored.annotations[0].stored_workflow.user.email? I was able to find/serialize the other values (including Workflow Tags).
(2) Side note: calling stored.annotation
(singular) fails with the error: 'StoredWorkflow' object has no attribute 'annotation'. The plural value can be accessed using stored.annotations
; however, it lacks parameters like the Workflow Tags. Instead, I used stored.annotations[0].stored_workflow
to get the Workflow Tags - if that is an unreliable value, please let me know.
(3) Side note: using useWorkflowInstance
pulls up an entirely different Workflow when using the Encoded Workflow ID (that appears in the URL). Tried also with the literal Workflow ID number (as a string) and failed. Perhaps this works only for Invocations since that is where I see useWorkflowInstance
used in the codebase currently...? The method seemed to be able to used successfully in WorkflowInvocationHeader.vue
so hopefully @ahmedhamidawan can please advise on this question?
(4) Question: Not a blocker, but I was surprised the following element didn't contain Workflow Annotation data within the same method: workflow.annotation
returns null
instead of any actual Workflow Annotation data. If that is not expected, then this line is broken. If "null" is expected, how can this be -is the variable misnamed? This code block is pretty old, but perhaps last editors have some thoughts: @guerler @nsoranzo @dannon ?
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.
useWorkflowInstance
takes the stored workflow_id
as parameter, not the encoded_workflow_id
we have here from the run data. The stored id is essentially the id for the specific workflow (for the given version; latest in this case) retrieved here:
galaxy/lib/galaxy/managers/workflows.py
Line 916 in aa25743
workflow = stored.get_internal_version(version) |
Once we have that id, the whole loadAnnotation
method could be replaced by a:
const { workflow, loading, error } = useWorkflowInstance(stored_workflow_id);
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.
@ahmedhamidawan Thank you so much for this helpful comment. The latest iteration of this (v3) doesn't need this additional data right now, but I may need to know this helpful piece of information in the future.
lib/galaxy/managers/workflows.py
Outdated
if step.annotations: | ||
step_model["annotation"] = step.annotations[0].annotation | ||
if step.upgrade_messages: | ||
step_model["messages"] = step.upgrade_messages | ||
step_models.append(step_model) | ||
return { | ||
"id": trans.app.security.encode_id(stored.id), | ||
"annotation": annotations_dict, |
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.
@mvdbeek Please let me know if it would be even better to serialize these SQLAlchemy objects in stored.annotations
in some other way, happy to replace.
name: props.model.runData.name, | ||
owner: props.model.runData.owner, | ||
tags: props.model.runData.annotation.tags.map((t: { user_tname: string }) => t.user_tname), | ||
annotations: [props.model.runData.annotation.annotation], |
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.
@itisAliRH for this line annotations: [props.model.runData.annotation.annotation],
is ok to only use the first annotation record (ie. annotation[0]
)? Or are other annotation records need to be included/consolidated somehow?
@itisAliRH Wanted your review on changes to the |
lib/galaxy/managers/workflows.py
Outdated
if step.annotations: | ||
step_model["annotation"] = step.annotations[0].annotation | ||
if step.upgrade_messages: | ||
step_model["messages"] = step.upgrade_messages | ||
step_models.append(step_model) | ||
return { | ||
"id": trans.app.security.encode_id(stored.id), | ||
"annotation": annotations_dict, |
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.
You're including properties here that are not part of the annotation model.
This is a good attempt that goes in the right direction, I'll try to find some time to rework this.
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.
Sure - any insights & examples are appreciated too.
09a4eae
to
2b5f1ac
Compare
Ahmed: Minor change requests
|
455a0ec
to
471ca88
Compare
… duplicate on same page
Co-authored-by: Ahmed Hamid Awan <[email protected]>
…kflows Landing Page (instead of design consistency with Workflows Annotation History Panel). Added 'show-actions' Boolean parameter to focus user on running the workflow as consistent with their intended behavior from the prior step; when 'show-actions' equals False, all actions are hidden (note: not same terminology as technical 'read-only' as 'show-actions' also prohibits Share/Favorite which are separate from being able to Edit a workflow).
Co-authored-by: Marius van den Beek <[email protected]>
Co-authored-by: Marius van den Beek <[email protected]>
…ocations Page and Workflow Run Form Page
…ocations Page and Workflow Run Form Page
- No `in_panel` prop in route anymore - In `lib/galaxy/managers`, all we need is the `workflow.id` so on the front end, for the run form, we can call `useWorkflowInstance(workflow_id)` - Adjust props and variables in the workflow header to cater for all edge cases such as whether it is rendering for run form or invocation view, workflow is owned or not, is published or not etc. - Minor style improvements
The `BButton :to`, was replaced with a `BButton @click` because the styling in `WorkflowNavigationTitle` worked better with a non `<a>` BButton (using `:to` turns the `<button>` into an `<a>`)
471ca88
to
fa118ba
Compare
Addresses #18711. Visually, there are numerous ambiguous ways to solve this issue.
Version 3
takes into account Marius' comment for simplicity but maintaining consistency with Workflows Landing Page design_.v3: Expandable Portlet component with site consistency for Workflows Landing Page
Version 2
takes into account Ahmed's comment for consistency with Tool Form page header design.v2: Expandable Portlet component with site consistency
Version 1
is illustrated below as an "expandable portlet" solution. Other ideas/possibilities: "Mouse Hover Overlay-Menu", "Mouse Click Overlay-Menu", "Only Display Description", and so forth. After general solution is agreed, will complete "code clean-up" and test script fix process. Constructive ideas/comments welcome.v1: Expandable Portlet component
How to test the changes?
(Select all options that apply)
License