I think this is probably the cleanest fix, but I only tested event imports (which now appear to work). If you want to test Maniphest with subtypes configured (to make sure it doesn't break) and send me a revision with this change, I'll review it. Otherwise, I'll do that testing when I get a chance and land this if nothing crops up.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Oct 3 2021
Aug 20 2021
Aug 19 2021
Mar 29 2019
Mar 28 2019
Mar 27 2019
Feb 12 2018
See Planning.
Is there someone working on this feature?
Dec 21 2017
The apparent lack of support for scheduling in UTC in much more mature calendar software (Google Calendar / Calendar.app) further suggests that this is not an important feature for most users.
Nov 29 2017
Nov 28 2017
@epriestley what do you think of creating another column in the calendar_eventinvitee table, something like a bool futureStatus so that when we get a list of invitees back, we can check for that flag. I think this would mean a lot of date comparisons (seems inefficient), and I'm not quite sure when to populate event stubs. For example, if the futureStatus flag is set to true for instance 10, and there are stubs for instances 15 and 20, when would 15 and 20 get converted to have the updated status?
Aug 31 2017
@mna Please follow our bug reporting guidelines if you feel you've encountered a bug. This task is several years old and not relevant.
Hi everyone, when I open the datepicker (e.g. via https://secure.phabricator.com/calendar/event/edit/form/default/ ) today (it is August 31st), then it defaults to today (August 31st).
Aug 16 2017
@epriestley @jdiepenmaat If I may add ideas on that. I am using Things at the moment. There are only two reasons that hold me back to finally and completely switch to Phabricator:
- recurring tasks
- start dates for tasks
The latter is basically what your example is about, right? Because if I have just renewed the SSL certificate then a new task is created (due date being in one year), but it should not possible to start that right away, as it's not necessary. You would use a start date as well, wouldn't you?
Aug 6 2017
I can confirm this.
Jul 27 2017
This almost certainly has nothing to do with being invited via a project. I'm just going to merge this into T10448, which will moot it.
Jul 13 2017
I've seen complaints about this on phabricator.wikimedia.org as well, so I can confirm that this is an issue.
Jul 11 2017
Hm, this screenshot made me dig a bit into the whole thing, so here is what I've found:
First, my date format is different because of my settings:
Why does your date format look different than ours? Is that a local modification or do we support this somewhere I'm not aware of.
Merging over so there is one thread on this topic. We're happy to reopen if you have new reproduction steps we can follow or if you can verify on a Phacility test instance.
I can't reproduce this (again)
Here's the proof: F5042439
Jul 10 2017
Jul 9 2017
Jun 30 2017
I think it's probably reasonable for us to warn about RSVP'ing to an event which has already ended. I'd guess this is usually a mistake, and in cases where it isn't some kind of weird off-label workflow is taking place and the warning is probably fine.
Jun 29 2017
Jun 13 2017
Should not, but looks like there are. I updated to master now, and it works now.
I used the current version, but there should be no meaningful changes to this behavior between your version and HEAD.
That's weird since I exactly did the same with my version from above. Did you used the current or my version? Or should I update and try if I can reproduce it at the master?
I can't reproduce this. Here's what I did:
Version infos are:
phabricator 0d1654446be6de43b2bd12fcc247db0dc1a46464 (Sat, Jun 10) arcanist c04f141ab0231e593a513356b3832a30f9404627 (Fri, Jun 9) phutil 74a1350416eb2df825c2315d6519bee03f77bee9 (Mon, Jun 5)
Jun 12 2017
Jun 11 2017
May 9 2017
In T7930#215278, @isfs wrote:Something that would be useful to us would be the ability to create, or probably better, assign a task, as it nears a due date. E.g. we may set up a task due in a year's time, and anticipate working on it two months before it is due. It would be great to be able to schedule the task to be assigned on a particular date, and perhaps moved on a workboard. I don't think this would need to be any more complicated than a Herald action that runs at a particular date/time rather than in response to some other action. I'm not familiar with what Calendar can already do, as we don't have prototype applications turned on for our install, so apologies if this is already possible. I just thought I would mention this use case here for future reference.
The recurring and due date use cases in the previous comment would also be useful to us. I would prefer something more natural for the formulation, though, e.g. for tasks:
- when [Father Time] [reaches] value in [Due Date] (or other selected field), [Assign to] [ben].
- when [Father Time] [is one week before] value in [Due Date] AND [Status] is [any open status], [Set priority] to [High].
- when [Father Time] is [one month after] value in [Creation Date] AND [Status] is [any open status], [Send email notification] to [manager].
It would be great if task Due Dates (or other date fields, conceivably creation date could also be useful) could (optionally) appear on a calendar.
May 1 2017
I cancelled and reinstated E1486 to force a cache clear with the new code, which seems to have resolved this in production.
I think we're too conservative about invalidating this cache. To reproduce:
Apr 25 2017
@epriestley, what's weird is, I still have this on my bug install, despite having the latest stable updates. I checked, and the migration definitely ran. Thoughts on how to debug this further?
Apr 18 2017
KDE has some interest in this as our contributors are distributed around the world.
Apr 17 2017
I originally posted this feature suggestion because I needed to put a tradeshow event in the calendar. The tradeshow took place in another time zone, and when I got there I realized that the calendar entry was on the wrong day. I also frequently schedule conference calls with clients and suppliers in other time zones.
@chad Like I said I'm aware you guys don't support prototype apps, figured I'd just make someone aware of it, not looking to make it work right now.
Oh, Calendar is a prototype. :/
Do you mind verifying the bug on an up-to-date version of Phabricator?
Apr 12 2017
Crazy, I guess I'm in some project called ? ?
Can you unhide the event please so I can fix my notifications?
Well now I have 4 notifications I can't see or reset. :(
Sorry, I should have thought about that!
@ivo Just a reminder this is a real install, please do not create test events on it. You can use a free instance on http://phacility.com/ if you want a clean, up to date install to test against.
Apr 10 2017
In T11073#218937, @epriestley wrote:Do you routinely schedule events in timezones other than UTC or your local time?
Do you routinely schedule events in timezones other than UTC or your local time? If so, why? (For example, do you frequently travel between two timezones? Do you schedule events on behalf of a team that works in a different, non-UTC timezone?)
In T11073#218834, @epriestley wrote:I'm just trying to understand whether this is a common problem that all users of Calendar software routinely experience
- After D17646, event reminder mail should render with timezone information.
- Additionally, timezone information in this mail and other modern ModularTransactions mail will now render with timezone abbreviations where available: (PDT) instead of (UTC-7), for example.
- I wasn't able to identify or reproduce any actual bug here. Hopefully the additional information in D17646 will make it clear what's happening. The expectation is that the mail you receive should use the same locale as your account uses in Settings → Date and Time → Timezone, and in all my local attempts to reproduce this that was the case. Note that if an event is scheduled in UTC but instances cross daylight savings time in a particular locale the local time of the event may change. I don't think that's what happened here, just mentioning it. See also T11073.
I think this is a legitimate bug where the viewer's timezone on the event becomes stuck as the last invitee we process, so events with multiple invitees in different timezones can generate mail with the last user's timezone.
Go ahead and create a new request -- knowing which things people actually want/use will be helpful since other calendaring applications seem to have very complex controls here without much consistency and with different supported sets of capabilities.
Fair enough. I think that if "on the $nth $weekday of the month" and "on $weekday every $x weeks" were to be supported, we would technically be able to schedule all events in Calendar. Do you know if support for this already planned somewhere, or should I create a new feature request?
Future instances of recurring events aren't visible in panels when an item limit is set:
I'm just trying to understand whether this is a common problem that all users of Calendar software routinely experience, or a problem that is experienced much more strongly at WMF that by most other users.
In T11816#218816, @epriestley wrote:
This is her status at 13:45 today...
She doesn't have any events till 14:00 today.
I believe this occurs only if an install has improperly migrated legacy data. This install does; presumably yours does as well.
ICS issues seem to have calmed down so I'm going to call this resolved; future issues can just be filed as separate tasks.