| Summary: | Changed tag name is not updated in Tag tab for topics | ||
|---|---|---|---|
| Product: | [Community] PressGang CCMS | Reporter: | mmurray |
| Component: | Web-UI | Assignee: | pressgang-ccms-dev |
| Status: | CLOSED NOTABUG | QA Contact: | |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 1.1 | CC: | lnewson, mcaspers |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-09-22 21:34:18 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
mmurray
2013-09-13 03:06:46 UTC
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). 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. |