That is quite hard to protect against real people dedicating their time on spamming projects. As @epriestley mentioned, there are paid systems for that.

In T10215#197817, @epriestley wrote:

From what we've seen on this install, the "printer fax support" spammers are humans willing to go to significant lengths to overcome access barriers (they fill out Captchas, register and link GitHub/Google accounts, validate email addresses, successfully navigate workflow changes, originate from different remote addresses, and take actions slowly), so I suspect no automated system designed to deter bots will be effective against them. My best guess is that they're being recruited through Mechanical Turk or some similar system.

I can't remember if Phabricator already requires a confirmed e-mail address to do anything.

In T10215#197805, @brechtvl wrote:

• Custom Blender specific captcha or question that bots can't answer

Of course there's no totally automatic and reliable system, we're just trying to find something better than manually removing dozens of spam tasks every day.

We can also let installs send us all their data, we'll decide if it's spam or not, then we remotely delete any data that we feel like deleting. But we'd have to charge like a gorillion dollars per message to make this sustainable today.

Hi Matheus,

Nuance (Phabricator Help Desk) is the only reasonable way forward here I can think of, which puts new tasks into a private queue). Anything else is cat & mouse with spammers and that's just a huge time sink for us with no obvious benefit (99% of installs are private).

What sort of reliable and automatic solution are you hoping for? How could the system reliably, automatically detect that a user is a spammer or that a task assignment is unwanted?

The past few days we've had a lot of spam on the Blender phabricator instance. These spammers are also assigning tasks to random users, who then get emailed. See here for examples:
https://developer.blender.org/maniphest/query/all/

Ah thanks, I was concerned there was an actual bug - not just a questionable design decision. This isn't easy to fix, and may lead to a completely different design to resolve - we'll keep this open to see how many people run into it.

No, this is a prototype application.

Is there any documentation on how to get started with this?

As you described, the model would be very complex considering a task can be in more than one subprojects, or a milestone. Why is it needed to have separate columns for subprojects in a parent project's workboard?

The blue group icon does hide the box. It didnt occur to me to try that, as it is not inside the box frame. I did look at the + beside participants, but guessed correctly that was only add.

After D16714, the problem tasks should complete cleanly.

This feature request doesn't describe a root problem. See Describing Root Problems and Contributing Feature Requests for help filing a feature request which we'll consider.

D16714 should fix this by adding an implicit byte limit.

Differential also currently does not substitute a diagnostic message when declining to inline a patch: it should. ("Patch is too big to inline because limit X is set to Y." or similar.)

An additional inconsistency is that the diffusion.byte-limit applies to attached patches, but the differential.byte-limit does not. There's some vague argument for this behavior (you "shouldn't" be reviewing patches which are so enormous that they can not be emailed) but consistent behavior is probably better.

Sorry, "tomorrow" definitely didn't happen. Looking at this now.

Some possible implementations of this expose an open redirect (e.g., by passing returnURI=<something> where <something> can be anything). An open redirect here isn't necessarily inherently dangerous, but the minor inconvenience we'd avoid probably isn't worth the security risk.

Broadly, I think this is better expressed as "Commits in rXYZ on master, including build status" than "Builds of commits in rXYZ on master". Diffusion proper already shows build status in commit lists, although the commit query in Audit currently does not. This probably won't get an update until T10978 happens.

If you have an exact Android version/browser I should test, let me know. We can also just make this smarter if you left it open on desktop (it should be off by default).

This is expected, either we have full remarkup, or we don't. T3278 covers the general infrastructure work needed, but I don't expect this to be pursued for some time.

and I cant dismiss the participant list box.

It also occurs in landscape for my mobile. LG D335

And "request desktop site" does not work.

Still failing as of today (rarely though):

Building in workspace /Users/admin/Jenkins/Home/workspace/Hyper-tvOS-AdHoc
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url ssh://hyper@vault.phacility.com/diffusion/HYPER/hyper.git # timeout=10
Fetching upstream changes from ssh://hyper@vault.phacility.com/diffusion/HYPER/hyper.git
 > git --version # timeout=10
using GIT_SSH to set credentials Phabricator
 > git -c core.askpass=true fetch --tags --progress ssh://hyper@vault.phacility.com/diffusion/HYPER/hyper.git +refs/heads/*:refs/remotes/origin/*
ERROR: Error fetching remote repo 'origin'
hudson.plugins.git.GitException: Failed to fetch from ssh://hyper@vault.phacility.com/diffusion/HYPER/hyper.git
	at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:763)
	at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1012)
	at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1043)
	at hudson.scm.SCM.checkout(SCM.java:485)
	at hudson.model.AbstractProject.checkout(AbstractProject.java:1276)
	at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:607)
	at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
	at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529)
	at hudson.model.Run.execute(Run.java:1738)
	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
	at hudson.model.ResourceController.execute(ResourceController.java:98)
	at hudson.model.Executor.run(Executor.java:410)
Caused by: hudson.plugins.git.GitException: Command "git -c core.askpass=true fetch --tags --progress ssh://hyper@vault.phacility.com/diffusion/HYPER/hyper.git +refs/heads/*:refs/remotes/origin/*" returned status code 128:
stdout: 
stderr: ssh_exchange_identification: Connection closed by remote host
fatal: Could not read from remote repository.

Going to pass on this overall, not sure it's worth effort an I'd rather 'pin' favorites that be able seem room #10 from the list of most recent rooms. Happy to revisit if it seems to scratch an actual itch users have.

Closing since most of the v4 UI is complete and there will only be minor polish going forward with other tasks.