Add some kind of notification to user accounts like "some email you would have been sent was dropped because you haven't verified your address yet"?

My plan here is:

My guess is that this is just something dumb and mostly out of our control, and we fell through the cracks because the email volume we send from this install is tiny. We sent 41,877 messages in January at a cost of $0.00 -- this is too few messages to even qualify for charges, which start once you send 2,000 messages in a single day.

🤔

The changelog from Mailchimp (opt-in only) is from noreply@phacility.com, but I can't think of anything else off the top of my head

Yeah: if it's important to identify duplicates because you use duplicates as a priority signal, making it easier to see a list of duplicates on the task detail isn't a very powerful approach.

Future instances of recurring events aren't visible in panels when an item limit is set:

In T12237#211025, @epriestley wrote:

Although I'm somewhat confused by this because it came to the address for my personal AWS account.

Related to paid prioritization, how much would it cost to terminate this task and also the ability to edit the time entries after validation (man does mistakes).

I appealed this, but the FAQ says "Due to the way spamtrap sending is reported, it will take a minimum of three weeks before we can confirm that a fix you have put in place has succeeded.".

@chad, just to make sure my ducks are in a row, you aren't using noreply@phabricator.com in association with any marketing mail, right? I don't want to claim "we only send transactional mail" if that isn't true.

SES is definitely rejecting mail, though:

Although I'm somewhat confused by this because it came to the address for my personal AWS account.

Anyways, I don't know what the root problem of this task is, like @epriestley mentioned above. Knowing the problem this information solves is what we're most interested in. It might be Facts, it might be something else. Basically, what do you do with this information? Why is it important? How often do you need it? What decisions do you make differently with it? Can subscribers be a better proxy for this information because it includes both hard duplicates and people who proactively found and followed the task?

I was referring to "A task with a lot of dupes might end up getting higher priority because of the number of dupes.". This kind of data should be pulled by facts.

Wouldn't that split up important data? A project manager will normally always be looking at the project board and moving tasks around there. Would it be cumbersome to have to go to some other application in order to do a query to figure out the relations on this one object? Not sure how you guys are thinking about Facts but going somewhere else for that info might be too cumbersome to do often. Especially if I'm jumping around a group of tasks in projects already. I would want that information presented there as well.

I'd rather solve that problem with Facts.

As to why it's important I think dependes on the style of project management being employed. Some places keep track of the dupe count as a way to gauge how often an issue is being seen or how many separate requests for a feature have shown up. A task with a lot of dupes might end up getting higher priority because of the number of dupes.

Maybe a more useful form of this would be some form of being able to view "how all related objects are related to this one". You can currently see related objects but you cannot easily tell the nature of that relationship for some of them. The task graph solves part of this for dependencies but not for other relation types.

T11050 seems to be describing a different issue. I don't mind having the review in my queue just not in the must review section.

Yeah sorry I was missin your step 2a from above. I guess this behavior just feels weird since it's saying specifically that I must review. As a user I intuitively think of must review as something that I have personally blocked. For user B to see must review makes sense. But I don't think the same applies to every other member of the project. It's ok for the review to remain in my queue under needs review. Just not all of a sudden upgraded to must review.

Revisions in the "Needs Revision" state (i.e., following the reject in step (2)) should never appear in "Must Review". I think the steps are missing a step "2a", where the author updates the revision with new changes?

Hey, one of our teams is experiencing this issue as well - many of their tasks include the name of a flag with a lot of punctuation, such as subgrowth_biz_buy_order_summary. At some point in the not-terribly-distant past, searching for these flags started to return 0 results.

Why is it important to see all the duplicates at a glance?

oh well

There's currently no way to query that, since the dashboardPHID is in a JSON blob in the PhabricatorProfileMenuItemConfiguration table.

One thing I'd like to bring back is "Install" in some fashion, which is easy to prompt and do the legwork on landing it on a home or project menu, but doesn't seem we can let you know where a dashboard is used and if you have it installed.

T12233 is an essentially identical case, although it discusses other analogous use cases (hide/shrink "Audits" if empty; hide/shrink "Reviews" if empty).

Also: I think it's reasonable that if no event has happened in some time (A week? A month?), the Taskmaster would take 15 seconds to react to come back when it's needed (i.e., allow auto-scale to 0 if last task was a long time ago, although I'm not familiar with how the overseer and daemon scaling actually works).

They support a set of 12 currently.

I just dropped her off at daycare but I will submit proof that she is alive and unharmed after I pick her up this evening.

send puppy pics please

See Planning for help on status and timelines.

From elsewhere, it would also be nice if this tokenizer highlighted instance members of instances associated with the billing account. There isn't a straightforward way to determine which "joe" or whatever is correct right now that works better than "ask Joe what his account name is".

Whats the status of this? Also is there any actual documentation for the existing @generated and differential-generated-paths functionality?

The most important aspect in flexibility is the ability to support all locales. MediaWiki uses a system largely based on PHP's date() for historical reasons, see Language::sprintfDate().

Sorry, I never tried to bother you.

In T12232#210902, @yelirekim wrote:

Yeah I clicked "Delete File" and can't see it anywhere now.

Yeah I clicked "Delete File" and can't see it anywhere now.

You destroyed the original file in Files too, right?

Edited to not give out my credit card number on the internet.

No problem, we're not in any rush.

(by the way @epriestley I haven't forgotten; some things have come up but I'll try to get back to you this weekend!)

Asking questions to the community first frees the developers up to fix bugs and make new features.

How do you suggest we handle reports/feature requests that have not been properly filed per our guidelines. Currently you've opened 4, and likely all 4 have not met our guidelines. Our guidelines are based on what it costs us (2 developers, unpaid) to give a basic level of free support to anyone. Without some base guideline, we become overwhelmed with support and are unable to move the project forward.

Humm I'm sorry but it's not a support question. I think It's a feature request o even a bug...

Great! Glad that worked out. I think the documentation is good enough given it's description. We'll keep an eye on it.

Thanks for testing @jcox!

verified

Thanks for the suggestion, we'll keep this task around if there is further interest we can always reopen.

This isn't a valid feature request. See Contributing Feature Requests and Describing Root Problems for what we take into the upstream. Specifically this needs a root problem described.

Unfortunately we don't take support questions as feature requests. See Support Resources for more information.

T12214 was the task.

I presume this was fixed on Monday with b33bb3714bdb, can you verify?

I've seen the same issue (on latest stable install).

Just to clarify, I tested it locally, not on this install.

Just to provide some more information, filling this feature request I realised that I like the fact that you have created two different forms (Bug and Feature Request) with the tags preassigned to avoid people "forgetting" to tag them.