I was testing out my calendar system and noticed an issue. Users can add dates to their calendar, and before they click ‘update’ schedule, the dates are saved as ‘Status = Draft’. When user closes the popup (rather than clicks the update button), the dates with ‘Status = Draft’ are deleted.
The issue is when the user opens the popup again and adds more dates, it doesn’t delete them a second time around, but I can’t work out why.
This is what the popup looks like with dates added. They currently have a Status of Draft.
Closing the popup first time works great - the dates are deleted (as they are set as ‘draft’).
When I re-open the popup for the same listing and add dates again, I can then close and re-open the popup and some or all of the dates will still be there (even though I can see that they are deleted from the DB).
I wish there was a better solution to creating a ‘frequency’ calendar system. This has been the trickiest part of my build so far!
Instead of saving ‘draft’ dates as status = draft (into the database), I wonder if there’s any way to save them locally by setting a state (not sure if ‘set state’ can work like that)?
@louisadekoyaI THINK I’ve diagnosed this issue, I just can’t figure out how to fix it.
Seems like the issue only occurs when I close a popup before all dates have been added to the repeating group/saved to the DB.
For example, if I’m adding dates from 9th Jan until 23rd Jan, this can take 8 seconds or so to fully add them to my repeating group/DB. If I close the popup after 5 seconds and re-open the popup, the dates will still be there (although they will have been deleted from the DB).
If I do that again, but I wait for all the dates to be added to my repeating group and then I close the popup, all dates are successfully deleted for when I next open the popup.
Not sure what this means in terms of a fix though!
Why delete them ? Just leave them there and start again.
So when you click “Add Dates” generate some sort of unique-id for your schedule and save on the Schedule Group, and then when they “Save” update the status from Draft.
Tie your Repeating Group into the id.
That way if they come back in, you will generate a whole new set.
Storage is cheap, and you can clear up every so often. And it gives you an idea how many people are leaving before they “Save”.
Although I would suggest a more elegant way is not to store each event, but to store the template (period, start, end) and exceptions.
Thanks for working on this Nigel, much appreciated. Have been super busy so have only just had a chance to take a proper look.
Looks like it’s working except for one thing – in the add/remove dates popup, I need to show all dates with the status = Live for that class listing.
For example,
If the user has classes between 1st and 20th Jan scheduled, they should appear every time I open the popup for that particular listing, which is where I think the ID solution is problematic?
They need to appear because the user can add OR remove existing class dates. If they can’t make a particular class, they will want to remove it from their list of dates, so displaying existing dates (past current date/time) is important.
Currently, the popup is ‘fresh’ every time because it’s a new ID, whereas in reality it should show all existing ‘Live’ dates, but when I close the popup, any ‘draft’ dates (not saved as Status = Live’ should disappear).
Not sure if we can tweak the ID solution in order to accommodate this?