Closed patrickmj closed 9 years ago
The items from my own Omeka install did not import the associated metadata if I did not map the items. It wasn't clear to me that the items had to be mapped in order for the metadata to import.
If elements were mapped, did that data come in okay?
Otherwise, that sounds like expected behavior.
Or maybe more details about what's expected for element to property maps for the default settings are in order.
I think it would help to make it clear that fields MUST be mapped for any metadata to be imported. Perhaps not allowing import unless there is mapping (why would you import without mapping)?
Interface note - it's not clear that "Get Data" doesn't run the import. I would change it to "Map Data" or "Get Data for Mapping"
Well, if it's working, there will always be some default mappings. There's no actual way to import data that isn't mapped.
I'm not sure how to differentiate. There's text in the sidebar explaining the button in the sidebar, which is different from "Import". We might be getting down to indistinguishable details here.
Is there a reason there are two import buttons? Both below where a user enters the api info and in the upper right.
Yes. Upper right is standard placement across many views. At the bottom is because that's where people's eyes will be after a long screen.
I think it might be easier if there was just one - we would have the standard placement and it forces people's eyes to go across the "Get Data" button. The upper-right import button remains in view when users scroll down the import area.
sounds happy! changes made on develop
Looks good, thank you!
Yay!
There's also those checkboxes in the original issue to check. That'd help a lot, too
File metadata was coming through fine and changing metadata and updating worked when pulling from mallhistory, but the last two times I've tried to update from http://dev.omeka.org/mebrett/Omeka/, the process seems to be getting stuck. Importing onto the shared install on dev.
Thanks! That sounds like a new issue.
Huh. Looks like I got everything from your site, @mebrett . Am digging around on dev server for clues.
@mebrett Looks like its the large file at http://dev.omeka.org/mebrett/Omeka/items/show/501 that hits the memory limit. It's now issue #45 . Until that's resolved, it'll be fine to test and look at the other things at the top of this issue with other origin Omeka sites.
Take a look at Job 166 on the shared install -it's an Omeka2 import, shows up on Jobs, started in Firefox, but it doesn't show up under Past Imports for the Module (other in progress jobs do).
I'm having the same issue in Safari.
@mebrett @alyssafahringer I'll dig around to see why those jobs aren't showing up. Oddly, I'm not seeing any past import jobs.
@mebrett @alyssafahringer The past imports not showing up looks like a combo of 1) an uninstall/reinstall I did to catch up the database and 2) a new bug. Those should be fixed now on develop.
Many changes are up. Changes based on #36 are in there. Basic steps are the same, but:
Feedback on the new interface/workflow, as well as functionality, welcome and helpful at this point. There are lots of possible combinations of things that could get weird, so an Omeka 2 Import site with a lot of variations and as much weirdness as you can muster will help. Then, it'll be testing whether you can break it with the import process.
A couple I can think of, but there will be more for us to discover:
Known issues
Depending on the original site's API settings, it might not find all the elements ( #34 )Mapping to Media isn't connected yet ( #25 ), so that checkbox is uselessNB: Like the other modules, this is moved over to using the 'develop' branch for ongoing work, so you'll want to pull the latest and switch to that branch