-
Notifications
You must be signed in to change notification settings - Fork 0
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
Allow supporting files to be added to requests #175
Conversation
369413f
to
8fbf9a9
Compare
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 looks great, a lot of careful work here.
I have left a bunch of comments on various bits.
My only main question is how we build and store the information about supporting files in the nav tree. Think, rather than use relpath_to_html_class
, output_files_with_group
and supporting_files_with_group
, we should build the supporting file info right into PathItem and the tree building.
Something like this:
- Add method
.is_supporting_file(relpath)
to AirlockContainer- Workspace (always returns False).
- ReleaseRequest (looks up RequestFile, returns True if supporting) (I just added a way to look up a file by path in my PR)
- Add
PathItem.supporting_file
boolean property - Use that to add
supporting
class in.html_classes
- When creating a PathItem in get_path_tree, set
supporting=container.is_supporting_file(relpath)
- In
html_classes
, addsupporting
ifself.supporting
This way, the PathItem itself has all the information needed at construction time to a) render itself in the nav tree and b) render its file metadata/contents.
except bll.APIException as err: | ||
# This exception is raised if the file has already been added | ||
# (to any group on the request) | ||
messages.error(request, str(err)) | ||
else: | ||
messages.success( | ||
request, f"File has been added to request (file group '{group_name}')" | ||
request, | ||
f"{filetype.name.title()} file has been added to request (file group '{group_name}')", |
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.
Nice improvement. I'm a big fan of messages containing as specific info as possible.
53ee532
to
3d64ec6
Compare
@bloodearnest sorry for stupid question. You said:
Can you point me at what you're referring to here? I'm looking at your iframes PR and I can't see an obvious lookup-RequestFile-by-path sort of thing. |
I just realised its in a WIP branch, not yet committed! Let me get it up |
Also changes the local_db's StatusField to a generic EnumField
Also renames `get_file_paths` (used when releasing files) to `get_output_file_paths` Currently the UI doesn't differentiate between output and supporting files.
3d64ec6
to
5039e21
Compare
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.
Brilliant, thanks for making those changes!
Give a PathItem knowledge of whether it is a supporting file or not.
5039e21
to
c044a26
Compare
Fixes #128
files
(which are output files) and now also has asupporting_files
attributeAdding a file now has a field for filetype, defaulting to Output