Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Recurring maintenance schedule/reminders #516

Open
1 of 3 tasks
dima-ser opened this issue Jul 29, 2023 · 11 comments
Open
1 of 3 tasks

Recurring maintenance schedule/reminders #516

dima-ser opened this issue Jul 29, 2023 · 11 comments

Comments

@dima-ser
Copy link

What is the problem you are trying to solve with this feature?

We can schedule maintenance and it's great but we have to do it one at a time. I'd love to be able to set up a maintenance schedule (e.g., every 6 months) and have a report showing my upcoming maintenance for my items.

What is the solution you are proposing?

When adding a maintenance entry, provide a "recurring" option and ability to specify recurrence (every X days/months/years)

What alternatives have you considered?

External calendar, but I'd love to have everything in Homebox.

Additional context

No response

Contributions

  • I have searched through existing issues and feature requests to see if my idea has already been proposed.
  • If this feature is accepted, I would be willing to help implement and maintain this feature.
  • If this feature is accepted, I'm willing to sponsor the development of this feature.
@agrrajag
Copy link

agrrajag commented Aug 1, 2023

On a similar note for this...

We have sections on assets like Warranty, Purchase, Sell. It may be good to add a section for Maintenance which would include:

  • Maintenance vendor
  • Maintenance plan cost
  • Maintenance contract start date
  • Maintenance frequency (weekly, bi-weekly, monthly, bi-monthly, quarterly, semi-annually, annually, custom mo/days)
  • Maintenance Contact Information

A section could also be added under attachments for Maintenance-related files

From there, future development could include this data in the automatic recurring scheduling of maintenance.

@lennon101
Copy link

+1 for this feature. It was pretty much the first issue I ran into

@jjmoffitt
Copy link

In addition, it would be great if there was an ical integration or something so I can add it to my shared calendars.

The goal is that I can have my maintenance schedules in homebox, I can use either my calendar or a "upcoming maintenance" page that shows me a list of all scheduled things coming up, then track history of completed on the item page exactly like it is now. Unfortunately, notifications on the due date are useful for some things, but not super useful for something like AC/Heat maintenance where I need to call a vendor to come out.

Still loving this as is. Thanks!

@erahhal
Copy link

erahhal commented Jan 1, 2024

Also the very first issue I ran into within minutes of installation. In fact it's my core use case. Package looks great so far, thanks for the nice work.

@rasmusson
Copy link

Agree with @erahhal, this is my main usecase for something like homebox

@rasmusson
Copy link

rasmusson commented Jan 24, 2024

Hi @hay-kot I have some hope that I could do some work on this. I have worked as a developer in my past but never used go or vue, but Im guessing I'll get into it. Should we have discussions on implementation here? I have not contributed to github projects before

@th3lon3w0lf
Copy link

+1 for this feature. This tool is awesome and so far, the only missing piece to me is this.

@hay-kot
Copy link
Owner

hay-kot commented Feb 2, 2024

@rasmusson

I haven't looked much into implementing this. Here's some general thoughts I have

  1. We can't/shouldn't populate all the items in the database, especially if the interval is infinite. We'd likely need to compute evens that happen in the future either on some kind of interval or when the previous task is completed.
  2. It might make sense to store this as a complexity different entity and treat the current elements as "notes" on the maintenance. In reality we can treat these more like calendar events than a maintenance event if that makes sense.
  3. I'm not sure what the UI should look like, If anyone in this thread has examples of this that they like, please provide some screenshots.

@erahhal
Copy link

erahhal commented Feb 3, 2024

Yeah, you wouldn't want to enumerate the dates and store them, as it makes editing difficult. You could follow how other calendars do it, by using the iCal standard. There appear to be a couple libraries in golang that assist with this:

https://github.com/arran4/golang-ical

https://github.com/teambition/rrule-go

And here's a good stackoverflow post that describes how to solve this problem in general:

https://stackoverflow.com/questions/85699/whats-the-best-way-to-model-recurring-events-in-a-calendar-application

@erahhal
Copy link

erahhal commented Feb 3, 2024

Regarding the UI, it doesn't need to be that complicated. I can imagine it like this:

  • On the page for an item, have a maintenance schedule button/link. When clicked, it shows a modal with a scheduling widget similar to what you'd see on Google Calendar, with a single date time, and the ability to select recurring/repeating instances. There are several open source scheduling widgets out there
  • Offer the ability to add multiple of these schedules/events for a single item. Sometimes there are different types of maintenance that need to be done on different schedules, or the schedule is too complicated to squeeze into one entry
  • Once saved, there would be a view listing the future dates when maintenance is required, or at least the next date.
  • Also show the last maintenance event that already passed, and whether it was actually completed or not.
  • On the front page or somewhere you can get to easily, have a list of the next N upcoming maintenance events.

@giogua
Copy link

giogua commented May 20, 2024

+1!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

9 participants