Fix/batch upload children, with validation according to default widget #896
Conversation
... before the colon is the project name, so should only be "drupal" for modules shipped in core.
... bit of refactoring stuff making a mess.
... as in, basically functional. Still needs coding standards pass, and testing with more/all types of content.
... 'cause need to slap together a media-specific batch similarly?
Both the child-uploading, and media-uploading forms.
... no longer necessarily trying to load files, where files might not be present (for non-file media... oEmbed things?).
... is defined instead at the "FileSelectionForm" level, accidentally left it here from intermediate implementation state.
|
Couple general comments for discussion (not necessarily related to the implementation / code):
|
|
I'm testing this and at http://localhost:8000/node/1/members/upload I get "The requested page could not be found." |
|
@rosiel: Could be a couple of things:
|
|
bump -- let's talk about this soon again if no movement by the next I8 Tech call |
|
Some progress.
|
|
Ah right, forgot about that whole issue, of the
Can make it so... ... as for the other bit... was doubting my sanity at first, looking at it, but, looking back, looks like things were dev'd against ctools 3.7... and the introduction of the |
|
I think this should be good now, @rosiel. |
|
Tech Call: question about ctools version 3 || 4? |
Gave it a run through here, and seemed to work fine; however, ctools' project page still seems to suggest the 3 major version should be preferred... but let's allow 4, if people are using or want to test it out?
|
Gave it a test with ctools 4(.0.1, the version that a
|
|
I updated to your latest commit, and the (children) wizard worked. I made three islandora_object children (node 2, 3, and 4, with medias 1, 2, and 3). However, this was my log message list right after.
The three 'search api' errors i'm not worried about, but some of the others seem like they might be asking for things before they're in place. Here's more detail on the islandora error. A yellow flag went up when i saw it was appending "?_format=jsonld" to the batch url:
|
|
@rosiel : Of that, yeah the one "undefined index count" thing, is a goof on my part, fix'd; however, the other bits... not really sure:
|
|
@wgilling i've done another run through and the fixes @adam-vessey fixed are, indeed fixed. I'm 100% ok with getting this merged but wanted to check if you had any reservations, since you're the requested reviewer. |
Islandora#896) * Add ctools, prior to using it. * Fix up all the dependency references. ... before the colon is the project name, so should only be "drupal" for modules shipped in core. * Some more together. * Decent progress... getting things actually rendering... ... bit of refactoring stuff making a mess. * More worky. ... as in, basically functional. Still needs coding standards pass, and testing with more/all types of content. * Coding standards, and warning of validation issues. * Pull the batch out to a separate service. * Something of namespacing the child-specific batch... ... 'cause need to slap together a media-specific batch similarly? * All together, I think... Both the child-uploading, and media-uploading forms. * It is not necessary to explicitly mark the files as permanent. * Further generalizing... ... no longer necessarily trying to load files, where files might not be present (for non-file media... oEmbed things?). * Adjust class comment. * Get rid of the deprecation flags. * Remove unused constant. ... is defined instead at the "FileSelectionForm" level, accidentally left it here from intermediate implementation state. * Pass the renderer along, with the version constraint. * Add update hook to enable ctools in sites where it may not be. ... as it's now required. * Cover ALL the exits. * Refine message. * Excessively long line in comment... ... whoops. * Bump spec up to allow ctools 4. Gave it a run through here, and seemed to work fine; however, ctools' project page still seems to suggest the 3 major version should be preferred... but let's allow 4, if people are using or want to test it out? * Fix undefined "count" index.
I am ok - and the separate question of ctools version has not been addressed in our Born Digital ops sprints as of yet. |
Islandora#896) * Add ctools, prior to using it. * Fix up all the dependency references. ... before the colon is the project name, so should only be "drupal" for modules shipped in core. * Some more together. * Decent progress... getting things actually rendering... ... bit of refactoring stuff making a mess. * More worky. ... as in, basically functional. Still needs coding standards pass, and testing with more/all types of content. * Coding standards, and warning of validation issues. * Pull the batch out to a separate service. * Something of namespacing the child-specific batch... ... 'cause need to slap together a media-specific batch similarly? * All together, I think... Both the child-uploading, and media-uploading forms. * It is not necessary to explicitly mark the files as permanent. * Further generalizing... ... no longer necessarily trying to load files, where files might not be present (for non-file media... oEmbed things?). * Adjust class comment. * Get rid of the deprecation flags. * Remove unused constant. ... is defined instead at the "FileSelectionForm" level, accidentally left it here from intermediate implementation state. * Pass the renderer along, with the version constraint. * Add update hook to enable ctools in sites where it may not be. ... as it's now required. * Cover ALL the exits. * Refine message. * Excessively long line in comment... ... whoops. * Bump spec up to allow ctools 4. Gave it a run through here, and seemed to work fine; however, ctools' project page still seems to suggest the 3 major version should be preferred... but let's allow 4, if people are using or want to test it out? * Fix undefined "count" index.
GitHub Issue: Islandora/documentation#2129
Release pull requests, etc.)
What does this Pull Request do?
Implements a multi-(/two-)step wizard for bulk child node (and media) creation, where:
... By using the widget this way, ideally we maintain any relevant validation regarding file types and sizes and the like, but also should make use of the field's configured upload location and more.
What's new?
Implemented the wizard(s) and deprecated the old forms.
ctoolsis now a dependency(i.e. Regeneration activity, etc.)? No.
How should this be tested?
Really, should be effectively regression-testing the two batch upload mechanisms being replaced with multi-step wizards:
Use the child-addition wizard to "Batch Upload Children" to create child nodes of a given node.
/node/{node}/members/upload, should be present as a local action on the/node/{node}/membersroute... its use should be relatively straight-forward?Use the media-addition wizard to "Batch Upload Media" to create media on a given node.
/node/{node}/media/upload, should be present as a local action on the/node/{node}/mediaroute... and should be similarly straight-forward to use.Documentation Status
Additional Notes:
Any additional information that you think would be helpful when reviewing this
PR.
Interested parties
Tag (@ mention) interested parties or, if unsure, @Islandora/8-x-committers