After you add the phutil_tag for the "View More" link, add a class to it, phui-calendar-month-get-more. Then go to the css file specified on line 63 and add that class to the bottom of that file, with position absolute, height of 18px, padding to line up with the text of the events, and a color of {$lightgreytext}.

The Calendar application has several different builtin queries that provide different views of Calendar events:

• Month view
• Day view
• Upcoming view

This might not be fully correct, but it should get you a little further:

In the middle of refactoring the search engine, started writing a custom date search field, but I'm not sure how to get/set it's value.

The problem was that all-day events were not in the correct timezone (we store them as UTC, but then convert them and pretend they're not UTC). Another problem that I discovered was that we weren't generating ghost events to see if any of them fit inside the "3 day availability window". There is one thing left here, and that's to figure out how to avoid getting a rawResultLimit of 0 - placeholder T8613

I have a repro for this if you don't.

Sorry about this. Hopefully, I'll land a fix in the morning, but if you need to see events asap, the workaround is to use /calendar/query/advanced/. The issue is with saved queries, and advanced search is not a saved query.

I can confirm this. I got this error when viewing the agenda widget on my dashboard today:

When creating/editing events, transaction feed stories are generated for every transaction applied to the event object. Sometimes, the feed stories are grouped and prioritized, so that not all stories are visible. But each transaction that can be displayed, should have better text. Currently, event transactions for the recurring information should only be applied when creating an event, since you can not edit the recurring information of a recurring event after it is created.

First, to understand this task, let's compare how a description renders in a Calendar event versus, say, a Maniphest task. Create a Maniphest task with a description of something like:

```Some test description```

After saving the Maniphest task, you'll see the description render in the detail view as:

Some test description

If you repeat the same exercise with a Calendar event, this would not be true. The Calendar event detail view will show the saved description as:

```Some test description```

If you look at the PhabricatorCalendarEventEditController, the description control is added on line 440. Currently, the control is a AphrontFormTextAreaControl. It should be a PhabricatorRemarkupControl. Remarkup allows users to style their text and add meaningful text decorations. After you convert the description to the right control, the control in the edit view will now have a little menu along the top of the control that offers quick inserts of standard remarkup keys. However, if you save the description now, you will see that the description is still not rendered correctly in the detail view.
That view is built in PhabricatorCalendarEventViewController in the buildPropertyView method. You can use the same method in a similar file in the Spaces application for an example of this. After you implement that, refreshing that Calendar event you created should now render the description with remarkup. Let me know if I can clarify anything.

I think there was a bug with ID's not being passed to Javascript, but I think I resolved that in passing. Closing for the moment, as the issue isn't reproducible in the current state.

Current notion of "recent" versus "standard" dates should expire as soon as date preferences have been specified.

Currently, a recurring event can be one of three types:

@epriestley, You can't send this to v2 because it blocks T7924 through T7929. Huh, a task dependency tree tool might be cool.

Maybe a better way to think about it, at least as I understand it, is Invite/Subscribe sends it to individual people and their calendars, but just tagging will not.

Invite/Subscribe for Projects is for adding all people, like "Engineering" to an event. Tagging with a Project is different, as it's just stating this Event is defined by being a part of "Product" or whatever. Specifically, we intend to have a "Project Calendar" which will list everything happening by date for that Project (not people invited to said events).

It is already possible to invite and subscribe projects. Ain't that even better than just tagging?

Yeah, and the worst case would be if E111/4 is actually E112, an exception, and E111 gets auto-converted to E222. Then E111/4, also known as E112, will no longer be part of the E222 sequence. We could start keeping track of the relationships, but that seems like a lot of work with little pay off and possibly way more confusion.

Oh I guess that wouldn't work either if people linked to events.

Can we just do the destroy/rebuild for them automatically when they change the event?

This is by design, but, I agree, we should make this a better user experience. The idea is that generated instances of recurring events can have exceptions that hold an index in the sequence of generated events, and when a recurring event is edited from say a "weekly" event to a "daily" event, the index no longer makes sense. Right now, the expected workflow is to cancel the recurring event you wish to edit, and create a new recurring event to replace it.