Show tags in Inbox Entries

[jassanja]

Title:
Show tags in Inbox Entries

Area:
Inbox

Summary:
Show tags for entries in Inbox

Description:
When tracking a user/community and a post has been tagged, said tag does not show up at the Inbox

Currently one needs to go to the original entry to see if it was tagged, and then have another click to go to the display of said tag

Displaying tags in the Inbox would be a short-cut and a help to see if any tags were used at all for an entry

Poll #2942 Show tags in Inbox Entries

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

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
20 (54.1%)

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

Shouldn't be implemented.
1 (2.7%)

(I have no opinion)
16 (43.2%)

(Other: please comment)
0 (0.0%)

site-schemed pages should horizontally re-wrap or scroll when necessary

[the_shoshanna]

Title:
site-schemed pages should horizontally re-wrap or scroll when necessary

Area:
site interface

Summary:
Some site-schemed pages, when in a narrow window, lose information off the right edge without providing a scroll bar, so there is no way to see the full page without widening the window.

Description:
I don't like reading long lines of text and like to be able to put two windows next to each other, so I normally keep browser windows at a width that makes most text lines 80-100 characters long. Most web pages either re-wrap themselves as needed to accommodate whatever width the window is at (far preferable) or show a horizontal scroll bar to allow access to the full width. Site-schemed pages, however (I think that's the right term) do not; some text re-wraps, but often there are elements (such as text boxes) that do not wrap or scale themselves, and if the window is too narrow to show their full width, no scroll bar appears. I tested this in three browsers.

For an example of what I mean, check out this jpg of my "manage other sites" page: http://thisland.ca/siteimages/screencap.jpg. Note that the banner at the top, with my default icon and the DW logo, has scrunched itself together nicely to fit, but the rest of the page is falling off the right edge of the window, with no scroll bar. Moreover (presumably because the window, having no horizontal scroll bar, doesn't "know" it's not wide enough), clicking the green zoom button in the top left corner (I'm on a Mac) does not widen the window; I have to grab and drag the corner to widen it.

Windows should re-wrap as much as possible, but when it's not possible, they should always show a horizontal scroll bar! I cannot think of any problems or drawbacks involved in having that happen.

Poll #2944 site-schemed pages should horizontally re-wrap or scroll when necessary

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

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
2 (4.0%)

(Other: please comment)
0 (0.0%)

Make a public entry resistant to bulk privacy change

[lauredhel]

Title:
Make a public entry resistant to bulk privacy change

Area:
Access locking

Summary:
A way to make particular public entries resistant to bulk privacy change.

Description:
I go through and access-lock older posts in swathes, using the Edit Journal Privacy tool. It would be great to have a way to set a particular post to stay public regardless of bulk security changes applied to that month/year of posts.

Problem Being Solved: Sometimes a post is linked at access_fandom or metafandom or whatever. I'd prefer to have to be able to set a flag on just those particular posts to stay public, ignoring bulk changes.

Drawbacks - Maybe someone who had set a post to stay public would erroneously think that it had been changed to private after a bulk change? That's the feature working as designed, of course, but a warning could be appropriate at the time of the bulk privacy change, in case the flag was set back past living memory.

Or perhaps there could be two 'levels' of bulk change: one regular one that ignores the StayPublic flags, and one 'emergency/absolute' one that overrides absolutely everything?

Or perhaps the bulk privacy change could be more fine-grained in another way, like listing the entries to be locked and having a tickybox option on each. (It would still be nice to be able to set some sort of flag on posts to readily pick them out from the tickybox list, if this were to be the case.)

Poll #2943 Make a public entry resistant to bulk privacy change

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

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
19 (35.2%)

Should be implemented with changes. (please comment)
19 (35.2%)

Shouldn't be implemented.
6 (11.1%)

(I have no opinion)
10 (18.5%)

(Other: please comment)
0 (0.0%)

Rename tags with the name of an already-existing tag

[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%)

Retitle "Reading" link for communities

[yvi]

Title:
Retitle "Reading" link for communities

Area:
Style System

Summary:
Communities also have a "Reading" link on their layouts - rename that to "Members" or something else that makes sense for communities.

Description:
Every community also has a page that displays the public posts its members (not subscribers) have made: http://examplecomm.dreamwidth.org/read. The link to that is by default also called "Reading", like it is on personal journal. I propose renaming this to something that makes a bit more sense for communities, but it probably needs to be short so as to not break layouts, for example "Members".

Poll #2960 Retitle "Reading" link for communities

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

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
43 (72.9%)

Should be implemented with changes. (please comment)
5 (8.5%)

Shouldn't be implemented.
5 (8.5%)

(I have no opinion)
6 (10.2%)

(Other: please comment)
0 (0.0%)

Community tag privacy and management

[iamsosmart]

Title:
Community tag privacy and management

Area:
tags, communities

Summary:
Change default tag security to public. Enable an option that will allow members to add and remove mod-created tags from entries, but not create new ones.

Description:
There doesn't seem to be a tag management option that will let community members add and remove tags from their entries, but not create new ones.

Right now they can add, remove, AND create new ones ("Who can create new tags and add or remove tags from entries? Members Only"), or they can only add tags without being able to remove them OR create new ones ("Who can create new tags and add or remove tags from entries? Admin Only").

This is a bit problematic for comm mods who want members to be able to manage their own tags on entries, but don't want to give members the ability to create (or mistype) a bajillion new tags in the comm.

Another problem is that new tags added by the admin in the Manage Tags area are set as PRIVATE until they have actually been assigned to an entry -- by someone who can create new tags. So if your members cannot create new tags, they also can't use new tags YOU have made unless you stick the tags on an entry somewhere. I think having new tags defaulting to public would make more sense.

Poll #2961 Community tag privacy and management

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

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
47 (85.5%)

Should be implemented with changes. (please comment)
2 (3.6%)

Shouldn't be implemented.
2 (3.6%)

(I have no opinion)
4 (7.3%)

(Other: please comment)
0 (0.0%)