Open patdunlavey opened 9 years ago
Additonal comments from email thread: Pat: Hi Peter,
The block is filtered by rels-ext relation name, so my off-the-top-of-my-head guess is that you used the same relation name for your ingested submissions as the collection content model uses for its children. If true, and if changing the relation name is not possible/practical, and if you are using a consistent namespace for your parent objects, you could use that in the block visibility section.
Peter: Pat:
Thanks for your suggestion, but...
the RELS-EXT datastream in the ingested submission Fedora objects all have an "isAnnotationOf" relation, as the following shows.
Hi @petermacdonald and @patdunlavey, can you confirm the delta for the block is correct? Did you clear your drupal cache after modifying the relations? Reading the code, i see the block "delta" is the actual rdf relation used to fetch the objects. So, if the block was generated initially using a "wrong" delta, then even when you change the default relation used by the ingest webform, the already in place block could still be using the initially configured one.
Basically, what is the link (mouse over the iw block you are using) when you go to admin/structure/block?
Hope i'm not adding confusion to the topic, but since hook_block_info() defines the deltas initially(a.k.a relations), i assume that even when those are changed on the fly, the already configured ones could still live in the DB or cache using a wrong delta and as a result display wrong relations.
@petermacdonald and @DiegoPino - Peter has stumbled into what I believe is a critical flaw in the ingested objects rels-ext logic that can wreck all of your repository's collections in one false-move! So, first, if this is on your production repository, I would back it up now. Though it may be too late!
You can set ingested objects to use the "Is Member Of Collection" relation to the target object. That's not a problem yet. The catastrophic problem occurs (may occur - I haven't actually tested it) if you then modify your webform ingest settings to use a different relation predicate. In that case, all objects in the repository that are members of a collection will have that relation replaced by the new one - thus wrecking all of your collections!
As I say, I haven't tested this, but I think it is true. And it would explain the behavior that Peter is seeing.
@DiegoPino Can you think of a way to prevent this from happening? Can we add some flag to the rels-ext record to identify it as generated by this particular ingest configuration, and then when the ingest configuration is changed, only change those rels-ext records associated with it?
@DiegoPino has proposed a solution and we have given him the go-ahead to work on it. So I'm assigning this task to him.
@petermacdonald: Diego thinks he can implement a method for fixing member of collection relationships that have been lost. Probably best if you wait to hear back from us before attempting to change any more webform ingest relationship predicate settings.
Thanks, Pat
I have a fairly robust and flexible set of Tuque-based Drush scripts that I can run against a repository to effect things like RELS-EXT changes too. If they might be useful here just let me know.
-Mark
From: Pat Dunlavey notifications@github.com<mailto:notifications@github.com> Reply-To: commonmedia/islandora_webform reply@reply.github.com<mailto:reply@reply.github.com> Date: Thursday, July 2, 2015 at 11:31 AM To: commonmedia/islandora_webform islandora_webform@noreply.github.com<mailto:islandora_webform@noreply.github.com> Subject: Re: [islandora_webform] Related object block shows incorrect objects (#10)
@petermacdonaldhttps://github.com/petermacdonald: Diego thinks he can implement a method for fixing member of collection relationships that have been lost. Probably best if you wait to hear back from us before attempting to change any more webform ingest relationship predicate settings.
Thanks, Pat
Reply to this email directly or view it on GitHubhttps://github.com/commonmedia/islandora_webform/issues/10#issuecomment-118086609.
Great @McFateM, i appreciate your offer, i will give a local try first using my tools and will also contact you tomorrow to get some info on how we can identify the affected objects so we can roll everything back and fix this. Thanks!
I'm off work (holiday) tomorrow (Friday, July 3), but if you still need or want to talk on Monday please let me know. Take care and have a great weekend.
-Mark
From: Diego Pino Navarro notifications@github.com<mailto:notifications@github.com> Reply-To: commonmedia/islandora_webform reply@reply.github.com<mailto:reply@reply.github.com> Date: Thursday, July 2, 2015 at 2:24 PM To: commonmedia/islandora_webform islandora_webform@noreply.github.com<mailto:islandora_webform@noreply.github.com> Cc: Mark McFate mcfatem@grinnell.edu<mailto:mcfatem@grinnell.edu> Subject: Re: [islandora_webform] Related object block shows incorrect objects (#10)
Great @McFateMhttps://github.com/McFateM, i appreciate your offer, i will give a local try first using my tools and will also contact you tomorrow to get some info on how we can identify the affected objects so we can roll everything back and fix this. Thanks!
Reply to this email directly or view it on GitHubhttps://github.com/commonmedia/islandora_webform/issues/10#issuecomment-118140085.
Hi @McFateM, @petermacdonald and @patdunlavey. I just committed a new branch so we can test some new functionality and ideas. Basically
It's a lot of code, some invisible fixes but proactive (means if we start from 0 everything flows). So we need now a retroactive fix for current ingested objects. There are many different ways we could handle this, from deleting -> re ingesting to batch identifying and updating. And i can help on this.
I did many, many border case tests, but i'm sure you will find a much more border case that i have not resolved, so i would love you could clone this branch and start playing around.
Wow Diego, you did a lot of work! (I think you measure time differently down there!)
We should probably have another skype call to discuss strategies for retroactive fix.
It will take some time to properly understand and test all this work. But on first run-through, I had a couple questions related to this screenshot:
Hi Pat, well, let's forget about timing this time =)
About your questions:
On Jul 8, 2015, at 7:58 AM, Pat Dunlavey notifications@github.com wrote:
Wow Diego, you did a lot of work! (I think you measure time differently down there!)
We should probably have another skype call to discuss strategies for retroactive fix.
It will take some time to properly understand and test all this work. But on first run-through, I had a couple questions related to this screenshot:
Does 'Only those objects that are using the former predicate ""' mean that all objects with that predicate will be modified, or only those objects ingested under this webform with this predicate? Should we have separate options for those two possible preferences? The messages area indicates that the other settings have been saved, which seems a little strange on a confirmation page. Do you know if at this stage of the form submission those settings have been saved yet? If not, I think we should just change when the message appears. Otherwise, it may not be worth the trouble to modify the form submission process to save the other settings after the confirmation page. — Reply to this email directly or view it on GitHub.
Thanks Diego, that makes sense. I'll think about improving the wording on that page.
I'm going to be occupied with other things today. Will you have any time tomorrow (Friday) for a skype call about retroactive approaches?
@petermacdonald does the original problem described in this issue still exists for you?
From @petermacdonald: I have set the IW block to show up in the right side-panel (see image below), but when I'm viewing the whole collection it is displaying every item in the collection -- most of which are not submissions at all.![incorrectrelatedobjects](https://cloud.githubusercontent.com/assets/241240/8463846/c20b7b0e-200b-11e5-974b-eb87b66d73eb.png)