Skip to content
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

Pre-migration questions/notes #160

Open
michael-wynne-wsu opened this issue Dec 4, 2023 · 2 comments
Open

Pre-migration questions/notes #160

michael-wynne-wsu opened this issue Dec 4, 2023 · 2 comments

Comments

@michael-wynne-wsu
Copy link
Member

  1. Do atoms get flagged as referenced by multiple items if it's used in a DH item with community records? I'm seeing a lot of them in my tests and that seems likely.

  2. I suspect lots of sites are going to end up with a real mix of unreferenced and multi-referenced atoms (see below - out of 1530 atoms that needed a protocol assignment, 690 were able to duplicate from item). I don't know if we can practically do anything to make this step more manageable, but in a lot of cases I wouldn't even know where to start hunting down multi-referenced atoms. At least with unreferenced atoms if those could be separated out I bet many would be deleted or assigned a single review protocol...

Screenshot 2023-12-04 at 9 01 53 AM

@taylor-steve
Copy link
Collaborator

  1. Yes. Each community record is an independent DH item, including a reference to the atom. We could change the duplicate action to ignore community records, but copying the protocols from only the original record could certainly result in a different level of access to the media than the original site in many cases.
  2. We have views like /manage/scald-atoms that allow you to filter by protocol/no protocol, if that helps. Another VBO for batch assignment of specific protocols could be added. Showing atoms with multiple references is more difficult, the full data we need isn't easily captured in a Drupal view, but I think it is possible. Though it's another situation where there's no guarantee any one user on a site will be able to see the whole "picture", depending on their memberships.

@michael-wynne-wsu
Copy link
Member Author

  1. Okay that makes sense, I just wanted to confirm. I actually DO wonder how much inheriting from original record only would mess things up. In v3 a community had to be listed to enable creation of a relevant community record. I'm oversimplifying and probably missing something though...

  2. I can see the no protocol filter at /manage/scald-atoms being useful once all referenced atoms are resolved. Any atoms left without protocols would in theory not be in use on the site, they could be assigned or just deleted easily.

The big issue I'm hitting is okay I have a list of atoms that need manually assigned protocols. How do I determine which protocols? Unless my file naming is great and I can identify DH items from there.... What about reporting the other way - here is a list of content that includes an atom with no protocol?

Happy to meet and discuss if it helps.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants