Bug 1007640 - Changed tag name is not updated in Tag tab for topics
Changed tag name is not updated in Tag tab for topics
Product: PressGang CCMS
Classification: Community
Component: Web-UI (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: pressgang-ccms-dev
Depends On:
  Show dependency treegraph
Reported: 2013-09-12 23:06 EDT by mmurray
Modified: 2013-09-22 17:34 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-09-22 17:34:18 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description mmurray 2013-09-12 23:06:46 EDT
Description of problem:
After changing the name of a tag, the tag name is not updated in Tag tab for topics.

Version-Release number of selected component (if applicable):
Build 201309081012
Build 201309131104 (Next)

How reproducible:

Steps to Reproduce:
1. I created a JBDS Release tag (tag id 554, tag name JBDS 7.0.0).
2. I added this tag to topics (e.g., 13331).
3. I then changed the tag name (to JBDS 7.0.z)
4. I then searched for the topics associated with the new tag name > all of the topics assigned under the old tag name were retrieved, all good (presumably since based on tag id which didn't change)
5. I picked one of the retrieved topics and viewed its tag > the tag name displayed is still the old name

Actual results:
The tag name displayed is still the old name

Expected results:
The tag name displayed should be the old name
Comment 1 Lee Newson 2013-09-13 00:19:33 EDT
This one is Matt's to answer since he designed it, but I'd class this as NOTABUG based on what I know. The reason is that the display is supposed to show the Topic as it was when it was saved, therefore changing the name afterwards shouldn't be reflected in the view.

In saying that however I do see where you are coming from and perhaps the latest version (the one that is editable) should display the latest data, or perhaps the Tag data shouldn't be audited in this case (ie the name will always be the latest version no matter what the revision is).
Comment 2 Matthew Casperson 2013-09-22 17:34:18 EDT
I'll leave this as NOTABUG, because it is the expect behaviour. Although it is not ideal in this situation, there are no ideal solutions at this point.

Technically, the reason why this happens is because:

1. The topic's basic details are loaded, which includes things like the XML and description.
2. The revision of the topic that was loaded is remembered.
3. When new tabs are loaded, like the tag tab, the topic's extra details are then loaded, using the revision to ensure that what is seen in the new tab reflects what was assigned to the topic when it was loaded in the UI.

Step 3 uses the revision to deal with cases where the topic may have have been changed by someone else in the time between loading the topic and then loading its extra details.

We have two options here:

1. Keep the current system. This means that what you see in the UI accurately reflects the state of the topic regardless of any changes in the background. It has the downside of not showing things like tag name changes, and also leaves it up to the server to work out how to deal with changes to collections in the UI (like added or removed tags) when those tags may have been added or removed in the background already.

2. Load the latest state of the child collections when the additional tabs are opened in the UI. This may mean that there is a discrepancy in the state of the information between tabs. On the other hand the user will be editing the latest state in a tab, and name changes will be visible.

A third option, although one that is not trivially implemented, is to introduce a locking system or some kind of notification system, so background changes are impossible to make, or will result in some kind of real time update or notification in the browser.

Note You need to log in before you can comment on or make changes to this bug.