This commit allows quoting of discourse-local-date elements
and converts the quoted tags back into bbcode so that the
rendered quote will also render the discourse-local-date HTML.
This works on single dates as well as date ranges, and supports
all of the options used by discourse-local-date.
This also necessitated adding addTextDecorateCallback to the
to-markdown core lib (similar to addBlockDecorateCallback and
addTagDecorateCallback) to transform the text nodes between
date ranges to remove the -> in the final quote.
c.f. https://meta.discourse.org/t/quotes-that-contain-date-time/101999
This fix attempts to fix an issue where the preview was not updated after changing timezone. Changing time would work as it would recreate the date DOM element and as a result, reset the popper.
Note this commit also introduce a new {{d-popover}} component, example usage:
```hbs
{{#d-popover |state|}}
{{d-button label="foo.things" class="d-popover-trigger"}}
<div class="d-popover-content">
Some content
<div>
{{/d-popover}}
```
It's very easy to forget to add `require 'rails_helper'` at the top of every core/plugin spec file, and omissions can cause some very confusing/sporadic errors.
By setting this flag in `.rspec`, we can remove the need for `require 'rails_helper'` entirely.
This allows text editors to use correct syntax coloring for the heredoc sections.
Heredoc tag names we use:
languages: SQL, JS, RUBY, LUA, HTML, CSS, SCSS, SH, HBS, XML, YAML/YML, MF, ICS
other: MD, TEXT/TXT, RAW, EMAIL
This also switches to using the NPM package for better build stability. And adds a clearer label in the alert that is displayed to show your current timezone (when changing timezones).
New range tag for local dates with syntax like:
```
[date-range from=2022-01-06T13:00 to=2022-01-08 timezone=Australia/Sydney]
```
Previously, 2 dates in one line were considered as range. It was hard to decide if 2 dates are range when they were in separate lines or have some content between them.
New explicit tag should clearly distinguish between single date and range.
Common code from `addLocalDate` is extracted to `addSingleLocalDate`.
Both `addLocalDate` and new `addLocalRange` are using `addSingleLocalDate`.
Also, `defaultDateConfig` was extracted to have one place for all possible parameters.
* FIX: do not display add to calendar for past dates
There is no value in saving past dates into calendar
* FIX: remove postId and move ICS to frontend
PostId is not necessary and will make the solution more generic for dates which doesn't belong to a specific post.
Also, ICS file can be generated in JavaScript to avoid calling backend.
- Stop looking up the topic title from the DOM. On long topics, the topic title may not be present. Instead, we can store the topic title in a data-title attribute during decorateCookedElement, and then access it later. This approach would also allow us to add customize titles per-local-date in future. If there is no topic title available (e.g. when local dates are used elsewhere in the UI), we use the site name to build a sensible default
- Don't require a postId for creating calendar events. We don't have postIds in non-post contexts. At the moment, the 'download ICS' function will fail without a valid postId, so that will need to be fixed in a future commit.
When there is a blank space in the end of date, moment is returning a different value:
```javascript
console.log(moment.tz("2021-09-09 ", "Australia/Sydney").toISOString());
// 2021-09-09T00:00:00.000Z
console.log(moment.tz("2021-09-09", "Australia/Sydney").toISOString());
// 2021-09-08T14:00:00.000Z
```
Jarek Radosz
Peter Wagenet
David Taylor
Martin Brennan
Discourse Translator Bot
Joffrey JAFFEUX
Penar Musaraj
Krzysztof Kotlarek
Natalie Tay
Martin Brennan
Kris