dw_suggestions | Entries tagged with bugzilla: exists

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/banana to display all User's current public entries tagged 'banana'. And some people have hundreds of entries per tag, so checking all by hand might not be practical.

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/lutefisk and the same for security/public/tag/lutefisk to make sure of that.")

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.

Poll #15786 Filter entries by tags AND security level

Open to: Registered Users, detailed results viewable to: All, participants: 40

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
16 (40.0%)

Should be implemented with changes. (please comment)
6 (15.0%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
17 (42.5%)

(Other: please comment)
1 (2.5%)

cesy

Title:
Send error if you try to email post from the wrong address

Area:
email posting

Summary:
Don't fail silently on email posting - show an error message somewhere with an explanation.

Description:
If you try to email a post to your journal, there is a setting that lists the email addresses that are allowed to do this. If you have multiple email addresses, and accidentally send it from one that's not one of the three on http://www.dreamwidth.org/manage/settings/?cat=mobile, it fails silently.

Instead of failing silently with no clues, you should get a notification of some sort to let you know it happened and give you a clue why. This should include appropriate caveats about telling Support or improving your security if it wasn't you that did it, and could go either to your Inbox, to your main email, or to the email you tried from, whichever is considered to be most secure.

Poll #13461 Send error if you try to email post from the wrong address

Open to: Registered Users, detailed results viewable to: All, participants: 31

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
15 (48.4%)

Should be implemented with changes. (please comment)
1 (3.2%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
15 (48.4%)

(Other: please comment)
0 (0.0%)

vilakins

Title:
Bring back mouse-over userpic key words

Area:
Comments

Summary:
I used to be able to mouse over a userpic in an entry and comments (in default comment layout) and see its key word(s). Now we get the options that also show up when one mouses over a userhead so functionality has been lost.

Description:
I used to be able to mouse over a userpic in an entry and comments (in default comment layout) and see its key word(s). Now we get the options that also show up when one mouses over a userhead so functionality has been lost.

I'd like to be able to see userpic key words again, especially since I can get the options shown now by mousing over a person's userhead.

Poll #8386 Bring back mouse-over userpic key words

Open to: Registered Users, detailed results viewable to: All, participants: 39

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
14 (35.9%)

Should be implemented with changes. (please comment)
0 (0.0%)

Shouldn't be implemented.
1 (2.6%)

(I have no opinion)
19 (48.7%)

(Other: please comment)
5 (12.8%)

azurelunatic

Title:
Separate crosspost footer for when comments are disabled on Dreamwidth.

Area:
crossposting, entries

Summary:
Add a separate crosspost footer for when comments on Dreamwidth are disabled.

Description:
Sometimes you just want to turn off all comments, no matter where you're posting.

Currently, when comments are disabled on Dreamwidth, the "comments disabled locally" footer is used. This footer is also used when comments are disabled on the crossposted-elsewhere entry but turned on at the Dreamwidth entry. This increases the chances that people will have put text explicitly inviting people to go over to Dreamwidth to comment.

If comments on Dreamwidth are disabled, it makes no sense to invite a person viewing your entry on a remote site to come to Dreamwidth and leave a comment.

It is one more setting to potentially confuse people, but the alternative involves confusing and annoying a more broad range of people on other sites with every cross-posted entry that invites people to comment but it turns out not to be possible.

[feature already exists; poll closed.]

Poll #6509 Separate crosspost footer for when comments are disabled on Dreamwidth.

This poll is closed.
Open to: Registered Users, detailed results viewable to: All, participants: 51

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
31 (60.8%)

Should be implemented with changes. (please comment)
1 (2.0%)

Shouldn't be implemented.
1 (2.0%)

(I have no opinion)
16 (31.4%)

(Other: please comment)
2 (3.9%)

quicksilver_ink

Title:
Default privacy settings should be most restrictive

Area:
Privacy settings

Summary:
When journals are created, privacy settings on profile information should default to the most restrictive possible until they are changed by the user.

Description:
When journals are created, privacy settings on profile information should default to the most restrictive possible until they are changed by the user.

I had a delay of a few days between journal creation and getting a chance to really sort things out, and based on the default settings it looked like some of my personal information (email and DOB) was publicly viewable on my profile during that time period, which makes me uncomfortable.

I believe this change would be a good idea because a number of people are currently moving to DW in reaction to LiveJournal's alliance with FaceBook. Most of the people I know who have discussed leaving LJ over this are concerned about privacy issues, and feel that LJ has shown a lack of consideration for their privacy. I believe that making DW privacy settings opt-out would be reassuring to many people.

It would also be an easy way to demonstrate the DW takes privacy seriously and will not be going the FB route of compromising privacy by default.

The only drawback I can see to making this change is that people may need to change more settings to match their desires when they get things set up.

Poll #4428 Default privacy settings should be most restrictive

Open to: Registered Users, detailed results viewable to: All, participants: 80

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
45 (56.2%)

Should be implemented with changes. (please comment)
6 (7.5%)

Shouldn't be implemented.
18 (22.5%)

(I have no opinion)
9 (11.2%)

(Other: please comment)
2 (2.5%)

archangelbeth

Title:
Expandable cut tags for www.dreamwidth.org/inbox/

Area:
Format of the Inbox

Summary:
Put in expandable cut tags automatically for long posts that show up in the inbox, like the News.

Description:
I tend to read the DW_News in my inbox (which I maintain much better than I maintain my LJ one...), but I like to leave the notification there until the next News post comes along, or as a reminder to think about something, make a suggestion, give feedback, etc.

DW_News posts can be very long. I wouldn't want them to be terser! But does make a lot of scrolling up and down if I want to see if I replied to a comment someone made or not. (I delete after replying.)

But this News post included the joy of expandable cut-tags, and I thought, "You know, it'd be really cool if long posts in my inbox could just have those cut tags..." Because then I could click on 'em and read, or click to close them and see if there are notifications I should be deleting.

And then the News post had this handy link to "make a suggestion"...

Poll #4419 Expandable cut tags for www.dreamwidth.org/inbox/

Open to: Registered Users, detailed results viewable to: All, participants: 57

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
42 (73.7%)

Should be implemented with changes. (please comment)
0 (0.0%)

Shouldn't be implemented.
1 (1.8%)

(I have no opinion)
14 (24.6%)

(Other: please comment)
0 (0.0%)

sibyllevance

Title:
Rename tags with the name of an already-existing tag

Area:
Tags

Summary:
I think it would be useful to be able to rename tags to an already-existing tag, which I don't think is possible right now.

Description:
Today, I wanted to rename all my tags related to Harry Potter 'book: harry potter'. I had several tags for Harry Potter, 'writing: harry potter', 'general thoughts: harry potter' and 'fic rec: harry potter'.
I managed to rename writing: harry potter to book: harry potter, but I quickly realized I couldn't rename general thoughts: harry potter to book: harry potter after that. I had to edit each general thoughts: harry potter entry manually to have them tagged properly.
It would be convenient to be able to merge three tags into one directly in the 'manage tags' section as opposed to editing each entry.

Poll #2959 Rename tags with the name of an already-existing tag

Open to: Registered Users, detailed results viewable to: All, participants: 53

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
48 (90.6%)

Should be implemented with changes. (please comment)
0 (0.0%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
3 (5.7%)

(Other: please comment)
2 (3.8%)

yvi

Title:
Allow paid account users to upgrade to premium paid accounts

Area:
accounts, shop

Summary:
Paid account users should be able to pay the point difference between their current account level and a 6/12 month premium paid account to get upgraded.

Description:
If you have a 'normal' paid account on Dreamwidth right now, but would like to have a premium paid account (maybe someone else gifted you the paid account time, maybe you suddenly realized you need those 500 extra notifications, whatever), it would be good if you could just pay the difference in Dreamwidth points and convert your account to a premium paid account.

I admit I have no idea what would happen now if I just purchased a premium paid account in the store right now and because I am not interested in having one at the moment, I am not going to try. However, it looks like someone who has a few months left of regular paid account time pays the same price as someone who has a free account. Since from looking at another bug in the bugtracker I just learned that there is currently no downgrading from a premium to a regular paid account, it obviously won't be the case that you would have a premium paid account for 6/12 months and then be downgraded to a regular paid account. So I think the system should calculate how many points the remaining regular paid time you have on your account is worth and subtract that from your order.

Examples of how I think it would work:

A regular paid user has two months left on their paid account. That's 60 Dreamwidth points. They go into the shop and select 6 months of premium paid account time, which is worth 250 points. The system should ask the user whether they want to upgrade their account level and then tell the user that they need 190 points to perform the upgrade.

A regular paid user has 10 months left on their paid account. 6 months paid time is 175 points, 12 months is 350, and from there on the system should probably make some sensible calculations and rounding and so on, so I'd gather 10 months is worth about 290 points. The user goes into the shop and selects 12 months of premium paid account time, which is worth 500 points. The system should ask the user whether they want to upgrade their account level and then tell the user that they need 210 points to upgrade their account.

The calculations with rounding are probably going to be a bit tricky to implement - rounding down to the nearest full month and then having fixed values for those would probably be easiest, but with the points system, there can also be smaller steps. There can also be situations where the users gets Dreamwidth points back - which isn't bad, in my opinion, as that doesn't mean Dreamwidth will have to pay back money, it just means the points can be used for something else. But I think it's worth it so that users can upgrade their account without having to wait or feeling like they are losing something.

(And I certainly know that I have been hesitant to gift paid account in the past because I didn't know whether the user would maybe want a premium account)

Poll #2939 Allow paid account users to upgrade to premium paid accounts

Open to: Registered Users, detailed results viewable to: All, participants: 36

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
16 (44.4%)

Should be implemented with changes. (please comment)
0 (0.0%)

Shouldn't be implemented.
6 (16.7%)

(I have no opinion)
14 (38.9%)

(Other: please comment)
0 (0.0%)

mlyn

Title:
Stick icon selection even after editing keywords

Area:
Tags

Summary:
Make icon choices stick with posts unless the icon is fully deleted. Changing details on the icon shouldn't revert the post's icon choice to the default icon.

Description:
I recently uploaded an icon, made a post, and in the midst of posting realized I hadn't described the icon correctly with my keywording. After posting I changed the icon keywords and then refreshed my journal. The new post's icon had reverted to my default, so I then had to edit the post and change back to the re-keworded icon.

I'd hate to think that future editing of keywords on my icons will make every past post show my default icon. Can we make icon choices stick with the posts regardless of the information on the icon, or are keywords permanent the minute we write them? Should I be using icon descriptions rather than keywords? I had the impression that this kind of move has worked in the past, using LJ.

Poll #2845 Stick icon selection even after editing keywords

Open to: Registered Users, detailed results viewable to: All, participants: 40

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
6 (15.0%)

Should be implemented with changes. (please comment)
1 (2.5%)

Shouldn't be implemented.
27 (67.5%)

(I have no opinion)
5 (12.5%)

(Other: please comment)
1 (2.5%)

azurelunatic

Title:
Don't display unnecessary tag vs. crosspost warnings

Area:
crossposting, tags, the little things that irk us

Summary:
If there's no chance that a given entry would or could be crossposted, ever, (or if we can't crosspost it), don't warn us that it won't be crossposted when editing tags.

Description:
The edit tags on an entry page (http://www.dreamwidth.org/edittags?journal=username&itemid=####) warns us:

"This will not respect your default crosspost settings. Your crossposted entries will not be updated. If this is important to you, edit this entry directly to add the tags."

This warning is only appropriate in your own personal journal (at least at the moment). It is not currently (or perhaps ever) relevant:

* on your community entry
* on someone else's entry
* on someone else's community entry

Suggested implementation: It looks* like that phrase is part of the edittags.intro string, so if it is, then edittags.intro should probably be split into something like edittags.intro and edittags.crosspost, and then edittags.crosspost only displayed if it's at all possible to crosspost.

Since it appears* that this page is still using BML, this could either be done on its own if someone feels like it, or rolled into the conversion of the page to TT.

* There's a BML error on the page, so I can't be sure, see http://www.dreamwidth.org/support/see_request?id=6107 if you have the curiosity about that. (Two notes, one foot! How about that!)

Poll #2786 Don't display unnecessary tag vs. crosspost warnings

Open to: Registered Users, detailed results viewable to: All, participants: 32

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
22 (68.8%)

Should be implemented with changes. (please comment)
0 (0.0%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
8 (25.0%)

(Other: please comment)
2 (6.2%)

katieastrophe

Title:
post-security in email posting doesn't use DW language but should
Area:
Email posting
Summary:
When posting by email, most post-security tags fit with Dreamwidth's terminology, except for the access list option. This should be changed.
Description:
When posting access locked entries by email, I would expect to use "post-security: access", but according to the further instructions page found off the mobile tab of my account settings, the command is actually "post-security: friends", which is old LJ language. I think that it should be updated to reflect DW speak.

Obviously, to keep backwards compatibility/email crossposting, "lj-security: friends" should remain.

ETA:

yvi has pointed out in comments that what I'm asking for exists, but is improperly documented, so just ignore my post :-)

Poll #2487 post-security in email posting doesn't use DW language but should

Open to: Registered Users, detailed results viewable to: All, participants: 26

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
17 (65.4%)

Should be implemented with changes. (please comment)
1 (3.8%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
5 (19.2%)

(Other: please comment)
3 (11.5%)

ranrata

Title:
Remember work as [user] selection

Area:
styles, management

Summary:
When selecting an account in the "work as" drop-down menu, the selection should be remembered after hitting "save changes."

Description:
While working on the layout for a new community, I wound up accidentally overwriting my user journal's layout because I forgot to change the "work as [user]" selection, which defaults back to my user journal every time I hit "save changes," and subsequently spent the next half-hour trying to get my layout back in order. To prevent this ~great tragedy~ from befalling other users, the "work as" should remember what the user selected at least until they navigate away from the page.

Poll #2419 Remember work as [user] selection

Open to: Registered Users, detailed results viewable to: All, participants: 31

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
26 (83.9%)

Should be implemented with changes. (please comment)
0 (0.0%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
2 (6.5%)

(Other: please comment)
3 (9.7%)

vilakins

Title:
Deleting messages

Area:
Inbox

Summary:
It would be good if we could delete messages by category, e.g. all unread, all comments etc. Going into "Unread" and deleting all removes all messages. :-(

I would also like a category for cross-posting updates.

Description:
It would be good if we could delete messages by category, e.g. all unread, all comments etc. Going into "Unread" and deleting all removes all messages. :-(

I would also like a category for cross-posting updates so I could clean those out easily.

Poll #2256 Deleting messages

Open to: Registered Users, detailed results viewable to: All, participants: 38

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
36 (94.7%)

Should be implemented with changes. (please comment)
0 (0.0%)

Shouldn't be implemented.
1 (2.6%)

(I have no opinion)
1 (2.6%)

(Other: please comment)
0 (0.0%)

ninetydegrees

This is already implemented. I had some custom coding which prevented me from seeing the separation. My apologies.

Title:
Suggestion Preview: clearly delineate the preview/remove extra text

Area:
http://www.dreamwidth.org/site/suggest

Summary:
When you preview your suggestion I find it a bit difficult to spot what's the preview and what's a repeat of the suggestion page. There is no separation between the two.

Description:
Ideally, I'd like all the extra text starting from 'Have a way to make Dreamwidth better?' to be removed from the preview and a simple <hr> line to be added but, if that can't be done, just the line would be useful.

Here's a screenshot to show you what I mean: http://i38.tinypic.com/2j31f6c.jpg

Poll #1536 Suggestion Preview: clearly delineate the preview/remove extra text

This poll is closed.
Open to: Registered Users, detailed results viewable to: All, participants: 3

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
0 (0.0%)

Should be implemented with changes. (please comment)
0 (0.0%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
1 (33.3%)

(Other: please comment)
2 (66.7%)

medrin

Title:
Watch a group of tags

Area:
tags

Summary:
To be able to watch a group of tags on a journal instead of only the entries under the specific tag.

Description:
There is the awesome function of being able to group tags by typing a :. For example: someone writing reviews for different shows might tag them 'review: show1' and review: show2' and so on.

My suggestion is that it should be possible to view all the entries under the group of tags named 'review' in this example in a simple way. A way of doing this is to create a page under '*/tag/review' where these entries are showed and in the list view of tags the group tag could be made into a hotlink to that page.

Cons: Could get confusing if the user already has a separate tag for only 'review'. A way to avert that could be to put some extra sign after the url, maybe '*/tag/review:', but I don't know enough to know what kind of signs you can use there without creating troubles.

Poll #967 Watch a group of tags

Open to: Registered Users, detailed results viewable to: All, participants: 26

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
12 (46.2%)

Should be implemented with changes.
0 (0.0%)

Shouldn't be implemented.
2 (7.7%)

(I have no opinion)
11 (42.3%)

(Other: please comment)
1 (3.8%)

triadruid

Title:
Comment pagination links

Area:
entry navigation

Summary:
Maintain use of the #comments anchor when paging through entries with numerous comments.

Description:
DW has already implemented a feature (at least in some styles) where if you click to read comments on an entry, you are jumped to a #comments anchor. Paging forward or backward within an entry should also jump to that link; this avoids having to scroll down through the entry, which you have presumably already read.

'Link', as always, should take you to the top of the page.

Poll #896 Comment pagination links

Open to: Registered Users, detailed results viewable to: All, participants: 26

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
17 (65.4%)

Should be implemented with changes.
2 (7.7%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
6 (23.1%)

(Other: please comment)
1 (3.8%)

galateus

Title:
An RSS / Atom feed per tag

Area:
rss, tags

Summary:
Tag-specific RSS feeds would be more flexible than the current per-tag email notifications system, and let non-account-havers track things.

Description:
(Right now, when viewing a /tag/footag page, the little RSS icon in Firefox points to a generic feed for the whole community/journal. That's slightly unintuitive but also inspired this suggestion!)

The same use-case for per-tag Notifications applies to per-tag syndication: Wanting to keep up with a subset of a community/journal's posts without having to read through non-related topics.

The difference is that Atom/RSS would let us use feed aggregators instead of just our email clients. It'll also allow random Internet passers-by to track tagged entries without having to sign in or provide an email address or anything at all. (Which seems like a big plus point to me. There are probably other "feeds beat out circa-1999 subscription techniques" advantages I'm forgetting.)

Poll #880

Open to: Registered Users, detailed results viewable to: All, participants: 22

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
3 (13.6%)

Should be implemented with changes.
4 (18.2%)

Shouldn't be implemented.
5 (22.7%)

(Other: please comment)
10 (45.5%)

ETA: Ohhh, this already exists--it just isn't very visible.

Dreamwidth Suggestions

Filter entries by tags AND security level

Send error if you try to email post from the wrong address

Bring back mouse-over userpic key words

Separate crosspost footer for when comments are disabled on Dreamwidth.

Default privacy settings should be most restrictive

Expandable cut tags for www.dreamwidth.org/inbox/

Rename tags with the name of an already-existing tag

Allow paid account users to upgrade to premium paid accounts

Stick icon selection even after editing keywords

Don't display unnecessary tag vs. crosspost warnings

post-security in email posting doesn't use DW language but should

Remember work as [user] selection

Deleting messages

Already implemented! [WAS] Suggestion Preview: clearly delineate the preview/remove extra text

Watch a group of tags

Comment pagination links

An RSS / Atom feed per tag

Profile

Most Popular Tags

December 2018

Page Summary

Active Entries

Style Credit

Expand Cut Tags

Syndicate