-
Notifications
You must be signed in to change notification settings - Fork 506
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature: Replace "visible to" with Published/Under review/Archived #1281
Comments
@brandonrosage @jshorland what should the default status filter be? show everything? or just published? or published+under review? |
Running stats on number of posts published with custom 'published_to' values. |
@jshorland this is deployed to ushahididev.com - can you test there? it covers a lot of areas of the UI To test:
|
QA FAILED. Filter by status:
Bulk actions:
Post edit sidebar shows created/updated dates:
|
Assigning back to you, @rjmackay -- failed QA. |
With all of our filters, no filter = return anything. The UI doesn't really match this but I'm not sure what it should do. Returning an empty list is pointless.. I'll investigate other issues. |
@jshorland can you put these back into "In Development" column when they fail QA? |
I can't reproduce this. We refresh the listing after a 'mark all' but its working fine for me.
Can't reproduce this at all |
I'm not 100% clear: who can see archived posts? I'm going to assume everyone but we can fix that later if that wasn't desired. @brandonrosage @jshorland |
@rjmackay My intent is for “Archived” posts’ visibility to be identical to that of posts that are “Under Review.” If nothing else, this keeps things simple. Until we learn of a user need to expose “Archived” posts publicly, I think we should treat them as posts the deployer explicitly wants to “retire” from the outward-facing dataset, without being forced to either delete or demote them back to “Under Review." |
Passes QA! Moving to done. |
Changes:
Background: #1263 (comment)
The idea is basically this: From a user-facing point of view, let's scrap "Who can see this," and instead double down on "Post status." A post that's saved within a deployment is either:
Any user needs around the fine-tuned visibility of posts will therefore have to be constrained to Role configuration. This effects, well, a lot of screens. But here's the jist of it:
Postcards
Anywhere you see a postcard (including as a map popup, in the Timeline, and post detail), you'll see a consistent email-like treatment of its "status."
Example:
In the top-left of the postcard, a status indicator is displayed with one of the three status icons. If it's "Under review," it glows yellow (similar to an "unread" indicator), suggesting it requires attention. Otherwise, it's a subtle icon.
If you mouseover it, a short description of the status appears:
You can, of course, change a post's status when you edit it. But you can also change its status from:
The status-related actions available correspond to the post's current status.
Map & Timeline
The tools we provide for mashing up the data you're looking are naturally affected by this.
the toolbar's more exhaustive "Filters" control also includes this feature:
Post edit
The example I've staged also assumes the user can edit the post time (and author). But you can see there's a very visible control there for changing the post's status:
The text was updated successfully, but these errors were encountered: