How would you like the flow where you give permission to new users to work? In T4411, @chasemp expressed some concerns about using CC/Subscribers for this (particularly, that users can add other users to CC). Do you share those concerns, or is adding users to CC to give them rights satisfactory for you?

unless the Nuance entry was basically just a special task, where we could have to option to continue as normal while including the reporter

Development Log

Yeah, the "Security" use case is letting users see objects in a Space they normally don't have access to because they have some special relationship to those objects (for example, giving users access to security tasks if they reported them).

Looks like the feed_storynotification queries are the slowest ones; there's no objectPHID key on that table.

Can we get a fund initiative for making Fund work like Kickstarter? :P

Note that it takes your money immediately -- not when a specific goal is reached (so it's not like Kickstarter) -- but I'll, uh, do this proportionately sooner relative to how much funding I3 gets I guess, unless someone wants to separately prioritize making Fund work like Kickstarter.

Yeah, that seems reasonable to me.

@epriestley, could we simply invert the logic of DivinerAtomQuery so that it returns undocumentable atoms by default (and add withExcludeUndocumentable(true) to all existing callsites?

Unclear if this is really a 100-package limit, but some kind of limiting is probably happening.

They're a function of an individual commit instead of being a function of the repository as a whole, so we'd have to do a lot more work to support them (it's not meaningful to, say, "list all tags in the repository", as it is with Git), and I suspect they're not used much in the wild because of how they work. I'm not sure if this is true or not.

Development Log

Hitting this again.

T8415

I think you need to add a mention.

Thanks, looking at this now.

https://secure.phabricator.com/differential/diff/31781/ seems to fix this, although I doubt this is the correct solution.

Adding PhutilArgumentParser and --trace gives me the following output:

See T8398 for any followup issues.

This migrated cleanly on this install, although we only had one real mailing list plus a handful of old invalid test lists (although these errored out correctly). If you run into problems with the migration or otherwise, let me know.

These changes were fairly sweeping, so please let me know if you see anything suspicious with mail/feed/notifications.

This seems to be working correctly in HEAD. In particular:

Can't find any problems.

NOW I AM TESTING

I like testing.

In T8392#118222, @chad wrote:

Why don't we fix the Recaptcha module to work on LDAP?

You can also use "Return to Subscription" from an invoice/order directly, although it's in a sort of unusual place (upper right corner) that we don't use very often in other applications. My intent was to make it more visible, but maybe it's actually less visible.

You can get here via Billing > Subscriptions > Instance.

Some screenshots if that wasn't clear:

If you don't have automatic payment set up, choose a different payment method the next time you manually pay the invoice.

As far as I can tell, we're missing these:

One thing I caught is that things which use Transactions now need to implement ApplicationTransactionInterface. At least one object (PhameBlog) does not. I'll check the rest of the codebase and see if there are any more.

@carlsverre, this probably impacts you, too.

Here's a rough sketchy of my thinking:

I don't plan to give mailing lists their own Email Preferences panel

(Note that this stuff isn't in HEAD yet, but will likely land today.)

T8398 has guidance on what to expect when you upgrade.

Development Log

Since this is a relatively large task that's likely to end up with a hundred thousand subtasks, I'll try to summarize progress here periodically.