[00:39] * StevenK kicks celebrity_logged_in() [00:51] wgrant, wallyworld_: Have either of you seen user research from dan about the manage disclosure mockups (I guess from a while ago)? I'm just trying to track it down [00:52] huwshimi: perhaps. was it an email? [00:52] I don't think there's much point continuing those at the moment. [00:53] wallyworld_: I assume so [00:53] wgrant: How come? [00:53] * wallyworld_ checks his email [00:53] huwshimi: Requirements have changed. [00:53] wgrant: Really? [00:54] It's not clear what we're doing now. [00:54] wgrant: So the whole manage disclosure pages might be different? [00:54] Things are sort of on ice. [00:54] Possibly, yes. [00:54] Can haz review? https://code.launchpad.net/~stevenk/launchpad/bugtask-userHasPrivileges-nomination/+merge/84041 [00:54] StevenK: How does that affect performance? [00:55] wgrant: When did this happen? I got asked over night to get them ready for testing tomorrow [00:55] wgrant: IBugNomination.cannAprove() is already a dog? [00:55] huwshimi: wgrant: the page will likely not be that different [00:56] the testing should still go ahead [00:56] huwshimi: A little over 24 hours ago. [00:56] wgrant: Oh right [00:56] It may not be that different. But it quite possibly will be. I guess we might as well continue testing. [00:56] ok [00:56] there's been an adjustment to the scope - security bugs need shared conversations, even private ones, hence multipillar private security bugs are allowed [00:57] Which means that the disclosure overview page can no longer feasibly show an overview of disclosure. [00:57] wgrant: We already had to look up the product/distribution and {product,distro}series in canApprove() anyway, we're just checking a few more columns in the same tables. [00:58] StevenK: k [00:58] StevenK: Hm [00:58] StevenK: Isn't this wrong? [00:58] It seems like it will permit bug supervisors to approve. [00:58] Which is wrong. [00:59] We don't want that? [00:59] wgrant: i think the md page can still show an overview [00:59] wallyworld_: It can't. [00:59] It can show a partial view. [00:59] huwshimi: sent you an email with the info [00:59] sure it can [00:59] StevenK: No. [00:59] wallyworld_: How? [00:59] Bah [00:59] how not? [00:59] * StevenK fixes it to check owner [00:59] wallyworld_: Awesome, just got it. Thanks for that [00:59] By hand [00:59] huwshimi: np [00:59] wallyworld_: We can't join through BugTask. [01:00] wallyworld_: So we'd have to flatten everything. [01:00] wgrant: why can't we do a union [01:00] wallyworld_: Hm? [01:01] instead of joining through a single bugtask, why not do the same thing across all the bug tasks (if there are now allowed to be > 1) and union the results [01:01] If I have a bug for project A shared with project B, project A's disclosure management page has to show all the observers for A and B. [01:01] yep [01:01] If the disclosure management page knows about bugtasks, ARIWEJOFUWEFIHWEFIUWEF [01:01] and? [01:01] Also, slow. [01:01] It's slow enough as it is. [01:01] so we denormalise [01:02] I went through this two months ago :) [01:02] It is not pretty. [01:02] Or usable. [01:02] At all. [01:02] bottom line is, we've been tasked with providing a solution for a problem our stakeholders want solved, we need to figure out a way to do it [01:03] we may need to compromise on how some things are delivered/reported [01:03] We don't necessarily need to solve this. [01:03] It's not clear whether we want disclosure reports for security bugs. [01:03] Because proprietary projects will probably be forbidden from sharing security bugs. [01:03] what about private security bugs [01:03] Or having security bugs at all. [01:04] so, if that's the case, then problem solved :-) [01:04] wgrant, like i said, why not just delete the field? [01:04] poolie: Which field? [01:04] security [01:04] Ha ha ha. [01:04] It's not that simple, unfortunately. [01:04] mm [01:04] Security privacy is now defined to be completely different from normal privacy. [01:04] s/now/as of yesterday/ [01:05] wallyworld_: Not problem solved. [01:05] wallyworld_: It still requires a rethink of the UI. [01:05] wallyworld_: Regardless. [01:05] sure, but shit happens [01:05] we'll come up with something [01:05] Right, I'm not saying we won't. [01:05] I'm saying it needs more thought. [01:05] And work. [01:05] the mockups can stil be tested [01:05] And that spending time testing mockups that we know won't work is probably silly. [01:06] we aren't spending any more time developing them, but it's still valid to test them [01:06] as is [01:06] since there's other useful feedback we can get [01:06] like the use of the tag paradigm etc [01:06] the location of the delete icon [01:06] etc [01:07] wgrant: Fixed, diff updated. Ignore the ADMIN_EMAIL addition, I've removed that already. [01:08] StevenK: Why not add a helper method somewhere that checks if driver privileges are possesed? [01:08] It would be very similar to userHasPrivileges or whatever the existing thing is. [01:08] Except without bug supervisor. [01:09] wgrant: StevenK: same me some greping, do either of you know the unit test for viewing a P3A owned by a private team where the use cannot see the team but is subscribed to the P3A? [01:09] /same/save [01:10] wgrant: Because it probably requires rewritting IBugTask.userHasPrivileges() for the third time in as many branches. [01:10] StevenK: Good. [01:10] StevenK: Rewritten but clean is better than dirty. [01:10] wallyworld_: No idea, sorry. [01:10] wallyworld_: You can probably find it by following the evil aura, though. [01:10] np. just an opportunistic question just in case [01:10] wgrant: userHasPrivilegesContextWithBugSupervisor() [01:11] StevenK: userHasBugSupervisorPrivileges? [01:11] userHasDriverPrivileges? [01:11] huwshimi, i have a thing for you [01:12] https://code.launchpad.net/~mbp/launchpad/feature-modulus/+merge/84042 [01:12] review pls [01:18] wgrant, wallyworld_: the discussion between sinzui, mrevell and I was that we think it's fine that manage disclosure only shows a partial view of security issues [01:18] basically the view of the security policy for your project [01:19] flacoste: Right. But it gets confusing for projects like U1, which may have both proprietary and security bugs. [01:19] with a warning saying: some people might have access to some security bugs through other projects [01:19] flacoste: i think that's workable [01:19] We need to present that somehow that they're different. [01:20] poolie: You are awesome :D [01:21] now do something useful with it :) [01:22] poolie: Sure will, I just need to build a logging/reporting tool for it :D [01:22] poolie: do you take bribes to allow users to "get in" on the feature :-) [01:23] sounds like a business model to me [01:23] wgrant: is it really a problem? either these security bugs are really private and they won't share it, or they are security bugs (and say also affect Ubuntu) in which case the warning is good enough [01:23] more seriously you can always have something turned on either by membership in a team or by being lucky with your uid [01:23] or vice versa [01:23] flacoste: Well, we have to make it clear that it shows everything for one tag, and not everything for the other. [01:24] Which is confusing, because in the current designs they're shown identically.. [01:24] wgrant: yes, but a simple notice is probably good enough [01:24] Heh, users don't notice notices. [01:24] Ever. [01:24] agreed [01:25] wgrant: you are in "glass half empty"mode today :-P [01:25] today? [01:25] What poolie said. [01:25] but the assumption here, which should be tested, is that users have different assumptions between privacy and security [01:25] flacoste: At present they have the same assumptions, because they behave the same way. [01:25] so the fact that other people have access through the shared project security policy isn't surprising [01:25] lke it would be for private bugs [01:26] flacoste: there will be some adjustment to users' thinking when security and privacy an de-conflated, but the overall; result will be much easier to grok i think [01:26] wallyworld_: that's what sinzui though when I suggested that we keep multi-tenancy around security bugs [01:26] thought [01:27] flacoste: i liked your email. enum for privacy/visibility with orthogonal security flag [01:27] agree with security bugs being multi-tenanted so conversations can be shared [01:27] huwshimi, let me know howmuch you care about slicing anonymous users [01:27] my impression is they do not have very interesting interactions [01:28] I don't agree that multi-tenancy is the solution to shared conversations. [01:28] mm [01:28] But it may be the easiest way out for now. [01:28] i wonder how many non bot requests are anonymous [01:28] poolie: A quick grep should tell you... [01:28] indeed, i will do that in a sec [01:28] wgrant: yeah, i can agree with that [01:28] but the real question is do people ever want to run experiments on them [01:29] wgrant, though i wonder too how many anonymous users are also blocking or ignoring cookies... [01:29] poolie: True. [01:29] we can possibly find that too [01:29] even some non anonymous users block cookies [01:29] well, those who care about privacy [01:30] uh [01:30] Well, if they're not anonymous to LP they're probably allowing at least one LP cookie :) [01:30] not if they want to sit at the big people's table [01:30] "big people's table"? [01:30] you cannot be both logged in and also blocking lp's own cookies [01:30] wgrant: yeah, sadly i had to add lp to my whitelist [01:31] wallyworld_: Yeah :( [01:32] poolie: I guess we could always build that into into the reporting, there would certainly be some a/b test where we would be targeting logged out users. [01:32] spm i have a thing for you too: https://code.launchpad.net/~mbp/launchpad/feature-admin-party/+merge/84044 [01:32] wgrant, would you mind doing a security review of that one? [01:32] it is not very big but it is a little scary [01:32] Admin party? [01:32] Aha [01:32] when you first start couchdb, it says "Admin party! Everyone is admin!" [01:33] There seems to be a false assumption th ere. [01:33] Why would anyone willingly start couchdb? :) [01:33] *if [01:34] I'm not sure if we should really do this. [01:34] We have non-Canonicalers in ~registry, for example. [01:34] istr robert approving it [01:34] And even Canonicalers aren't always going to be aware of what implications flags have. [01:34] the concept that is [01:34] perhaps ~registry is the wrong thing [01:34] (there are security-influencing flags) [01:35] wgrant: Diff updated. [01:36] i think we should probably be careful about putting really dangerous things in there [01:36] in the first place [01:36] mmm [01:37] StevenK: DriverPrivileges and PrivilegesContext? [01:37] i guess making it a specific group would let us flip this at run time [01:37] without a boostrapping problem [01:37] StevenK: We probably want BugSupervisorPrivileges(Context)? and DriverPrivileges(Context)?. [01:39] lifeless, what do you think? [01:41] i had the idea it had a preimp approval [01:42] poolie: https://bugs.launchpad.net/launchpad/+bug/790025/comments/1 is all I had said [01:42] <_mup_> Bug #790025: provide LP developers full access to QAS/Staging feature flags

