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

MH-13167, Republishing metadata does not update all metadata #490

Merged
merged 1 commit into from Oct 22, 2018

Conversation

Projects
None yet
2 participants
@lkiesow
Copy link
Member

lkiesow commented Oct 15, 2018

The merge option of the publish-engage operation is used for
republishing metadata like dublincore catalogs or access control lists.

Merge works in a way that every previously published element which is
not in the new catalog is included in the merged media package. Or in
other words, only newly published catalogs are updated.

This behavior, while technically well defined and implemented correctly,
causes severe usability issues in some edge cases since a metadata
update can include an unexpected removal of an element.

Example 1 (Series Catalog)

Given an episode which is assigned to a series. Both dublincore/episode
and dublincore/series are published to engage. The user updates the
metadata in the admin interface, removes the series and republishes the
metadata.

Since the episode does not contain a series catalog any longer, the
element is not published which causes the merge to republish the old one
(a new catalog is not published after all). Hence you end up with a
published episode without a series which still has a series catalog.

Example 2 (ACL)

Given an episode with a published episode ACL. A user now removes the
episode ACL, modifies the series ACL and republishes the metadata to
update the access status. Note that switching from episode to series ACL
may happen automatically in some cases.

The publication of the episode ACL is not updated and the merge option
will republish the old access rules which override the less specific
series ACL. Hence the new access rules have no effect at all.

The Fix

This patch introduces a new merge-force-flavor option which can be used
to enforce the update of certain catalogs. By default this is done for
the dublincore catalogs and the ACLs which are usually part of a
metadata republication. This ensures the metadata are updated even when
a catalog is removed.

The default is set in a way that users will usually not need to specify
any other value. Additional values may be set for extended metadata
catalogs (for which the default does not make things worse though) or in
the case that someone republishes parts of the metadata which is rather
unlikely.

@lkiesow lkiesow added the bug label Oct 15, 2018

@karendolan

This comment has been minimized.

Copy link
Contributor

karendolan commented Oct 16, 2018

Hi @lkiesow this looks like a good solution for removal based on the absence of "dublincore/,security/" flavored element without having to retract everything and republish from scratch.

MH-13167, Republishing metadata does not update all metadata
The merge option of the `publish-engage` operation is used for
republishing metadata like dublincore catalogs or access control lists.

Merge works in a way that every previously published element which is
not in the new catalog is included in the merged media package. Or in
other words, only newly published catalogs are updated.

This behavior, while technically well defined and implemented correctly,
causes severe usability issues in some edge cases since a metadata
update can include an unexpected removal of an element.

Example 1 (Series Catalog)
--------------------------

Given an episode which is assigned to a series. Both dublincore/episode
and dublincore/series are published to engage. The user updates the
metadata in the admin interface, removes the series and republishes the
metadata.

Since the episode does not contain a series catalog any longer, the
element is not published which causes the merge to republish the old one
(a new catalog is not published after all). Hence you end up with a
published episode without a series which still has a series catalog.

Example 2 (ACL)
---------------

Given an episode with a published episode ACL. A user now removes the
episode ACL, modifies the series ACL and republishes the metadata to
update the access status. Note that switching from episode to series ACL
may happen automatically in some cases.

The publication of the episode ACL is not updated and the merge option
will republish the old access rules which override the less specific
series ACL. Hence the new access rules have no effect at all.

The Fix
-------

This patch introduces a new merge-force-flavor option which can be used
to enforce the update of certain catalogs. By default this is done for
the dublincore catalogs and the ACLs which are usually part of a
metadata republication. This ensures the metadata are updated even when
a catalog is removed.

The default is set in a way that users will usually not need to specify
any other value. Additional values may be set for extended metadata
catalogs (for which the default does not make things worse though) or in
the case that someone republishes parts of the metadata which is rather
unlikely.

@lkiesow lkiesow force-pushed the lkiesow:t/mh-13167-republishing-metadata branch from 04611c8 to a121d60 Oct 16, 2018

@lkiesow

This comment has been minimized.

Copy link
Member

lkiesow commented Oct 16, 2018

Updated the log message and also added the missing documentation.
@karendolan, will you take the review?

@karendolan karendolan self-assigned this Oct 16, 2018

@karendolan

This comment has been minimized.

Copy link
Contributor

karendolan commented Oct 22, 2018

Looks good to me. Removes force items as advertised.

@karendolan karendolan closed this Oct 22, 2018

@karendolan

This comment has been minimized.

Copy link
Contributor

karendolan commented Oct 22, 2018

@lkiesow can this still go into 5x?

@lkiesow

This comment has been minimized.

Copy link
Member

lkiesow commented Oct 22, 2018

I would say it can since it is a bugfix.
@karendolan, any reason why you just closed this pull request without merging?
Did you just hit the “Close and comment” by accident?
Or is there something wrong with this patch?

@karendolan

This comment has been minimized.

Copy link
Contributor

karendolan commented Oct 22, 2018

@lkiesow H, I hit close and comment by accident! I see It can be re-openned via this comment...

@karendolan karendolan reopened this Oct 22, 2018

@karendolan karendolan merged commit 65c0bfd into opencast:r/5.x Oct 22, 2018

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
@lkiesow

This comment has been minimized.

Copy link
Member

lkiesow commented Oct 22, 2018

I nearly did that as well a few times ;-)
Thanks for the review.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment