Privacy Settings

[RussW]

ok, so to the next obviously contentious point Privacy Settings

I've just committed a new proposal;

• new toolbar privacy buttons -- Privacy is OFF by default (although I always prefer a deny, before allow mentality) -- if suhosin is installed (hardened server/php) AND no explicit choice is made (ON or OFF) privacy is ON

• the radios in the post options can be removed if desired, giving the users less to choose by default and the privacy option isn't used within the post output at all -- then a decision on, and cleanup of, what is seen (either just removed or display text changed) in the post output can be made -- there are still some if $showProtected statements in the post output routine, I assume that since one of the initial 3 privacy options was removed at some point and from the comments above, that they are now just legacy and don't actually do anything anymore and can be removed

• this means there is now only a simplified 0 (OFF) or 1 (ON)

• a new set of redaction choices can be made to be more consistent again on the GUI version

[Webdongle]

@frostmakk

My vote goes as this: Remove the privacy option. No sensitive data in the post output. Nothing redacted on screen. https://github.com/orgs/ForumPostAssistant/teams/development/discussions/1/comments/102

That's my vote too

[RussW]

So, I guess we're up for another vote;

• Remove Privacy Options Completely 👍 @frostmakk, 👍 @Webdongle -- post output has no redaction but removes sensitive information, GUI has no redaction/privacy option (what data to be removed/text changed to be determined)

• Accept New Proposal 👍 @RussW -- post output has no redaction, just removes sensitive info & GUI has privacy/redaction option (catering for secure/hardened environments), (what data to be removed/text changed/redaction to be determined)

• Another Plan/Proposal -- please describe

[mandville]

it has been known for people to make the privacy so private theres no real output.

[sozzled]

I think the way @RussW has designed the on/off switch is good enough for the "desktop" view; the extra switch in the BBcode view probably needs to stay there, too.

[RussW]

It's my understanding, that at the moment the post output doesn't make use of any privacy (so I am told), so the Privacy buttons being in the Post Generation area seem to be superfluous. Hence the suggestion to removed them (plus giving users less things to get confused about when running the post generation from the options panels.

[sozzled]

I thought about this for about half-an-hour yesterday and, my suggestion this morning wasn't something on the spur of the moment. It's reasonable for the user to hide certain information when posting the BBcode on the forum (if that's their wish) and, for that reason, the additional settings when generating the BBcode aren't necessarily superfluous. Unless you combine the switch function at the top of the desktop view with the BBcode generator, that could make sense.

I'm not going to spend any more time on this. Depends on what @frostmakk may think, I guess. :confused: I don't know.

As I wrote in the other place (that no-one wants to mention), there's a difference between what someone considers to be private and what someone may consider to be sensitive and what someone may consider is "risky". I don't have much of a preference but I would like the ability to choose what I display on the J! forum that may differ from what I can see on the desktop.

[RussW]

that was the point @sozzled, my understanding from comments in the team discussion was that the use of the "Privacy" option in the post output was no-longer used, hence the location of those radio's has become superfluous. My understanding was that the Information that had deemed as "sensitive" or to be kept "private" in the forum had already simply been removed in the output.

There was some discussion of just adding some new text instead of any redaction/removal on some items, to just state if it was present or not, like the "Live Site" variable in the configuration.

Personally, I wasn't planning on immediately dealing with those changes/decisions until the GUI update was done and released as they were "core code" changes, not interface updates.

[sozzled]

AFAIAC, done.