Closed Bug 489874 Opened 15 years ago Closed 15 years ago

Staging copies are automatically created in no category

Categories

(support.mozilla.org :: Knowledge Base Software, task)

Product:
support.mozilla.org
Component:
Knowledge Base Software
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: cilias, Assigned: paulc)

References

Details

(Whiteboard: tiki_bug, tiki_upstreamed) 

Had to test this on prod, because of bug 489839. If I create a new article in the staging area, then move it to the KB, the staging copy is automatically created (which is good), but it is not created in the staging area ("Staging area" is not in the breadcrumb).
Taking this, as it's related to bug 489210. Hopefully this will take care of bug 489210.
Assignee: nobody → paul.craciunoiu
Target Milestone: --- → 1.2
I'm still working on figuring out how this works. Eric, are you familiar with the exact piece of code that creates the staging copy automatically?
So it seems that there are certain functions to pick up the categories and content for first-time editing of staging articles, but it doesn't seem that they are actually created. Instead, the information is grabbed from the non-staging copy. I tested this by creating a page in KB category, and I got:
https://support-stage.mozilla.org/en-US/kb/*testpaul1
redirects to https://support-stage.mozilla.org/en-US/kb/testpaul1 (non-staging)

So we should turn this bug around to either:
a) automatically create the staging copy
b) invalid (since articles are not actually created)
c) don't make it seem like articles are being created? :)

I sort of like the current behavior but I agree it's confusing. The best UX approach would be a), but it will certainly increase loading time for tiki-editpage, which already takes a while... What do people think?
Add some text ie option c).    Cheng will provide wording.
Cheng's suggestion was "This staging article will be created when this page is first saved."
Patch to come.
Oops. Sorry for confusing everyone! After rereading the first comment, I followed the steps exactly and was able to reproduce it...

However, on my local and on staging, this doesn't seem to happen. So maybe it's fixed?
Let's see if it still happens on prod after the 1.2 push.
Target Milestone: 1.2 → 1.3
Chris, Cheng: can you check if this still happens on prod? Also on staging?
https://support.mozilla.com/en-US/kb/*Upgrading+to+Firefox+3%C2%B75 seems to have been created in the staging area.

https://support-stage.mozilla.org/en-US/kb/*test+bug+489874?bl=n also seems to have been created in the staging area.
(In reply to comment #9)
So... This means that this bug doesn't happen anymore?
Marking this fixed as a result of the 1.2 push. If it happens again, please reopen.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Staging copy created in staging area on https://support-stage.mozilla.org/en-US/kb/*testtmz so marking verified.
Status: RESOLVED → VERIFIED
Whiteboard: tiki_bug
Whiteboard: tiki_bug → tiki_bug, tiki_depend
Should be fixed as part of other upstreams
Whiteboard: tiki_bug, tiki_depend → tiki_bug, tiki_upstreamed
You need to log in before you can comment on or make changes to this bug.