Closed
Bug 632084
Opened 13 years ago
Closed 13 years ago
[Demo Studio] Make demo deletion more forgiving
Categories
(developer.mozilla.org Graveyard :: Demo Studio / Dev Derby, defect)
Tracking
(Not tracked)
VERIFIED
FIXED
0.9.5
People
(Reporter: lorchard, Unassigned)
References
Details
chowse suggested that demo deletion could be made more forgiving, since the submission of a demo involves the assembling and upload of a lot of materials. Currently, there's a confirmation dialog before deletion. However, we could also offer the ability for authors to hide demos before deletion, thus allowing an un-doable option that removes a demo from public view. There is currently the ability to hide and show demos, but it's reserved for site editors / admins.
Reporter | ||
Updated•13 years ago
|
Target Milestone: --- → 0.9.4
Comment 1•13 years ago
|
||
This is a major feature that we desperately need. I would like to get this in for 0.9.5. It would be awesome to allow authors to submit their demos as "hidden" until they have a chance to test them. That way we don't have people uploading, deleting and re-uploading all the time if there are issues (and losing all their demo details in the process). So basically I think we should do 2 things: 1. Submission are "hidden" by default, but viewable by the author.. and they have to confirm/enable the demo before it is public. 2. Offer an option to "hide" a demo both in the demo editor and also in the delete demo dialog, in case they don't want to delete it completely.
Target Milestone: 0.9.4 → 0.9.5
Updated•13 years ago
|
Severity: enhancement → major
Updated•13 years ago
|
Assignee: nobody → lcrouch
Comment 2•13 years ago
|
||
One implication: allowing users to un-hide their demo's means admins can't hide spam/trash demos - they will have to delete them. Jay, you okay with that?
Reporter | ||
Comment 3•13 years ago
|
||
(In reply to comment #2) > One implication: allowing users to un-hide their demo's means admins can't > hide spam/trash demos - they will have to delete them. > > Jay, you okay with that? Another option is to introduce a second kind of "hidden" flag that's user-controllable, but is overridden by the current "hidden" flag. Might be confusing / awkward to code.
Comment 4•13 years ago
|
||
(In reply to comment #2) > One implication: allowing users to un-hide their demo's means admins can't > hide spam/trash demos - they will have to delete them. > > Jay, you okay with that? No, that's not ok. I would like to have admin rights that can override any state the user puts their demos in. Hope that's possible.
Comment 5•13 years ago
|
||
Dang I just finished changing the 'hidden' field to support this as you made that comment. :) I can add a 'censored' field that will work like 'hidden' did previously - admin-only field that will trump the 'hidden' value. Sound good?
Updated•13 years ago
|
Assignee: lcrouch → mozbugs.retornam
Status: NEW → RESOLVED
Closed: 13 years ago
Keywords: qawanted
Resolution: --- → FIXED
Comment 6•13 years ago
|
||
Should be able to test this on stage9 now. Here are the rules: * 'hidden' demos are visible to site admins and the demo author (on their demos/profile/<username> page) * demos default to 'hidden' unless/until the author un-hides them on the new/edit submission page * 'censored' demos are visible to site admins only in the /admin/ interface. * admins can censor demos to hide them from the whole site - not even their authors can see them
Comment 7•13 years ago
|
||
qa-verified https://developer-stage9.mozilla.org/en-US/demos/detail/bar-bar I was able to hide and then unhide the bar-bar demo
Comment 8•13 years ago
|
||
verified fixed https://developer.mozilla.org/en-US/demos/
Status: RESOLVED → VERIFIED
Comment 9•13 years ago
|
||
verified fixed for hiding and unhiding demos
Assignee | ||
Updated•12 years ago
|
Version: MDN → unspecified
Assignee | ||
Updated•12 years ago
|
Component: Demos → Demo Studio / Dev Derby
Updated•4 years ago
|
Product: developer.mozilla.org → developer.mozilla.org Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•