Get rid of old Attachments action, adjust new actions

[labkey-adam]

Rationale

Old, slow action has been replaced by a simple query

Related Pull Requests

• Add and populate core.Documents.ParentType column #7231

[labkey-jeckels]

Manually tested with site admin, troubleshooter, and reader access. Permissions functioned as expected, including on the backing core.Documents table.

Would be nice to have a little more automated coverage, unless I'm missing something that's already been merged. Maybe just check that the documents table is/isn't available for a few representative roles.

FWIW, on my dev DB, the majority of documents have no parent type. Is that expected?

[labkey-adam]

Manually tested with site admin, troubleshooter, and reader access. Permissions functioned as expected, including on the backing core.Documents table.

Would be nice to have a little more automated coverage, unless I'm missing something that's already been merged. Maybe just check that the documents table is/isn't available for a few representative roles.

FWIW, on my dev DB, the majority of documents have no parent type. Is that expected?

I added AttachmentsTest with previous merges. Feel free to review and/or augment that test.

I have one unkonwn attachment in my long-running database, but I was running with a full set of modules. I would expect lots of blanks if you're not running with one or more modules that are responsible for attachments in your DB. If the AttachmentParentTypes aren't present, we can't resolve their attachments. (Going forward, though, modules coming and going won't affect the ParentType column.) If you click through, the listing should show you attachment names and folder names, which should provide some clues as to what these are.

If clicking through doesn't resolve the mystery, you can try the hidden action admin-findAttachmentParents.view. This will crank for a while, looking for EntityIds that match your unknown attachments' parents. Primitive, but it may help.

[labkey-jeckels]

I added AttachmentsTest with previous merges. Feel free to review and/or augment that test.

Perhaps worth a quick addition to try as a troubleshooter (since that took extra work) and also make sure you can't see core.Documents in a folder as a simple reader.

I have one unkonwn attachment in my long-running database, but I was running with a full set of modules. I would expect lots of blanks if you're not running with one or more modules that are responsible for attachments in your DB. If the AttachmentParentTypes aren't present, we can't resolve their attachments. (Going forward, though, modules coming and going won't affect the ParentType column.) If you click through, the listing should show you attachment names and folder names, which should provide some clues as to what these are.

If clicking through doesn't resolve the mystery, you can try the hidden action admin-findAttachmentParents.view. This will crank for a while, looking for EntityIds that match your unknown attachments' parents. Primitive, but it may help.

Looking at those orphaned attachments, the vast majority are repeated many times and look to be from folder import/export testing. Seems like they're related to samples (I still have the exploded folder archive), but samples use Files, not Attachments. I'm confused.

[labkey-adam]

I added AttachmentsTest with previous merges. Feel free to review and/or augment that test.

Perhaps worth a quick addition to try as a troubleshooter (since that took extra work) and also make sure you can't see core.Documents in a folder as a simple reader.

I have one unkonwn attachment in my long-running database, but I was running with a full set of modules. I would expect lots of blanks if you're not running with one or more modules that are responsible for attachments in your DB. If the AttachmentParentTypes aren't present, we can't resolve their attachments. (Going forward, though, modules coming and going won't affect the ParentType column.) If you click through, the listing should show you attachment names and folder names, which should provide some clues as to what these are.
If clicking through doesn't resolve the mystery, you can try the hidden action admin-findAttachmentParents.view. This will crank for a while, looking for EntityIds that match your unknown attachments' parents. Primitive, but it may help.

Looking at those orphaned attachments, the vast majority are repeated many times and look to be from folder import/export testing. Seems like they're related to samples (I still have the exploded folder archive), but samples use Files, not Attachments. I'm confused.

Test has been updated. I don't know what's going on with those attachments. What does admin-findAttachmentParents.view say?

[labkey-jeckels]

Test has been updated. I don't know what's going on with those attachments. What does admin-findAttachmentParents.view say?

It doesn't add much. They show in the listing. The right-most column, tablename, is blank for them.

[labkey-adam]

Test has been updated. I don't know what's going on with those attachments. What does admin-findAttachmentParents.view say?

It doesn't add much. They show in the listing. The right-most column, tablename, is blank for them.

Well, that's weird. I know @labkey-tchad identified a couple places where we orphan attachments, i.e., when deleting a parent, we fail to delete the associated attachments. For example, https://github.com/LabKey/internal-issues/issues/707