Reimplement the "Validation Selection" use case.

As per the deprecation notice and list in the release announcement for Gem Release 0.12.0.

As specified in Issues #71 and #82, and PR #84, per the newly-created spec.

The fact that no standalone PR exists matching Issue #71 indicates how far into the weeds we'd gone for some time there in the 0.13.0-0.15.0 timeframe, when we wound up having to recreate the past to discover the present and build towards a future.

This is marked as a prerelease Gem only because, to the best of our knowledge, it has yet to be used in a project that itself is in production status. When that changes, we will release Version 1.0.0 of the Gem based on the latest prerelease at that time, and that new version will not be marked as a prerelease Gem.

Reimplement "Retrieve A Single Article" Use Case.

As per the deprecation notice and list in the release announcement for Gem Release 0.12.0.

As specified in Issue #70 and PR #76, per the newly-created spec. Issue #82 was final cleanup.

This is marked as a prerelease Gem only because, to the best of our knowledge, it has yet to be used in a project that itself is in production status. When that changes, we will release Version 1.0.0 of the Gem based on the latest prerelease at that time, and that new version will not be marked as a prerelease Gem.

Update dependencies, using extracted prolog-use_cases-register_new_member` Gem.

As port of our continuing process to have reproducible builds of our Gems (see the opening comment of Issue #77), prolog-use_cases 0.14.1 will replace the to-be-yanked 0.14.0. We now use, and will continue to use, current versions of all Gem dependencies as this and future releases are built.

The release message for prolog-use_cases 0.14.0, titled Reimplement "Register a New Member" Use Case, was as follows:

As per the deprecation notice and list in the release announcement for Gem Release 0.12.0; three more to go.

Reimplement "Register a New Member" Use Case.

As per the deprecation notice and list in the release announcement for Gem Release 0.12.0; three more to go.

Reimplementation of PublishNewArticle Use Case.

As per the deprecation notice and list in the release announcement for Gem Release 0.12.0; four more to go.

Implement "Summarise Own Submitted Proposals" Use Case.

This Use Case allows an authenticated Member to query the status of all Contributions that he has Proposed to Articles within the system. The Result value object returned from the #call method contains a :contributions attribute, which is a Hash with keys :accepted, :proposed, and :rejected. The value associated with each of these keys is an Array containing entities corresponding to each Proposal submitted by the Member based on each Proposal's current status.

Deprecation Notice for Early Use Cases

During the development of this release, inconsistencies with current use-case conventions were noted in several previously-implemented Use Cases (any Use Case implemented prior to the most recent updates to the Propose Edit Contribution Use Case). These will be re-implemented over the next several Gem releases. Any code using these Use Cases as presently implemented will break when run against these new releases, without change to the utilising code.

These Use Cases are:

Use Case Class	First Implemented In	Expected to be Reimplemented In	Reference Issue
PublishNewArticle	0.3.0	Implemented in 0.13.0	#68 and PR #73
RegisterNewMember	0.2.0	0.14.0	#69
RetrieveArticle	0.4.0	0.15.0	#70
ValidateSelection	0.8.0	0.16.0	#71
SummariseContent	0.1.0	0.17.0	#72

As a reminder, Gem Releases 0.5.0 and 0.6.0 introduced no new Use Cases; they dealt with underlying implementation-support code and are therefore not known to be affected by these changes.

Implement "Accept/Reject a Single Proposed Contribution"

With the supporting use case "Authorise Contribution Response", which must be completed prior to calling "Ac­cept a Single Proposed Contribution" or "Reject a Single Proposed Contribution".

These use cases implement the (very simple at present) use-case logic for an Author's accepting or rejecting a contribution which has been proposed to an article. In no event do these use cases modify external state (such as the contents of persistent storage); on successful completion, they merely indicate what changes (an updated Arti­cle entity and a new contribution entity) should be so persisted.

The basic usage scenario for non-Author contributions goes something like this:

1. A Member other than the author proposes a contribution to a specific article by a specific author;
2. The Author logs in and views his dashboard or other list of proposed contributions;
3. As part of composing that UI for the Author, a list of un-responded proposed contributions for all articles by the Author is queried (the "raw list" of proposals);
4. For each proposal in the raw list, the "Authorise Contribution Response" use case is called.
   1. A successful result will provide an Article entity to the caller, which represents the state of the Article, in­cluding proposed-contribution marker tag pairs, as of the time that the use case was called;
   2. An unsuccessful result will return a list of error identifiers to the caller, who is responsible for any further processing (such as UI reporting of the errors).
5. The UI is presumed to present features which allow the logged-in member (the Author) to indicate whether he wishes to accept or reject a specific proposal. The UI is expected to offer some means of entering a response message to accompany a specific acceptance or rejection; the use case makes no assumptions about the content or form (including markup language, if any) used within that response text;
6. When the Author indicates (through the UI) that a specific proposal is to be accepted or rejected, the appropri­ate use case is called (the "responding" use case). There is no conditional logic in these use cases; any error detection, such as invalid state, is the responsibility of "Authorise Contribution Response".
7. The Result value object returned by the #call method of the responding use case has
   1. the following fields/attributes:
      1. entity; an instance of a Entities::Contribution::Responded subclass with attributes that identify the related article and proposal, the response text provided by the article author, the timestamp when the author responded to the proposal, and a unique identifier for the entity
      2. errors; this should always be an empty Array;
      3. original_content; the previously-existing article body content that had been proposed for replace­ment by the proposal acted on by this use-case invocation;
      4. proposal; an entity representing the proposal; used throughout this workflow; and
      5. response; a Symbol with either the value :accepted or :rejected, as appropriate.
   2. the following methods
      1. #accepted? and #rejected?; convenience methods wrapping the :response attribute;
      2. #responded? this will always return true (it returns false on a propose-contribution use-case result instance);
      3. #success?; this should always return true if the errors attribute is empty (see above);
8. At this point, the UI and delivery-application logic have sufficient information to present the result successfully and to proceed to the next suitable action.

This is a fairly complex network of cooperating objects; the original plan for the 0.11.0 Gem release anticipated most of this occurring within a single, complex use case. We would argue that this is a significant improvement.

Implement "Summarise Articles by Author" Use Case.

Allows any user to query for a list of Articles Published by a specific, single Author. When executed while that Author is the current user, also includes any Draft Articles created by that Author.

Implement "Query Proposed Contributions to Single Article" Use Case.

Allows a Member who has previously Published one or more Articles to query (and, by implication, be presented with) any Contributions which have been Proposed (by other Members) to a single such Article.

"Validate Selection" use case.

The "Validate Selection" use case does not persist anything and does not modify any existing data. It simply verifies, for a specified Article and proposing Member, that a selection with specified endpoints and proposed replacement content would result in a valid (Edit) Contribution Proposal.

Along the way to this release, we found ourselves on a very high cliff and promptly fell off. We were delayed by the poor health of a critical, senior, team member whose lack of effective availability impacted delivery. We were delayed by a long foray into the corner cases of HTML-to-Markdown-to-HTML conversion and establishing that that was simply too fragile and unreliable for our use, falling back to relying on HTML for Article body content and Contribution Proposed Content. We fell from several other, more technically arcane, cliff edges and picked ourselves up again.

We want our month back.