Return to Project-GC

Welcome to Project-GC Q&A. Ask questions and get answers from other Project-GC users.

If you get a good answer, click the checkbox on the left to select it as the best answer.

Upvote answers or questions that have helped you.

If you don't get clear answers, edit your question to make it clearer.

+2 votes
204 views

Needed Found Dates has a fantastic feature to assist us with calendar based projects. We can export our needed found dates to a .ics file and import them to our calendar so that we can avoid finding caches of a particular type until our phones tell us that today is the day to get one.

With the recent addon enhancements to BadgeGen I find I want to work on multiple calendar projects at once, to gain the "366" addons for a variety of badges. However calendar programs use the calendar subject line to provide the uniqueness when importing files, and regardless of what parameters are chosen in Needed Found Dates, the calendar file is always called "Missing found date". If I was to import a needed found dates for micro caches and follow that with the same for Traditional caches, and if both occurred on the same date then one will not import, or the earlier one will be overwritten. Obviously this risks a date being missed and thus a possible another year required to complete the calendar.

I recommend that the calendar subject line include a parameter reflecting the options chosen in the Needed Found Dates. This would allow multiple calendar files to be imported without conflict. There are two ways I think this could be implemented:

1. Add a code to the calendar subject line
For example "Needed found dates (AAA11BB222CCC45)"
Where A = cache types (A-Z), 1 = sizes (1-7), B = difficulties (A-I), 2 =Terrains (1-9), CCC=country (as a short code or numerical index), etc

2. Add a limited code for the more common options
Where a single option is selected, specify that option in the subject.
For example "Needed Found Dates (Micro)" or "Needed found dates (T1.5,T2.0)"
Where a more complex query was made (which is less likely) either use a very long subject (may need to be limited to 255 characters?) eg Needed found dates (Traditional Cache,Unknown Cache,T1.0,Australia,Small) or switch to the code per option 1 above.

I do not think there is a practical need to include the Loop option in the subject line.

There are some obvious difficulties. For example an easier solution will include turning off the multi-select capability in the option boxes. As these effect an "and" they do not fit well with the intention of Needed Found Dates (eg selecting T1 and T1.5 will give all dates where both are missing, so will not help to complete the calendar for either terrain rating)

in Feature requests by the Seagnoid (Expert) (43.2k points)

1 Answer

0 votes
 
Best answer

There is a branch named "calendar" in Git already. It's kinda meant to solve everything related to this. But the work got postponed a few months back. The plan is also to use an online calendar that can be subscribed to, instead of importing an ICS file. This is supported by for example Google Calendar, and most likely all other common ones.

What I did (for) myself was that I created a simple HTML page using iframes to show myself everything I work on. It doesn't add it to the calendar, but I could just load the page every single day. http://1447.se/geocaching/calendar.php

The ICS download, as it is, was created a long time ago, and was only meant for filling the calendar with *anything*, that's why it's a bit stupid.

I am currently looking at the code and analyzing what I can do that would be fast and simple. Changing the topic to "Missing found date (<hash-of-filters>)" would solve the uniqueness, though it wouldn't be very readable. The description entry in the ICS already seems to involve the filter as a string. This solution would require the user to click the calendar entries, but I assume this is better than how it currently works. 

From what I can see my suggested change only requires one line of code:

$summaryText .= ' (' . crc32(json_encode($filters)) . ')';

Does it sound like something worth testing?

by magma1447 (Admin) (224k points)
selected by the Seagnoid (Expert)
Definately worth trying!
Personally I would like to see all my requirements to be somewhere all in one place - my calendar, rather than having to look up multiple different utilities depending on the type of activity. Personally I love the ics download and would prefer to keep that (unless your separate calendar utility will also be able to do an ics download?)
The point with the new page that's a work in progress is that you will see *all* of them at once. Not as it is now, one page which you need to load with different filters.

Regarding the ICAL part that probably will change. If I recall correctly (I am having a hard time finding the documentation now), it's still an ICAL. But most modern calendars allows you to use a http(s)-link for an ical file, instead of manually importing. Then the calendar will automatically update your calendar to whatever that file says.

For example, you build an ICAL for full micro calendar. You need 5 dates. Suddenly someone changes size on a canister you already logged, and you now need 6 dates. With the current method your calendar won't be updated, if you don't import a new file. If your calendar fetches that ICAL file via a webhook on a daily/hourly basis, this problem is fixed.

Same if you add another size to your PGC-ICAL-file. It will then automatically turn up in your calendar.
By the way. The proposed change I have is made in DEV-environment, but not yet released.
The change is working well. Very nice, thank you!
Sorry Ganja, my error - I had used files that didn't overlap. Digging into it further I have found that it is the ics file parameter "PRODID" that needs to be unique.
I have made a bit more advanced patch in the development environment. You will see when it's live easily because I added a input box left of the download-button.

The new field defaults to "default". It's used for both PRODID and SUMMARY. By writing something else in that field, you should then be able to differentiate them.

Again, I haven't tested them. I tried to read up on iCalendar to refresh my memory but didn't find a good source that didn't require reading the whole RFC. I'll just assume it will work, a bit based on your digging.
...