Sep. 25th, 2012

[personal profile] swaldman

Title:
Allow mailto: links in the Links module

Area:
Journal modules

Summary:
It is not possible to add a mailto: link to the "Links" module. I would like to be able to do so.

Description:
At present, if I fill in "mailto:my@email.com" as a link target for the Links module, it gets rewritten to "http://my@email.com", which is obviously something entirely different.

I don't know whether there is a reason for not allowing email links, and thus whether it is intentional that it can't be done, or whether this is an unintended side-effect of tidying up URIs. If it's not a deliberate choice, I think that email links should be allowed.

Poll #11748 Allow mailto: links in the Links module
Open to: Registered Users, detailed results viewable to: All, participants: 53


This suggestion:

View Answers

Should be implemented as-is.
25 (47.2%)

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

Shouldn't be implemented.
5 (9.4%)

(I have no opinion)
22 (41.5%)

(Other: please comment)
0 (0.0%)

sircaliban: (Default)
[personal profile] sircaliban

Title:
2 factor authentication

Area:
improvement to login

Summary:
Create a 2 factor authentication option. The user would login with the password, and then the server would sent a code to a cell phone. The user would then enter the code to verify that they are trying to log in and it's not someone trying to hack into the account.

Description:
This would of course only be necessary for when users are connecting from unknown networks or networks they have not connected to from before. Once logging in, the user would have the option to 'trust this computer', so subsequent authentication requests would not have to got through this option.

Yahoo, Google and Facebook all off similiar functionality.

ETA: I see this option as being 'opt-in', if you opt-in, then the system will ask you for an additional code. The code is generated via something you have (cell phone, hard token, soft token).

Poll #11749 2 factor authentication
Open to: Registered Users, detailed results viewable to: All, participants: 72


This suggestion:

View Answers

Should be implemented as-is.
10 (13.9%)

Should be implemented with changes. (please comment)
15 (20.8%)

Shouldn't be implemented.
35 (48.6%)

(I have no opinion)
10 (13.9%)

(Other: please comment)
2 (2.8%)

marahmarie: (M In M Forever) (Default)
[personal profile] marahmarie

Title:
Add a body class to http://exampleuser.dreamwidth.org/tag/each-tag

Area:
Styles

Summary:
Currently the post view that shows your entries organized by tag (for example: http://marahmarie.dreamwidth.org/tag/book+reviews) has the same body class as the front page of our journals, that is, it uses the .page-recent body class. I'd like to suggest that we add a body class specifically for the entries-organized-by-tag view, so that it gets the new body class .page-tag (not to be confused with .page-tags, which is currently in use on the Visible Tags page, the one that simply lists all your tags on one page).

Description:
As a casual (but slightly obsessed) DW CSS designer, I'm often confounded by not being able to style every page view on DW individually. Because we have a sorting feature on our DWs that lets users browse full posts by each tag used on them, I want to style those pages to work as well and look as good as all the other pages on our DWs do. But the front pages of our journals and the tag views of our posts? They share the same HTML body class (.page-recent), which means tag views can be sort of weird-looking because they inherit .page-recent's styling, which often does not work on the tags view of our posts for an assortment of reasons. Which makes me think: why not just add a new, separate body class so we can style those pages, too? I humbly suggest we add the body class .page-tag to all views on our DWs that sort posts by the tags used on them (for example: http://marahmarie.dreamwidth.org/tag/book+reviews would get the new .page-tag body class, as would all other similar page views on our DWs).

Poll #11750 Add a body class to http://exampleuser.dreamwidth.org/tag/each-tag
Open to: Registered Users, detailed results viewable to: All, participants: 39


This suggestion:

View Answers

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

Should be implemented with changes. (please comment)
12 (30.8%)

Shouldn't be implemented.
3 (7.7%)

(I have no opinion)
17 (43.6%)

(Other: please comment)
1 (2.6%)

Profile

Dreamwidth Suggestions

December 2018

S M T W T F S
      1
23 45678
9101112131415
16171819202122
23242526272829
3031     

Style Credit

Expand Cut Tags

No cut tags