Nuance - get some scaffolding up there
ClosedPublic
Actions

Authored by btrahan on Oct 30 2013, 11:29 PM.

Details

Reviewers

epriestley

Commits

Restricted Diffusion Commit
rP66ae64f7bc29: Nuance - get some scaffolding up there

Summary

I updated the wiki too - https://secure.phabricator.com/w/projects/pebkac/ - with what I am thinking right now. Rough plan here is

next diff:
- implement editors and transactions
- implement "web type" for contact source
  - /pebkac/item/new/ will be the entry point for this
- implement "actions" on a contact
- probably some "polish" on the scaffolding laid out here; like "create" permissions maybs
diffs after that:
- implement "twitter" type for source
- implement email reply handler stuff for item and source

Probs a great time to blast huge holes in all this stuff. :D

Test Plan

these pages load and arc lint doesn't complain

Diff Detail

Branch

pebkac

Lint

Lint Passed

Unit

Tests Passed

Event Timeline

some comments on schema for potential discussion

resources/sql/patches/20131030.pebkac-contact.sql
10 ↗	(On Diff #16820)	I envisioned this different per contact source type. Twitter might have all sorts of fun data here like the mentioned users and stuff.
18 ↗	(On Diff #16820)	in theory a queue will have source x, y, z so a common query will be where sourceid in (x, y, z) and status = 'un-assigned' the dateSupported thing is because you want the contacts that haven't been supported in a long time to come up
20 ↗	(On Diff #16820)	Since contacts can come from all over, I envision having to make some sort of hash out of whatever identifier I can get. For the "web" contact source, this can be the Phabricator user id.

How attached are you to "PEBKAC" as a name? I don't love the implication (that users are the problem) -- it feels a little tacky/crass, maybe? And it's kind of cumbersome (e.g., both "PEBCAK" and "PEBKAC" sound valid when expanded). I'll see if I can come up with some alternatives.

This otherwise seems reasonable to me, maybe with a slightly inclination to generalize. For example, I'd like to run content review through this application some day, but "Contact" and "ContactSource" aren't great fits for that, I think. My first instinct would be "WorkItem", "WorkSource", "WorkQueue", etc? I could even imagine dumping tasks or, say, users pending approval into a queue or something. These are all "contacts" in some very vague sense of the word, but it might be useful to think of them as "human work items".

Eventually, I think Sources should have routing rules into Queues -- so you could send most tweets to the "Support" queue, but other tweets to the "PR" queue or something, rather than simply grouping Sources into Queues. For now, routing them 1:1 makes perfect sense.

One object I don't see discussed here is the "contacting user" -- e.g., whoever's tweeting at us or whatever. It seems like that should be a major object too, so we can pull "past stuff this user has done" and such easily?

epriestley added inline comments.Oct 30 2013, 11:55 PM

resources/sql/patches/20131030.pebkac-contact.sql
18 ↗	(On Diff #16820)	I think this is completely reasonable for now, but in the long run I think we should think about putting items in queues explicitly based on routing rules and have a separate table for the queues, for performance and flexibility. Beyond routing, being able to have stuff like let a support person say "escalate this into the Legal queue, this guy is threatening to sue us" seems useful, but is tricky if queues are determined purely as a function of source.
20 ↗	(On Diff #16820)	My first thought is to make "contacting user" a real object with a PHID, and then use PHIDs here. Are there reasons that doesn't seem like a good idea?
30 ↗	(On Diff #16820)	Maybe this mail stuff should be on the actual contact, not the contact source? Basically, "reply to thread", not "reply to twitter"? Are there cases I'm just missing?

Thanks for the feedback. I'll try to incorporate the two big concepts I missed - contact users and queues - as I think its very time efficient long term to get these building blocks right. The generalized ideas re: contact are solid too.

Not attached to the name pebkac at all. Note I don't think the name necessarily needs to be exposed to customers.

Some ideas for other names, in the "human work items" scope, most terrible:

sisyphus
- shares cons of pebkac
- in a generalized version, many of the work items will be sisyphusian
processor
- "yeah, going in to processor and doing 1000 legal work items feels like a sisyphusian task"
operator
operations
turing
turingworks
turk
turkey
turkworks

resources/sql/patches/20131030.pebkac-contact.sql
18 ↗	(On Diff #16820)	sounds good
30 ↗	(On Diff #16820)	I envisioned there being discussion on a given contact source, such that folks might want email integration to reply to the various ongoings there. The mail stuff is also on the contact.

...or maybe we can call it "workwork"

I probably like "Processor" the best out of those, although it's not too flavorful.

I haven't come up with much yet: Inphlux (we'd have to rename Phlux) or Inphlow, Frenzy/Phrenzy, Refine/Rephine, Upheave (in my mind, this somehow connects to "Desk" via upheaving/flipping tables?? and it has a "ph"), Counterspell, Amphora (no relation, just a nice word), Labors (Labors of Hercules?), Fray/Phray, Baffle? I could also see calling it "Quest" and playing it off like it was a fun game.

resources/sql/patches/20131030.pebkac-contact.sql
30 ↗	(On Diff #16820)	Ah, yeah, that makes sense.

Zug zug! Dabu!

aphable (affable) ? aphably?

I was told there would be no new app icons needed for 2013. I feel shammed.

@chad - we can just use a broken image.

Last name suggestion for the night - Genuity

s/pebkac/nuance/g
re-jigger object model a bit
- item
- requestor
- source - source for items and requestor
- queue - collection of items
- transactions for the 4 big objects
slap in more empty-ish objects for all this stuff

Some minor inlines, but this all looks reasonable to me.

resources/sql/patches/20131030.nuance-v0.sql
9	I think this `CHARACTER SET utf8` is redundant.
src/applications/nuance/application/PhabricatorApplicationNuance.php
6	(We should fix these.)
10	Dupe with Conpherence? We should switch one or the ohter.
src/applications/nuance/controller/NuanceItemEditController.php
27–28	Consider `NuanceItem::initializeNewItem($user)`, which we've generally been needing as applications get default policies. I'm not sure if they'll make sense here or not, but it seems like a reasonable pattern.
src/applications/nuance/controller/NuanceItemViewController.php
16	For controllers where the capture isn't optional in the route, consider using `$data['id']` instead of `idx($data, 'id')`. The advantage is that you'll get an exception ("array index does not exist!") if the route is ever edited incorrectly or we arrive here by accident somehow. Basically, we expect to always have 'id', and if we don't it's a programming error, not a user error. `idx()` masks this error.
24–26	I'd probably skip this check: It isn't possible unless the route changes, since the route can not match "0" or empty string. Even if it becomes possible, the identical check below will handle it properly.
46	(Everything above applies to all other controllers.)
src/applications/nuance/storage/NuanceItem.php
12	This is `dateSupported` here, but `dateNuanced` in the schema, I think.
13–14	Should an `Item` really have its own policy? It seems like the policy should maybe be: You can see it if you can see the source and any queue it's in. The requestor can always see it (with grey login or whatever sorted out). (The owner can always see it?) What sort of use cases are you thinking about?
src/applications/nuance/storage/NuanceQueue.php
7	I'm not sure we should have this property. Queues don't feel very personal -- they seem more like repositories (which have no permanent/special owner) than revisions. Are there use cases this supports? Particularly, the special cased policy exception. My initial thought is that they should be ownerless/creatorless (the actual creator will appear in the transaction log, of course).
src/applications/nuance/storage/NuanceSource.php
7	As above, having a strong creator here feels weird. It doesn't seem like I should always have access to this object just because I happened to add "Twitter".

Thanks for the feedback. Will hammer all that out.

Inline about the grey user stuff. This is potentially juicy. :D

src/applications/nuance/storage/NuanceItem.php
13–14	Well, we have some permissions issues here. For example, when someone complains on twitter (publicly) we can't do much to authenticate them back into Phabricator. Ways to solve this I see - an Item would need to be publicly to be accessible if created from a source where we can't authenticate the requestor. this would end up being "read only"to the requestor or random internet user we could have a flow like user tweets complaint nuance auto replies on the tweet - "would love to help you - sign up here" sign up here has the user authorizing our app to be able to send (private) direct messages user does so, kicking off still more automation that sends the user a direct message with some hash or whatever so we can start getting our grey user on ...but maybe I am thinking of the grey user stuff super naively right now? The other use case of sorts was making a public knowledge base or otherwise just running all this in the open. I kind of figured we'd want to be wide open for Phabricator support, with a special queue for privacy type issues?

epriestley added inline comments.Nov 5 2013, 7:14 PM

src/applications/nuance/storage/NuanceItem.php
13–14	I think for truly public sources we just can't do anything -- imagine we get a post on 4chan or something over the 4chan API. We just have to accept that we can never authenticate the requestor. For some, like email, we can always reply privately and easily authenticate them. For Twitter, I think we could reply "follow us and we'll DM you details" or the requestor page could OAuth them with twitter and verify their identity. I'm not sure either of these would be worth building in the next year. But for anything we have OAuth with, we can give you `/nuance/stuff/9as8bfasnfn/` and then that page can say "We need to verify you are @whoever on twitter so we can show you your secret stuff. Click here to OAuth..". That will verify the account ID and we don't actually need to DM them. Should work for Twitter/Facebook at least. This is a bit simpler than the flow above, I think. We can grey-user pretty generally, and don't necessarily need an email address, just any verifiable external identity token. (Having public queue visibility seems reasonable to me.)

I'd never thought I'd say this but...

Oauth to the rescue!

made all discussed the updates with one small caveat:

NuanceItem policy doesn't fully work. I need to add the Requestor and the Queues to the overall data access pattern. If the Requestor is the Viewer, then yay auto capability! If any queue has a policy that lets Viewer view then yay getPolicy!

Tricky part IMO is the queues thing since they are N to 1 item. I am not sure how that's going to work to sort of loop through doing getPolicy, and I felt it couldn't really be tackled given there's so much not-quite-connected-stuff here. For another day!