-
Notifications
You must be signed in to change notification settings - Fork 40
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 different ways to "update" field values #47
Comments
With an initial upload all content would be new. However, with an update action I think the default assumption should be replace (that values I explicitly give the repository are the only ones that should persist). This option supports delete by simply removing the bad value from among the good that we hand back and add by simply adding the value to the list of values we are returning. I think adding the column/row signifiers overly complicates this. Sure, we can provide this as an "added value" feature for those who want it, but I wouldn't require it by default. |
@seth-shaw-unlv nicely put. I'll continue with the "append" option just to get it working, but make "replace" the default. |
I've added a replace option here for multivalue taxonomy field. |
@Natkeeran sorry I've been distracted focusing on #171. Which branch did you use as the basis for the work in https://github.com/digitalutsc/islandora_workbench/commit/bae6e772a544a0007c84e95c8606d08bdcbd2129? |
@mjordan It is off the main branch. However, the logic is basic can can be adopted easily. |
As of today, users can now use a New field types can be added by writing a class for them in "workbench_fields.py" and corresponding tests in "tests/field_tests.py". Unless there are any objections, I'd like to close this issue. - @seth-shaw-unlv and @Natkeeran, OK to do so? |
Related issue #423. |
Hi @mjordan - I just tested the update_mode: delete and although I am not getting any errors reported, the data in the field is not getting removed. Am I missing something? My config file looks like this:
My CSV file is attached. Output from the .log file is:
|
Everything looks OK, but can you try again and put something in the field_rights CSV field? That shouldn't make a difference but I don't know what else to try without digging into the code. The update/delete task passes all its automated tests so there's something (for example, because it's blank it's being skipped) going on outside of the field-handling code to make this behave the way you are reporting. |
So this is interesting: I ran it again, with text in the Rights field in my CSV, but I forgot to change the update_mode (so it was still set to "delete"). This time, the content was removed from the field completely (as I would have expected before).
My revised CSV (now with content in the Rights column) is attached. You can see the field data is now gone. So it seems to obey the "delete" configuration...if there IS content in the Rights column? |
Without any hands-on verification/testing, I suspect that the fact that the field was blank is causing it to be skipped by the field handler, where the nulling-out of the field contents happens before Workbench updates Drupal. I'll test this hypothesis this evening and fix if that's it. |
Okay, thanks! Just to clarify: isn't that how the "delete" mode is meant to work - if you run an update with blank columns, it deletes what is in that field for the nodes you indicate? Or am I misunderstanding its purpose? |
You're not misunderstanding its purpose - you found a bug. |
Haha - okay, just wanted to make sure! 😄 |
OK, I've fixed this. Thanks for catching it. |
Closing since we now have 3 different ways to update nodes! |
Updates are complicated. Currently, updates in workbench "preserve any values in the fields, they don't replace the values." It would be useful to allow for this type of update, as well as updates that replace existing field values with ones in the input data, delete field values (#39), and remove a specific value from a multivalued field (#40).
It would also be useful to allow users to specify at the row level, rather than for all rows in the input CSV, which of these types of "update" is intended. One option (not necessarily the best) is to have the user provide a flag as the first character in the field itself that indicates which type of update they want. Typed relation fields already use a structured value using
:
to separate the parts of the value, so an approach like that might be applicable. For example, the user specifies ana
for "append input values", anr
for "replace all values with input", ad
for "delete all existing values or a specific value" like this:This would have to work with multivalued fields, and also with typed relation fields, which already use the
:
.If the user didn't want row-level granularity for a given job (i.e., all update operations were of the same kind), the flag should be configurable in the config file.
The text was updated successfully, but these errors were encountered: