Keep track of last activate/deactivate date for plugins #16683
Conversation
… if custom date used. And add extra params to proxy method.
| $startDate = $earliestDateToRearchive; | ||
| } else if (!empty($earliestDateToRearchive)) { | ||
| // don't allow archiving further back than the rearchive_reports_in_past_last_n_months date allows | ||
| $startDate = $startDate->isEarlier($earliestDateToRearchive) ? $earliestDateToRearchive : $startDate; |
There was a problem hiding this comment.
Does that mean there won't be any possibility to rearchive specific reports for dates older than rearchive_reports_in_past_last_n_months? Wondering if there might be any use cases where it might make sense to force that somehow. But guess would be enough to implement it if we have such a use case at some point
There was a problem hiding this comment.
I guess a user could always configure it differently above setting.
There was a problem hiding this comment.
For this a plugin could manually invalidate, since rearchiveRepors is really just a smart wrapper for markArchivesAsInvalidated.
core/Plugin/Manager.php
Outdated
| * @return Date|null | ||
| * @throws \Exception | ||
| */ | ||
| public function getPluginLastActivationTime($pluginName) |
There was a problem hiding this comment.
not any important but could move this methods to the Plugin class so things would maybe feel a bit more natural like $plugin->getLastActivationTime(). Not sure that works though in our context maybe we need to have this information when the plugin is not loaded yet or unloaded already or so. Feel free to ignore
| $startDate = $earliestDateToRearchive; | ||
| } else if (!empty($earliestDateToRearchive)) { | ||
| // don't allow archiving further back than the rearchive_reports_in_past_last_n_months date allows | ||
| $startDate = $startDate->isEarlier($earliestDateToRearchive) ? $earliestDateToRearchive : $startDate; |
There was a problem hiding this comment.
I guess a user could always configure it differently above setting.
|
@tsteur applied changes |
core/Plugin.php
Outdated
| * @return Date|null | ||
| * @throws \Exception | ||
| */ | ||
| public function getPluginLastActivationTime($pluginName) |
There was a problem hiding this comment.
@diosmosis could rename it to getLastActivationTime() and remove the $pluginName and instead use $this->pluginName?
|
👍 looks good to me. Left one comment though and didn't really test it. @sgiehl maybe you could give it a test? |
| { | ||
| $optionName = self::LAST_PLUGIN_DEACTIVATION_TIME_OPTION_PREFIX . $pluginName; | ||
| Option::set($optionName, time()); | ||
| } |
There was a problem hiding this comment.
Should we clean up those entries whenever a plugin gets completely uninstalled?
There was a problem hiding this comment.
I think it might still be useful to know when the plugin was last there... might be more useful to know when it was installed/uninstalled. What do you think @tsteur?
There was a problem hiding this comment.
No preference here. Might be useful though to keep them and I can't think of some downside when keeping these entries.
Description:
Refs #16396
Stores the last time of activation/deactivation of plugins for use in other plugins. Also includes a change capping the amount of dates that are rearchived if a custom date is supplied.
Review