[go: up one dir, main page]

Page MenuHomePhabricator

Provide alternate style for non-public issues
Closed, ResolvedPublic

Description

Reported upstream: https://secure.phabricator.com/T6787

Because of the ease of accidentally filing a public Security issue (relative to Bugzilla), it would be nice to have a more prominent indicator of public vs not than the grey-on-grey globe icon plus text. For example, a banner color change or a background color change would be nice. That would make it much easier to notice when something is amiss with the view permissions on a task. Even if the cat is out of the bag, just knowing that helps us take appropriate action.

I imagine that wouldn't be a feature that the Phabricator folks would want as a standard styling change, but it would be nice to at least have well-placed class markers such that it'd be possible for us to override the default style sheet to get the styling we want. The class could be added any time that the issue is not "public". Even though that may sound overly specific to our use case, just knowing how other organizations use public/private issue trackers (I've administered public/private installations at two other orgs), I suspect this has general applicability.

This all assumes, of course, that "we" want it, which the "we" right now is only Chris Steipp and myself, but I file this partly to gauge if "we" is ultimately bigger than two people.

Related Objects

StatusSubtypeAssignedTask
ResolvedQgil
ResolvedQgil
ResolvedQgil
Resolved RobLa-WMF
ResolvedQgil
ResolvedDzahn
ResolvedQgil
ResolvedAklapper
Invalid mmodell
Resolved mmodell
Resolved mmodell
DeclinedQgil
Resolved mmodell
ResolvedQgil
ResolvedRobH
ResolvedAklapper
ResolvedAklapper
ResolvedAklapper
ResolvedAklapper
ResolvedAklapper
DeclinedAklapper
ResolvedQgil
Resolved chasemp
Resolved chasemp
Resolved chasemp
Resolved chasemp
Resolved chasemp
Resolved chasemp
ResolvedQgil
Resolved gpaumier
ResolvedAklapper
ResolvedDzahn
ResolvedDzahn
DeclinedNone
InvalidRobH
DuplicateRobH
Declined mmodell
Duplicate mmodell
ResolvedQgil
Resolved mmodell
Resolved Springle
ResolvedNone
Resolved mmodell

Event Timeline

RobLa-WMF raised the priority of this task from to Needs Triage.
RobLa-WMF updated the task description. (Show Details)
RobLa-WMF changed Security from none to None.

On the "we" front: not a security person, but a security-concious-and-paranoid person: it seems like something we should have. We constantly have problems on the projects with staffers accidentally editing from their personal accounts, even with a CSS hack that makes the staff account edit window bright red. So, more prominence for "this is sensitive, be careful" would be...good.

Qgil triaged this task as Medium priority.Dec 6 2014, 2:34 PM
Qgil added subscribers: mmodell, chasemp, Qgil.

Yes, we are aware of this problem and, in fact, we discussed in our last team meeting, on Wednesday.

We were talking about something technically simple and clearly visible, like changing the background to pink or something. This visual cue would take effect when the Visible policy is other than Public or All Users.

@mmodell, @chasemp, even if we plan to work on this, it would be good to upstream this request as well, don't you think? I'm happy to do it but I will wait for your opinion.

My local quick'n'dirty hack if we are not in edit mode and whenever a task is not entirely public is:

if (document.getElementsByClassName('policy-link')[0].innerHTML != "Public") {
  (document.getElementsByClassName('policy-link')[0]).setAttribute('style', "background-color:#FF7777;");
} else {
  (document.getElementsByClassName('policy-link')[0]).setAttribute('style', "background-color:#9be644;");
}

➔ below the task summary the second item next to the task status gets either a red or green background.

But background color of the entire page would be better. Mozilla Bugzilla has a local hack for that for security bug reports (probably based on the product of a ticket).

This is a very good idea.

I'll try find a way to do this with minimal amount of dirty hacks.

mmodell lowered the priority of this task from Medium to Low.Dec 19 2014, 11:58 AM
mmodell changed the task status from Open to Stalled.Jun 10 2015, 6:09 AM
mmodell lowered the priority of this task from Low to Lowest.
mmodell edited projects, added Phabricator; removed Phabricator (Upstream).

Alathough this is a good idea, I simply don't have time to work on it right now and it isn't as easy as I had hoped.

OK, but why Stalled and why not Phabricator-Upstream?

Part of this problem should be solved with Phabricator Spaces (for tasks located in those spaces).

Aklapper changed the task status from Stalled to Open.Jun 10 2015, 11:00 AM

I don't see how this is stalled (nobody can work on it). If it's technically stalled, some explanation would be welcome.

@Aklapper: I thought stalled meant 'I'm not working on it' rather than 'nobody can'

mmodell claimed this task.

This task is resolved upstream, and we've pulled the change, so I guess it should be resolved here as well.