search

mantisbt-plugins / Calendar

Adds the task scheduling function in MantisBT based on the calendar of events with the possibility of one-way synchronization with Google Calendar.
15 stars 7 forks source link

Events remaining after issue is closed #38

Open fgarciapatino opened 5 years ago

fgarciapatino commented 5 years ago

Events linked to issues, remain in calendar when the issue is closed, The spected behaviour should be delete related events once the issue is closed. If not, developers have to update calendar manually for already configured events, and it looses all its utility for untenable manteinance reasons.

brlumen commented 5 years ago

There are several reasons why an event does not have status:

  1. You can associate several issues with an event;
  2. The event also serves for the history of work with the issue;
  3. In my calendar usage scenario, there is no need to perform actions on events when the status of an issue changes.

I summarize the above, I want to draw your attention to the fact that I developed this plugin for my needs and proceeded from my work scenario. I have thoughts about the status of the event, but I did not plan to implement it in the near future.

Please describe your scenario of using the calendar, and I will think about how I can help you.

In any case, this is an open project and any contribution to its development is welcome. You can modify it and send your PR to merge with the main branch.

fgarciapatino commented 5 years ago

Thank you for your answer.

I feel very grateful for all your effort developing this plugin.

I will try to extend your plugin by myself. As I read, mantisbt publish the necessary events to be informed about issue state change, but I am not sure, if it should be possible to hook such events in your initialization file, and then perform the specific actions over the plugin event database records (delete further events from the issue state change date) .

I suppose my case is not an strange one: issues, developers, and events, are interrelated, and events without issues (deleted issues), or unuseful events assotiated to issues (solved or closed issues before a event date), are a nonsense or a bothering noise, that invalidate a large proportion of the plugin utility.

Most interesting than my scenario, should be know more about yours. I can not figure out the case where "the history of events that will never happen" (solved, closed, or deleted issue,s before the date defined for an assotiated event), has value in terms of information or management. I do not have any doubt about the requirements you had, match perfectly with your plugin implementation, but knowing this, could save time to some people, or at least, let them to take better decissions.