Scenario: I edit a topic, which is included in three content specs. One of the specs is for a current book, and the other two are frozen. My topic change is relevant to the current spec and one of the frozen specs. Request: When I change the topic, I would like to be able to select which specs the new topic revision should apply to without having to edit the specs manually. Before editing the topic: Spec 1 (current) - topic at rev. 3 Spec 2 (frozen) - topic at rev. 1 Spec 3 (frozen) - topic at rev. 2 After editing the topic: Spec 1 (current) - topic at rev. 4 Spec 2 (frozen) - topic updated and frozen at rev. 4 Spec 3 (frozen) - topic at rev. 2
+1. This is useful particularly when we share topics across different products, and we need to concurrently develop / maintain topics in different content specs.
Initial pass added in 1.7-SNAPSHOT build 201406101643 Upon clicking save, the user is now presented with a tabbed dialog box. "Messages" contains the old save message view and "Content Specs" provides a list of checkboxes for Content Specifications that can be updated for the topic change. Notes: - The content specs list will only contain topics or info topics that contain a revision number. - The content specs list is group into product/version groups and sorted in alphabetical order to make it easier to find the content specs you want to update. - The content updated in the content spec will be the topic title and revision. - The save is done in a two step process. First the topic is saved and then any selected nodes will be updated. If the topic save fails (ie through a 401) then the nodes will not be altered. This however does mean that there are cases where the user may need to manually update the content spec because the topic pass worked, but the node pass did not. - The log message will be used for the topic save and content spec node save.
Cleaned up the UI a little more in 1.7-SNAPSHOT build 201406161145 which has now been deployed to the test/development server.
The text "Select which Content Specifications this change should be applied to" should be changed to "Select the content specifications to update with this topic's new revision number."
The save box is collapsed in Firefox when you do the following Edit a topic assigned to spec at a fixed revision Save it, selecting a spec to update Edit and save it again The save box is collapsed See the attached image for an example of what this looks like
Created attachment 909280 [details] Collpased save box in Firefox
Info topics do not list specs that they are assigned to.
Confirmed that I could update regular topics, Abstract, Revision History, Legal Notice, Author Group and Feedback topics revision numbers in a spec when saving the topic.
When a topic is saved and tried to update a spec that no longer references it, a generic error about missing primary keys is displayed. 1. Open a topic that is referenced by a spec at a specific revision 2. Edit the spec to remove the reference to the topic 3. Edit and save the topic, selecting the spec edited in step 2 to be updated 4. Primary key for csnode no longer exists, so we get a generic error The list of content specs should be retrieved when the save box is shown to reduce the likelihood of this happening, and if the spec could not be updated the error should be caught and displayed to the user with a message like: "Content specification 12345, which you selected to update with this topic's new revision number, was modified by another user and could not be updated. Please review 12345 and apply this topic's new revision number manually."
Created attachment 909285 [details] Doubled spec list after failed save
After a save to a topic failed (it looked like the connection to the dev server timed out) I ended up with each content spec listed twice in the save box. See the attached screenshot to see what it looked like.
(In reply to Matthew Casperson from comment #4) > The text > > "Select which Content Specifications this change should be applied to" > > should be changed to > > "Select the content specifications to update with this topic's new revision > number." The text you want this changed to is not correct, as the title will be updated as well. So I believe what I had makes more sense still.
> Confirmed that I could update regular topics, Abstract, Revision History, Legal Notice, Author Group and Feedback topics revision numbers in a spec when saving the topic. Actually it looks like legal notices don't provide the spec list.
> Actually it looks like legal notices don't provide the spec list. Never mind, that was me not setting the revision. However, when you update a legal notice the "Legal Notice" text is replaced with the title of the topic.
(In reply to Matthew Casperson from comment #7) > Info topics do not list specs that they are assigned to. Fixed. This was also affecting the render window, as the query being used wasn't looking for info topic nodes. (In reply to Matthew Casperson from comment #11) > After a save to a topic failed (it looked like the connection to the dev > server timed out) I ended up with each content spec listed twice in the save > box. See the attached screenshot to see what it looked like. Fixed, the reset() method wasn't being called on failed connection attempts. (In reply to Matthew Casperson from comment #8) > Confirmed that I could update regular topics, Abstract, Revision History, > Legal Notice, Author Group and Feedback topics revision numbers in a spec > when saving the topic. This was actually updating the "title" field for metadata nodes, which is what caused the issue in BZ#1110039. This has now been fixed so that it only updates titles for regular topics and initial content topics. (In reply to Matthew Casperson from comment #5) > The save box is collapsed in Firefox when you do the following > > Edit a topic assigned to spec at a fixed revision > Save it, selecting a spec to update > Edit and save it again > The save box is collapsed > > See the attached image for an example of what this looks like This is also reproducible on Chrome, you just need to press cancel with the content specs tab open. Anyways this was caused by the way the height is calculated for the tab panel. Because the height was being calculated without it being visible due to the reset command, it was collapsing it. As such I've now taken this into account when re-displaying the window.
*** Bug 1110039 has been marked as a duplicate of this bug. ***
(In reply to Matthew Casperson from comment #9) > When a topic is saved and tried to update a spec that no longer references > it, a generic error about missing primary keys is displayed. > > 1. Open a topic that is referenced by a spec at a specific revision > 2. Edit the spec to remove the reference to the topic > 3. Edit and save the topic, selecting the spec edited in step 2 to be updated > 4. Primary key for csnode no longer exists, so we get a generic error > > The list of content specs should be retrieved when the save box is shown to > reduce the likelihood of this happening, and if the spec could not be > updated the error should be caught and displayed to the user with a message > like: > > "Content specification 12345, which you selected to update with this topic's > new revision number, was modified by another user and could not be updated. > Please review 12345 and apply this topic's new revision number manually." Fixed, this list is now loaded when save is clicked. Also as mentioned on IRC, without saving each content specification one at a time which could be fairly slow for a list of specs, we'll need to use a generic error message. As such if the content spec saving fails, then the error message displayed will be: A Content Specification which you selected to be updated, was modified by another user and could not be updated. Please review the selected content specs and apply this topic's new revision number manually.
Changes applied in 1.7-SNAPSHOT build 201406171057 This version is now live on the test/development server.
Verified that the list of specs is generated when the save button is clicked, and that conflicts (i.e. the spec removing the topic after the topic save button was clicked but before the topic save was committed) displays an appropriate warning. Also verified that the save box does not collapse between saves.
Verified that updating Revision History, Author Group, Feedback and abstract topics works as expected.
Info topics don't have their revision details updated.
(In reply to Matthew Casperson from comment #21) > Info topics don't have their revision details updated. This was actually another bug altogether. Info nodes weren't being updated by the rest server. This has been fixed and uploaded to the server, so moving this back to ON_QA.
Confirmed that info topics are now updated.
Specs that are currently invalid are listed as being available to be updated when a topic is saved. I would say that these should be disabled in the save dialog list with some kind of label to indicate that they are not valid.
Confirmed that invalid specs are now disabled and identified in the save dialog box.
Matt beat me to it, but this was fixed in 1.7-SNAPSHOT build 201406180829 The list will now append " - Invalid" and make the font red for invalid specs. I also fixed an issue that was causing specs to be displayed multiple times.