< https://launchpad.net/bugs/790025 > [01:43] poolie: heh, scratching an itch there? [01:43] i was going to do the userslice thing when i was offline yesterday and then i remembered this [01:44] poolie: I think there are two issues; A) there is a code structure issue, which I've reviewed. B) there is the how-to-enable-it [01:44] and yeah, it does seem like somewhat unnecessary manual handoffs [01:44] wgrant: PrivilegesContext is the current name and is still called everywhere [01:45] yeah [01:46] there are some precedents for the inline permission check [01:46] but not necessarily good ones [01:49] lifeless, so if it's hooked in differently and it is enabled by adding people to eg ~admin-features-rules [01:49] that would be acceptable? [01:50] poolie: are you proposing admin-feature-rules as a celebrity ? [01:51] i guess effectively yes [01:51] i understand some of the machinery around celebtrities is disliked? [01:52] it depends a bit how much you expect to want to change it dynamically [01:53] so the thing about celebrities that is disliked is largely the fact that its a well known team. [01:54] so avoiding the rest of the machinery but blessing a team name will just get the bad stuff without mitigating it via the other supporting code [01:54] ok [01:54] so what is the actually preferred place for configuration? [01:54] or rather policy [01:54] zcml or lazr.conf or feature flags [01:55] i hear config is disliked, zcml is disliked, embedding it in the code is disliked [01:55] are the three generic places we have [01:55] or schema things hanging off of objets [01:55] theres no 'site' or 'instance' object in the db today [01:58] hm [01:58] what defines who has a particular permission on a particular object? [01:59] the security adapters [02:02] hm [02:03] so i see there are things that grant some permissions if user.in_launchpad_developers [02:03] s/things/adapters [02:05] perhaps i'll leave it, it was more of a drive by attempt [02:09] StevenK: The callsites can and should be changed... [02:09] It's a pretty trivial refactoring across part of one codebase, which will result in cleaner, more maintainable code. [02:10] lifeless: https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-ce9f40e4e0a1507f99c1f0eda494ae39 [02:13] wgrant: win! [02:13] Rather. [02:14] a unicode string [02:14] wtf [02:14] wgrant: care to file a bug for me? I'll add a codepath to type-handle this [02:15] also someone should shoot the zope machinery [02:17] lifeless, is there enough value in pulling out the DemoSite fixture? [02:18] afk -> bank visit, bbsoonish [02:51] wallyworld_: In those prototypes is the "Add an observer" link for adding a privacy observer? [02:51] or security as well? [02:51] huwshimi: it adds the person ad both atm [02:52] as [02:52] from there you can use the popups to change [02:52] but we need to enahnce the picker [02:52] wallyworld_: That seems suboptimal. [02:52] yes, the picker needs to be enhanced [02:53] but we didn't want to do that for the mockup - ran out of time [02:53] sure, just checking [02:54] np [02:55] wallyworld_: Also the 10 users can view project information [02:55] 6 users are observers [02:55] 5 users are restricted observers [02:55] block seems to be a little redundant as it doesn't cater for security/privacy [02:55] Not sure what to do with that [02:55] Is it actually useful for anything? [02:56] those numbers are now used to represent users who have any sort of permission (security or privacy or ...) [02:57] wallyworld_: I guess that info can now be determined by using the filters [02:57] wallyworld_: And jumbling the stats together as they are now doesn't seem useful (but tell me if I'm wrong) [02:57] yes, but the portlet is useful because it shows users with *any* observer access for example [02:57] but that's just my opinion [02:58] as a project owner, that's what i'd want to see [02:58] wallyworld_: is that useful if you don't know if they can only see apport bugs or something? [02:59] of course we'd add that into the nav portlet in the final version [02:59] what's there now is based on the original screenshots before these new things were thought of [03:00] wallyworld_: Right, that's why I'm trying to determine how this should look now that we have that new info [03:01] ok :-) [03:01] (btw I'm doing a whole new set of mockups, so this isn't me asking you to do anything at this point). [03:03] "of course we'd add that into the nav portlet in the final version" <- what is "that" in this sentence? [03:04] the summary of number of apport bugs and "quicklink" [03:04] (and any other quicklinks deemed necessary) [03:05] wallyworld_: So there would be a list of each "tag" with the number of observers/restricted observers? [03:05] perhaps. that's what i would want to see as a user [03:06] sort of a shortcut to using the search form [03:06] but that may not be feasible for the number of tags we have [03:06] it's really up to the users to ask for what they want in that portlet [03:07] ah, scratch that comment about number of tags [03:08] the portlet has roles (observer, restricted observer) [03:08] plus any other shortcuts we want to add [03:08] or are asked to add [03:08] wgrant: Have another look? [03:10] StevenK: It seems sort of odd to call it as a method on a bugtask, but still have to pass the context in manually. [03:11] wgrant: I have no choice -- the main call sites don't have a BugTask. [03:11] StevenK: That's why there was a separate *Context method before. [03:13] wgrant: You'd like me to duplicate the current methods to Context and context-less versions? [03:14] StevenK: Yes. The implicit context version of userHasBugSupervisorPrivileges seems to already exist, but it's called userHasPrivileges. [03:16] poolie: I think showing the evaluated flag values is ok; just the scopes are the issue. [03:55] wgrant, wallyworld_: In the prototype where it says "Subscribed to 6 bugs and 4 branches" is "subscribed to" the right wording there? [03:56] No. [03:56] nope [03:56] "subscribed" is wrong. [03:56] It's not clear what the right wording is. [03:56] the wording is/was true to the originally supplied screenshots [03:56] I want to dump "observer" and say "access" or something instead. [03:57] private things shared with you [03:57] "access" sounds ok for now i think [03:57] isn't that the concept ? [03:57] yes, but we need a single word or two [03:57] 'shared with' [03:57] huwshimi: Where in the prototype does it say this? [03:57] I haven't looked for a while. [03:57] also why are we showing counts. [03:58] wgrant: http://people.canonical.com/~ianb/disclosure/ [03:58] 'shared with' sounds ok [03:58] counts? as per the original screenshots [03:58] i personally like them [03:58] which original screenshots ? [03:58] i would want to see them as a user [03:58] So, showing the counts outside the context of a particular policy probably doesn't make sense. [03:59] the balsalmiq ones from 18 months ago [03:59] not sure who did them [03:59] I still suggest [Proprietary: everything] [Security: 2 bugs, 4 branches] or something like that. [03:59] I was thinking the heading could be changed to "Disclosed bugs and branches" and the the content could just be the count "6 bugs and 4 branches" [03:59] Kills off the column, and destroys the probably deliberately obscure "observer" terminology. [03:59] that works [03:59] rule of thumb: showing precise counts is expensive. Unless it matters, don't. [03:59] is that doing too much for a summary though? [04:00] in this case, what matters is that you can click to expand the user/team and see what they have access to. [04:00] i guess it's up to the users whether it matters [04:00] I don't see how the exact count matters. [04:00] (after all, its potentially wrong as soon as we render the page :)) [04:00] as i user i'd want some indication, perhaps not an exact count [04:01] sure, and so are amazon stock counts on their order page [04:01] lifeless: As an OEM project manager, I need to grant a distro engineer access to one of my bugs, to get their expertise. [04:01] but they still show them [04:01] wgrant: then you need to know that their access is restricted. [04:01] On the disclosure management page, I want to be able to see that he doesn't have access to 2000 bugs. [04:02] actually, shopping sites normally show < 5 in stock or > 5 in stock or whatever [04:02] wgrant: But how do we show that without an exact count? [04:02] so not exact counts [04:02] wallyworld_: right, because thats all that matters to the user: can they make a reasonable order and get instant delivery. [04:02] i think we need some indication, but not exact if it's expensive [04:02] wgrant: so do you want a whiteboard to say 'this engineer should only access branch X' ? [04:02] wgrant: how will the project managers coordinate things? [04:03] anyhow, if the schema can do it brilliantly-fast, thats cool. It just sets off alarm bells every time I see this. [04:03] lifeless: Note that "the schema" is now invalid :/ [04:05] tales question -

