So, you want to learn more about the
Let us begin our magical mystery tour.
( dw_suggestions: A User's Guide )
And that is Everything You Ever Wanted To Know About
| You're viewing Create a Dreamwidth Account Learn More | Reload page in style: light |
Title:
In Case of Emergency write-only access
Area:
Posting
Summary:
Give limited access to a small number of other DW users to make posts on your behalf, with restrictions. [New feature suggestion]
Description:
What I want is a write-only function where (say) I nominate (say) you as an In-Case-of-Emergency poster for if I'm (say) ill in hospital; you can then post to my DW, but without any ability to see locked entries, modify settings, modify circle, or anything else; furthermore there'd be a prominent heading applied to any posts you made saying "posted by [YOURUSERNAMEHERE]", so impersonation wouldn't be possible. I can always delete or modify the posts that you have made on my behalf. Crossposting would work as normal.
Other methods:
a) implement this as an external website, using OpenID to verify you and store my password. Requires competently-run, secure, trustworthy third-party site. Need to remember to log in to that site every time I change my DW password.
b) give you my password. Trusts you to keep it safe, not lose it, and I have to tell you every time I change it. Allows impersonation and account-modification.
c) Give you my post-by-mail credentials. As above, but doesn't allow impersonation, eats an address slot per person, and only works for paid/permanent users.
d) The one that usually gets done these days - you making unlocked posts and hoping that enough of my circle see the post and that I don't have anyone I'd rather didn't know. This has the advantage of being simple, but is really not an effective solution to the problem.
Considerations:
I would favour the poster having the ability to post using any publicly-visible security setting that would let the poster see the post (at least "access-list-only" or "public") and possibly edit posts that they have themselves made (but not remove the header saying that the post was made by them). I don't see much need for anything beyond that; they can comment on posts as themselves.
I would envision small number of people given these posting privileges, though I don't have a particular limit in mind, and I don't see a really good reason to put a hard-limit on things.
There's always a risk that someone will post a malicious or spurious report, but really they can do that *anyway* via method d), it's called lying, and it's a social problem that is solved by only authorizing people that you trust not to do that kind of thing.
This suggestion:
Should be implemented as-is.![]()
![]()
29 (53.7%)
Should be implemented with changes. (please comment)![]()
![]()
12 (22.2%)
Shouldn't be implemented.![]()
![]()
2 (3.7%)
(I have no opinion)![]()
![]()
11 (20.4%)
(Other: please comment)![]()
![]()
0 (0.0%)
Title:
Password protect posts so non-DW friends can be included
Area:
entries
Summary:
Add an additional security option between "public" and "friends" where the post is viewable to anyone with the correct password. This would allow users to include friends without DW accounts in non-public posts.
Description:
It's been a few years since this was last suggested ( http://dw-suggestions.dreamwidth.org/14
WordPress has a password protected post option ( http://en.support.wordpress.com/posts/p
A modification suggested in the comments last time would also include the option to make the post (including password prompt) viewable only by direct link.
Having it not only gives you greater control over who outside the site can see your content, it might just pull in new users. They'd come to the site to read your posts, see how it works, and maybe just be tempted to try it themselves.
So it works like this:
Between "Public" and "Access List," there would be an additional security option labeled "Password Protected." When you select that, you enter a password. When the post goes up, you have what amounts to a cut tag hiding the post's contents (including comments) until the reader enters the correct password. An additional sub-option (available via checkbox, perhaps?) would allow you to make even the password prompt viewable via direct link only. Crossposts would link back to DW, where readers would be prompted for the password.
This suggestion:
Should be implemented as-is.![]()
![]()
7 (14.9%)
Should be implemented with changes. (please comment)![]()
![]()
7 (14.9%)
Shouldn't be implemented.![]()
![]()
23 (48.9%)
(I have no opinion)![]()
![]()
10 (21.3%)
(Other: please comment)![]()
![]()
0 (0.0%)
Title:
Filter entries by tags AND security level
Area:
tags, access filters
Summary:
It would be great to have a straightforward way to filter someone's current entries by both tags and security level, at the same time.
Description:
Currently, you can filter someone's entry by tag, e.g. user.dreamwidth.org/tag/banana would display all User's entries tagged 'banana' .
You can also filter it by security level, e.g. user.dreamwidth.org/security/public . This would display all User's current public entries.
But there is no obvious way (AFAIK - please correct me if I'm wrong) to do both at once, e.g. if you could use user.dreamwidth.org/security/public/tag/b
This would be useful for if you need to quickly check if something a person told you is public knowledge before running your mouth about it in your own journal ("Looks like User's banana posts are all access-locked. I'd better ask them first before posting publicly about meeting them at the banana festival!") or, potentially, for checking your own security levels ("I try to make sure my posts on lutefisk are in an opt-in access group for my fellow lutefisk enthusiasts, but I think I might have forgotten to filter a few. Let me just check user.dreamwidth.org/security/access/tag/l
Potential drawbacks:
- it might hit the database too hard? IDK.
- people have custom security groups with / in the title, and people have tags with / in the title, and this would make it more difficult to form a URL, not matter whether it's /security/level/tag/tagname, or /tag/tagname/security/level.
This suggestion:
Should be implemented as-is.![]()
![]()
14 (40.0%)
Should be implemented with changes. (please comment)![]()
![]()
5 (14.3%)
Shouldn't be implemented.![]()
![]()
0 (0.0%)
(I have no opinion)![]()
![]()
15 (42.9%)
(Other: please comment)![]()
![]()
1 (2.9%)
Title:
Provide OPML feed import/export options
Area:
Reading Page
Summary:
Providing OPML support would allow for a standards-compliant improvement in the ability to manage RSS/Atom feeds on user's Reading Pages.
Description:
DW offers users the ability to add and manage feeds of RSS/Atom sources as a "Reading Page" feature, effectively a Web-based Newsreader.
Management of feeds (adding, removing, organizing, modifying) is done through a series of Web interfaces, principally http://www.dreamwidth.org/feeds/, http://www.dreamwidth.org/manage/ci
Some of these tasks, as well as archival and distribution or sharing of lists, would be much easier if feeds could be exported in OPML format, a standard data exchange format for RSS and Atom feeds used by many feed readers. Providing import/export for Dreamwidth feeds would avoid a significant amount of front-end and back-end redesign to improve the feeds management process while providing for much greater user flexibility and ease in management.
https://en.wikipedia.org/wiki/Opml
This is *not* a request to allow re-syndication of feeds (though people would be able to share the feeds lists they subscribe to). E.g., request #9210 is an entirely different matter: http://dw-suggestions.dreamwidth.org/92
Among challenges:
- DW feeds are based on local feeds, not the original source. Translating between these would have to be provided for.
- Allowing both feeds *and* filters to be exported/imported would be most useful. This would require some design and planning.
There's an earlier (2009) suggestion which mentions OPML though it's not clear where it is access or what the files contain: http://dw-suggestions.dreamwidth.org/13
This suggestion:
Should be implemented as-is.![]()
![]()
6 (18.8%)
Should be implemented with changes. (please comment)![]()
![]()
0 (0.0%)
Shouldn't be implemented.![]()
![]()
1 (3.1%)
(I have no opinion)![]()
![]()
25 (78.1%)
(Other: please comment)![]()
![]()
0 (0.0%)
Title:
Admin posts: connect 'as admin' post with 'admin' icon keyword
Area:
icons, communities, entries, comments
Summary:
If one has an icon with the 'admin' or '_admin' keyword automatically select it when making a post or a comment as an admin (I meant when you tick the 'as admin' checkbox).
Edit: looks like _admin or something even more unusual would be better as there would be a good chance *only* users who wanna have this would.
Description:
Not sure automatic selection is possible in which case it could be automatically use (so you wouldn't even have to select an icon the way it works at support). The latter could be problematic if you wanted to use a different icon for once.
This suggestion:
Should be implemented as-is.![]()
![]()
9 (26.5%)
Should be implemented with changes. (please comment)![]()
![]()
1 (2.9%)
Shouldn't be implemented.![]()
![]()
2 (5.9%)
(I have no opinion)![]()
![]()
21 (61.8%)
(Other: please comment)![]()
![]()
1 (2.9%)
Title:
Add "Edit entry again" to Journal entry was edited Success page
Area:
entries
Summary:
Add "Edit entry again" to Journal entry was edited Success page "From here you can" options.
Description:
The page Success when one has edited a journal entry is:
<blockquote>
Success
Journal entry was edited.
From here you can:
* View this entry
* View your journal entries
* Manage your journal entries
</blockquote>
Having another option be "Edit this entry again" would be handy when one is making a number of changes to the same entry in a row, or saved and immediately realised another edit to make.
This suggestion:
Should be implemented as-is.![]()
![]()
53 (88.3%)
Should be implemented with changes. (please comment)![]()
![]()
0 (0.0%)
Shouldn't be implemented.![]()
![]()
0 (0.0%)
(I have no opinion)![]()
![]()
7 (11.7%)
(Other: please comment)![]()
![]()
0 (0.0%)
Title:
add youtube as a site recognized by the account-linking tag
Area:
entries
Summary:
see title
Description:
I'd like to be able to link to youtube accounts with the DW tag. Currently it's not possible because youtube uses /user and not /users.
This suggestion:
Should be implemented as-is.![]()
![]()
26 (57.8%)
Should be implemented with changes. (please comment)![]()
![]()
0 (0.0%)
Shouldn't be implemented.![]()
![]()
3 (6.7%)
(I have no opinion)![]()
![]()
16 (35.6%)
(Other: please comment)![]()
![]()
0 (0.0%)
Title:
A way to easily copy and paste Create Entry setting preferences
Area:
Posting
Summary:
It would be nice if an option could be implemented, once the new Create Entries page is out of beta, to quickly and easily copy-and-paste one's setting preferences.
Description:
The new Create Entries page, which is currently in beta, has a lot of different options to customize the page to a user's liking. But for users who have multiple accounts, for RPing or other reasons, remembering those options and applying them the same way to several different accounts might be troublesome. I'm opted-in to the beta and I have the page set up in a way I like for this account, but when I switch to other accounts it's jarring because things aren't the same way. I could manually set them all up in the same way (and I probably will after I finish posting this suggestion, since it's on my mind now), but it would be nice to have a way to rapidly apply all of my preferences at once.
My suggestion is to have some sort of button you can click somewhere, maybe on one of the Manage Account tabs, to generate a textual list of your preferences that you can copy, and a textbox somewhere else on the same page where you can paste those preferences and automatically apply them. (Once you've logged into the account you want to apply them on, of course.) The list would read something like:
entry_field:column;show_panels:entry-lin
Obviously that's just garbage spewed out by someone who doesn't have the faintest clue how this stuff works, so I wouldn't expect it to look exactly (or even necessarily remotely) like that. But something along those lines!
It would also be nice for users who have a specific way they want their page layout to look, but feel like temporarily changing it either to see if there's another way they like better, or perhaps for Support troubleshooting; they could save their preferences and easily revert to them this way.
This suggestion:
Should be implemented as-is.![]()
![]()
8 (22.2%)
Should be implemented with changes. (please comment)![]()
![]()
6 (16.7%)
Shouldn't be implemented.![]()
![]()
3 (8.3%)
(I have no opinion)![]()
![]()
19 (52.8%)
(Other: please comment)![]()
![]()
0 (0.0%)
Title:
Comment Threads: Full Collapse
Area:
Comment sections
Summary:
Comment ignore function: implement an option which allows comments and associated threads to be fully collapsed and hidden, showing a placeholder that says "This comment is hidden, click to unhide it".
Description:
Collapsable comment threads:
Allow users to collapse and hide individual comments + threads, effectively giving users the option to put comments and their associated threads "on ignore". Once hidden, the comment will be replaced with generic placeholder text that reads "This comment is hidden, click to unhide it". The comments can be unhidden with the press of a button.
This would be useful the event that a thread becomes long and begins stretching the page, requiring excessive amounts of scrolling to reach the bottom, or if the comment contains an image or discussion content that a user doesn't want to see.
This option is easily implemented with a javascript function, and already exists on certain *chan boards.
Thanks in advance for your consideration!
This suggestion:
Should be implemented as-is.![]()
![]()
19 (59.4%)
Should be implemented with changes. (please comment)![]()
![]()
0 (0.0%)
Shouldn't be implemented.![]()
![]()
4 (12.5%)
(I have no opinion)![]()
![]()
8 (25.0%)
(Other: please comment)![]()
![]()
1 (3.1%)
Title:
Control emailed image display sizes
Area:
entries, files
Summary:
In the department of more options, a set-and-forget page-saver for emailed images. Set the maximum dimensions you'd like to display unaltered for attached images, and have the included images automatically use that size version with a link to the full size.
Description:
Modern smartphones take some rather large pictures sometimes. If your post-by-email use case involves a smartphone and pictures, there's the risk of warping your circle's reading pages if you forget to include a <cut> at the end of the message.
One part of the image-handling backend is going to be the resizer, which will generate appropriately sized versions of emailed-in images for thumbnails and not breaking reading pages.
Upon receiving an image attachment, the back end currently saves it somewhere in the user's /file/ area, and appends the relevant <img src="exampleusername.dreamwidth.org/file/1
When activated, my proposed change would cause the back end to save the image attachment somewhere in the user's /file/ directory, and append <a href="http://exampleusername.dreamwidth.o
How to define this? It would be lovely if I could go in somewhere in my post-by-email settings and declare that I would like to default to images no larger than (pick from a menu of dimensions). Then I would rest secure in the knowledge that should I ever forget, my circle would be safe from my carelessness, and should they still like to view the larger version, there would be a link.
This suggestion:
Should be implemented as-is.![]()
![]()
27 (75.0%)
Should be implemented with changes. (please comment)![]()
![]()
0 (0.0%)
Shouldn't be implemented.![]()
![]()
0 (0.0%)
(I have no opinion)![]()
![]()
9 (25.0%)
(Other: please comment)![]()
![]()
0 (0.0%)
Title:
Differentiating inbox notifications from suspended users
Area:
inbox, suspension
Summary:
Inbox notifications should differentiate what kind/where a message from a suspended user originated.
Description:
Currently inbox notifications involving suspended users all have a very uninformative "(Reply from suspended user)" giving the username of the suspended user.
It would be good to at least differentiate between different types of notification (comment, private message -- poll vote? birthday notification?). It would be extra-fancy if there was more information, like, was it a comment in your own journal, a reply in another journal or community (when that goes through the inbox), a comment on something you're tracking, or other information to better contextualize what's going on.
Turns out it's startling when someone with an entirely locked journal doesn't realize they have private messages turned on, they get a message from a spammer who is subsequently suspended, and they have a sudden moment of alarm wondering if there was some kind of security incident. Situations like this could be better avoided with more context for inbox messages.
This suggestion:
Should be implemented as-is.![]()
![]()
33 (91.7%)
Should be implemented with changes. (please comment)![]()
![]()
0 (0.0%)
Shouldn't be implemented.![]()
![]()
1 (2.8%)
(I have no opinion)![]()
![]()
2 (5.6%)
(Other: please comment)![]()
![]()
0 (0.0%)
Title:
Add a new HTML tag to allow navigation across multiple entries in a single tag
Area:
tags, entries
Summary:
Across the web, multi-part series often have a section of navigation links to enable readers to find their way across multiple pages, articles, etc... First/ last page, prev/ next, list all pages/ articles... there's lots of different ways to make it easier for the reader. What I propose is to add a new HTML tag, like <cut>, that will auto-generate some navigation links when included in an entry.
Description:
This suggestion is based on an idea that I had on LiveJournal last year [ http://suggestions.livejournal.com/1107
Say I've written several different entries about my experiences traveling in Scotland. I could just rely on the reader to click on the "Scotland 2012" tag and find all the entries. If I have more entries in this tag than fit on a single page, the reader might miss some. Alternatively, I could edit every entry in the series whenever I publish a new entry, making sure to link to the next in the series, and maybe the latest, and possibly make sure that each entry in the series links to all the others. But that's a lot of work, and it gives a high likelihood for error.
So what I suggest instead is a custom HTML tag that will auto-generate navigation links. At the end of any entry in my series I could add a tag like <series tag="scotland 2012">. This would be displayed in the entry like so:
scotland 2012
First - Prev - Next - Last
Subject of 1st entry
Subject of 2nd entry
Subject of 3rd entry
* Subject of 4th entry, the one currently being read
Subject of 5th entry
If the series contains more than five entries, the fifth and subsequent entries should be hidden behind a link to save space. In addition, there could be several options. Perhaps you can include a title, so instead of saying "corruption" the navigation link header might read "Bribery in City Hall". Maybe the author would like the articles displayed in reverse-chronological order. Or maybe the author wants to include the date/time stamps along with the entry subject line.
One advantage of this approach is that no new UI is needed. All of the links are included as part of the entry, instead of attached to the entry, so no new buttons are necessary. And since the links are auto-generated, authors only have to remember to add the 'series' tag once, when they first write the entry, instead of having to constantly update every entry in the series.
This suggestion:
Should be implemented as-is.![]()
![]()
18 (47.4%)
Should be implemented with changes. (please comment)![]()
![]()
11 (28.9%)
Shouldn't be implemented.![]()
![]()
3 (7.9%)
(I have no opinion)![]()
![]()
6 (15.8%)
(Other: please comment)![]()
![]()
0 (0.0%)
Title:
For multiple admins in a Community
Area:
Communities
Summary:
More editing options on posts in a community not made by the admin wanting to edit it.
Description:
In a community I am an admin for, there are several admins, and all take turns making new posts when previous posts max out on comments. Sometimes comments get out of hand and the post needs to have its comments frozen for an hour or two. Dreamwidth fluctuates between whether or not it allows an admin who did not pen the post to freeze the comments of that post, requiring the admin who penned the post to be online, which is inconvenient, especially if they are an admin less often around. I suggest that anyone who is at Admin level in a community be allowed to edit the comment options(including disabling them) in any post in the community. It would make moderating much easier.
This suggestion:
Should be implemented as-is.![]()
![]()
25 (69.4%)
Should be implemented with changes. (please comment)![]()
![]()
3 (8.3%)
Shouldn't be implemented.![]()
![]()
1 (2.8%)
(I have no opinion)![]()
![]()
6 (16.7%)
(Other: please comment)![]()
![]()
1 (2.8%)
Title:
Option to disable tag auto-completion
Area:
tags
Summary:
Add an option to disable tag auto-completion.
Description:
The tab auto-completion system interacts poorly with at least older (2.x) Android browsers, because the text entry system on those devices does not support "overtype to erase selected text". It would be useful to have an option to disable tag autocompletion, so that users of such devices can fill in tags without heavy use of backspace.
This suggestion:
Should be implemented as-is.![]()
![]()
12 (37.5%)
Should be implemented with changes. (please comment)![]()
![]()
0 (0.0%)
Shouldn't be implemented.![]()
![]()
11 (34.4%)
(I have no opinion)![]()
![]()
9 (28.1%)
(Other: please comment)![]()
![]()
0 (0.0%)
Title:
Add ability to link OpenID account to DW account during content imports from other sites
Area:
site: openid, workflow: importer, and maybe site: usability
Summary:
Subsuming your OpenID while importing content created by the OpenID's account (such as associating the OpenID of Username@Livejournal while importing Username's journal contents from Livejournal) seems a very logical thing. Suggest there be an option on the Import Content page, which is easily reachable in the larger DW-sitescheme header, to do that in the course of importing content, or at least a link to the page for associating the OpenID, with a blurb explaining what it's for. To an end user, these two processes look to be rather closely related, so to have them obviously linked seems neatly intuitive.
Description:
I imported an account from LiveJournal a while ago and checked an entry's page, only to finally realize that comments made by that account, while it was on LJ, to its own posts... did not register as belonging to the new account on Dreamwidth, although the entries in the journal correctly said that they belonged to the DW account.
I realize that importing content from a non-DW journal to a DW journal and claiming ownership of that non-DW journal's comments are two separate things, but they feel as though they should go together somehow.
I can see two ways of doing this quite neatly, and in a way that makes things clear to the new user. The first would be to include a note on the Import Content page stating that "importing the comments on a journal's entries does not claim ownership of the journal's own comments, but this tool can take care of that for you: (and a link to the appropriate page for subsuming your OpenID accounts)" or something to that effect.
The other way, which I suspect would be more work, but still end up pleasing many users, would be to combine the two pages, so that you could take care of both tasks at once, if you wanted. There's all sorts of options for what to import, exactly, and you already need to enter your username and password, and specify which site to import from. Taking ownership of that account's comments, especially on its own pages, seems a logical and intuitive part of the process, to me.
If the second idea is gone for, still having a note and link like the first idea, in the Import pages (and it being pointed out that taking ownership of the OpenID account works for all OpenID sites, whereas importing the content only currently works for LiveJournal and InsaneJounral, would be great too) would be very handy, especially as it isn't linked directly in the header navigation, while Import Content is.
This suggestion:
Should be implemented as-is.![]()
![]()
16 (61.5%)
Should be implemented with changes. (please comment)![]()
![]()
0 (0.0%)
Shouldn't be implemented.![]()
![]()
0 (0.0%)
(I have no opinion)![]()
![]()
9 (34.6%)
(Other: please comment)![]()
![]()
1 (3.8%)
Title:
Add a CSS Class to Comment Count on View Month Page
Area:
styles
Summary:
Right now there is no CSS class for the comment count shown after each post on the View Month Page (this page and all pages like it): http://exampleusername.dreamwidth.org/2
Description:
Right now there is no CSS class for the comment count shown after each post on the View Month Page (this page and all pages like it): http://exampleusername.dreamwidth.org/2
This suggestion:
Should be implemented as-is.![]()
![]()
17 (51.5%)
Should be implemented with changes. (please comment)![]()
![]()
2 (6.1%)
Shouldn't be implemented.![]()
![]()
1 (3.0%)
(I have no opinion)![]()
![]()
13 (39.4%)
(Other: please comment)![]()
![]()
0 (0.0%)
Title:
Make Sidebar and Tags Page Tag Counts Into Links
Area:
tags, styles
Summary:
On other websites (in all truth, I can't remember exactly which ones) I've seen tag counts (such as "News: 20 uses", for example) displayed as links. By clicking the number 20 in my example - or the whole line, "20 uses", depending on how exactly the usage count is worded/displayed - one is taken to a page that shows all uses of that tag, exactly the way clicking on the tag *name* itself works right now on DW. I would like to 1) see the tag count included in the tag name link, for both styling and accessibility purposes or b) make another link for the tag count itself.
Description:
Right now tag counts don't have their own CSS classes or any fine-grained styling options in the Customize Style interface (but these first two issues are initially covered in another suggestion I've recently made), nor do they display as links. On my own DW I often look at the tag counts, in the sidebar in particular, and wonder why they can't also possibly function as links. It seems intuitive that you might read a user's tag names, check the tag counts on each one, then might want to, for example, click through based on a particularly high or low number of uses on at least one or more of those tags. But the ability to click through on a tag count isn't there so as a mouse user, for example, you might have to swing your mouse back across the screen to click on the tag name instead. This could sort of be a hassle, especially if there's more than one tag you want to click through on. My solution is to simply linkify the tag counts.
This suggestion:
Should be implemented as-is.![]()
![]()
10 (37.0%)
Should be implemented with changes. (please comment)![]()
![]()
0 (0.0%)
Shouldn't be implemented.![]()
![]()
5 (18.5%)
(I have no opinion)![]()
![]()
12 (44.4%)
(Other: please comment)![]()
![]()
0 (0.0%)
Title:
Expose Tag Count Tooltip Option to Customize Style User Interface, Make New CSS Class for Tag Count
Area:
tags, styles
Summary:
Based on a thread in the Style System community (http://style-system.dreamwidth.org/102
Description:
Right now as a DW user you may, for aesthetic or other reasons, not want to expose the tag count to users in your sidebar (a 'tag count' being how a sidebar tag might say, for example, "0 uses" or "20 uses" right after it). Rather than hide it via clumsy CSS ('clumsy' being, um, the only CSS guidance I could offer in that thread, given that there is no specific CSS class for the tag count) the idea is to expose the "display tag count only as a tooltip" in the Customize Style/Modules user interface to give users that option. Right now they can only access it by creating a custom theme layer and coding it in via DW's s2 programming language.
I'd also like to suggest that we have a separate CSS class for sidebar tag counts so we can style them however we want (this is the part of the suggestion I think DW designers will benefit from the most - but exposing the tooltip option also sounds like awesome sauce to me).
This suggestion:
Should be implemented as-is.![]()
![]()
14 (53.8%)
Should be implemented with changes. (please comment)![]()
![]()
0 (0.0%)
Shouldn't be implemented.![]()
![]()
1 (3.8%)
(I have no opinion)![]()
![]()
11 (42.3%)
(Other: please comment)![]()
![]()
0 (0.0%)
Title:
[css] Add admin-post css to entry-wrappers.
Area:
styles, entries
Summary:
When you mark a comment as an official admin/mod hat comment, it applies the admin-post class to the comment's comment-wrapper, but the same does not happen when you mark an entry as official. The entry-wrapper does not gain a admin-post class. I suggest that it does so you can use css to format those posts separately from others.
Description:
When you mark a comment as an official admin/mod hat comment, it applies the admin-post class to the comment's comment-wrapper, but the same does not happen when you mark an entry as official. The entry-wrapper does not gain a admin-post class. I suggest that it does so you can use css to format those posts separately from others. Personally, I'd love to use this as a way to call more attention to those specific entries without having to use a .poster class and have everything marked by a specific user stand out.
An additional suggestion related to this: At current the class .admin-post gets added to comments when they are made official moderator comments. It might be easier to suggest this css is changed to .admin-comment if it is a comment and .admin-post if it is added to an entry. This isn't a necessary step because you could format with ( .entry-wrapper .admin-post AND .comment-wrapper .admin-post ) but it might just be cleaner for those who don't like listing multiple classes together to specify.
This suggestion:
Should be implemented as-is.![]()
![]()
24 (64.9%)
Should be implemented with changes. (please comment)![]()
![]()
1 (2.7%)
Shouldn't be implemented.![]()
![]()
0 (0.0%)
(I have no opinion)![]()
![]()
12 (32.4%)
(Other: please comment)![]()
![]()
0 (0.0%)
Title:
Send notifications of unscreened comments in tracked threads
Area:
Commenting, tracking threads, notifications
Summary:
I'd like to get notifications of comments in screened threads, where a moderator later unscreens them. Right now, if you subscribe to a thread, you get notified of new comments--but not if they're screened. And there's no notification sent out on unscreening.
Description:
I don't know how technically difficult this would be to implement. All I know is, when I try to track threads in anon love memes, where comments are often screened until a moderator opens them, I don't get email notifications. I assume there are similar problems in some gaming journals and some kink memes--if you're not the person being replied to, you have to keep checking back to find out if there are new responses.
I assume that the "send notification" code activates immediately upon commenting, and is interrupted if the comment is screened. There may not be an easy way to implement "when comment is unscreened, check to see if anyone's subscribed, and send notification," especially if that includes "...but first, check to see if that person's already been notified, either because they were the reply-to person and got notified when the comment was made, or because the comment was originally unscreened, later screened, and is now being unscreened again."
I can't think of any drawbacks to this (other than, of course, it may be horrendously difficult to code), but I can easily believe I'm missing some. I don't know if there are any comms that make use of the lack-of-notification as it currently exists.
This suggestion:
Should be implemented as-is.![]()
![]()
38 (79.2%)
Should be implemented with changes. (please comment)![]()
![]()
3 (6.2%)
Shouldn't be implemented.![]()
![]()
1 (2.1%)
(I have no opinion)![]()
![]()
6 (12.5%)
(Other: please comment)![]()
![]()
0 (0.0%)