- fails because foo is not yet defined for the condition check [04:05] what's the best way to get around this? [04:06] i guess i need to use a nested div [04:07] foo is a collection ? [04:07] So, do we want the "Disclosed bugs and branches" column and if so what will the content be if it's not exact counts? [04:07] sorry, somefoos is ?. anyhow, the condition runs before the loop [04:08] somefoos is pseudo code. bugger about conditiob running before loop [04:08] i'll have to rework the tales [04:08] i want the condition on each item in the loop [04:09] huwshimi: we want the column with approx counts i reckon [04:10] wallyworld_: How do you represent an approx count? [04:11] that's for you as ui designer to tell us :-P [04:11] "~ 4 branches" ? [04:11] or perhaps "< 10" or ">10" [04:11] wallyworld_: Right, but I have no idea what an approx count is [04:11] wallyworld_: Ok, thanks [04:12] one of the reasons I was challenging the column is that it will get long [04:12] bugs [04:12] branches [04:12] 10 is arbitrary [04:12] milestones [04:12] series [04:12] blueprints [04:12] answers [04:12] wallyworld_: So we can get the database to return roughly what the user can see? [04:12] will all eventually be assets accounted for [04:13] huwshimi: we can ask it to estimate, it sometimes is spooky accurate, and sometimes heinously wrong [04:13] lifeless: can postgres return approx counts efficiently? i think so, based on previous irc conversations? [04:13] lifeless: Ah great. Thanks [04:13] it can return the plan estimate [04:13] but it would be accurate for small numbers no? like > 10 or < 10 ? [04:13] sometimes [04:13] wallyworld_: but would we no whether it was >10 or <10? [04:14] wallyworld_: or just ~10 [04:14] not sure [04:14] *know [04:14] i don't think it matters [04:14] i would just want to know if my exposure to that user is big or small [04:14] wallyworld_: Well it matters in how we represent it [04:14] to catch situations like wgrant described above [04:15] hmmm [04:15] wallyworld_: 10, >10 and <10 are all very different things [04:16] yes. i don't think we need "10" though. [04:16] i would want to know < some number or > some number [04:17] maybe we should kill this column and if people want to know what the user can see they have to view the person/team details [04:17] cause >10 is really a meaningless number to represent [04:17] perhaps, especially if it expands to more than bug and branches [04:17] > 10 is not meaningless - it depends on what you want to know [04:18] wallyworld_: well it is meaningless if the exact number is 2,000 [04:18] ie have you accidentally allow the user to see more than just the 1 or 2 branches you assigned them to [04:18] wallyworld_: I know in reality the estimation won't be that far off, but the user doesn't know that [04:18] Er [04:18] huwshimi: it may be that far off [04:18] The estimation may be orders of magnitude off. [04:18] huwshimi: approx *really is* approx [04:18] lifeless: Oh [04:18] the accuracy depends a great deal on how complex the query is [04:19] lifeless: OK, thanks that helps make the decision :) [04:19] lifeless: is it accurate for 0 or not 0? [04:19] wallyworld_: no [04:19] wtf? [04:19] It doesn't use indices. [04:19] wallyworld_: 0 is not special cased [04:19] It uses randomly gathered stats. [04:19] weird design then [04:19] wallyworld_: row count is just a vector, how many rows it thinks will be returned. [04:20]