Feature 9290 #855
Merged
Feature 9290 #855
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
silveruser
reviewed
Jan 10, 2018
| */ | ||
| @FunctionalInterface | ||
| public interface Process<V> { | ||
| V execute() throws Exception; |
There was a problem hiding this comment.
silveruser
reviewed
Jan 10, 2018
| @Column(name = "triggered") | ||
| private boolean triggered; | ||
| @Column(name = "trigger_datetime", nullable = false) | ||
| private OffsetDateTime triggerDateTime; |
There was a problem hiding this comment.
mmoqui
force-pushed
the
feature-9290
branch
3 times, most recently
from
efa7235 to
2af6522
Compare
|
SonarQube analysis reported 2 issues
Watch the comments in this conversation to review them. |
…, it is built from the perspective of unit tests in order to help to design it. So, it will be subject of changes in the futur according to the expectations on the reminder behaviours in some peculiar contexts.
Add a specific scheduler trigger for one shot job execution.
- DurationReminder for a reminder about only plannable contribution and to trigger a give duration before the start date of a plannable contribution, - DatTimeReminder for a reminder about any contributions and to trigger at a given datetime Add a builder to easily build such reminders directly from the Reminder class.
…omponents (aka applications) that manage them. Some core contributions are defined like publications, comments or events; contributions that can be extended to a more specific use. Others are just specific to a Silverpeas components. Nevertheless all of them can be handled either in Silverpeas Core or in some other Silverpeas components without knowing the concrete type of such a contribution. In order to be handled in a more generic way, each contribution can returns a model object that gives an abstract view, a conceptual view, of itself. For doing a new interface is added to represent this conceptual view: ContributionModel. A default implementation, DefaultContributionModel, is also defined so that it is returned by default by the Contribution interface itself. This default implementation accesses the represented contribution by reflection. Any concrete type that which customize this default implementation can override the method Contribution#getModel() to return its specific implementation of a model. Beside this new interface, a set of filters is added to apply filtering on some properties to execute operations associated with the matched predicates. The Filter interface is used by the ContributionModel in order to perform some specific operations according to the type of a contribution business property. These new interfaces are now used by DurationReminder to get the reference date time from which the triggering date time of the reminder will be computed. This reference date comes from a business property of the contribution related by the duration reminder and the name of this property is set when the triggering rule is set to the duration reminder.
…o take into account the case the value on which the filtering is done is null and in the case the matcher result value is also null.
- refactoring TimeData which is called Duration now - creating the silverpeas-contribution-reminder WEB component . autonomous creation on EVENT . autonomous modification on EVENT . autonomous deletion on EVENT . creation on EVENT creation . modification on EVENT modification . handling functional errors - implementing the REST WEB Service of Reminder - adding ContributionLocalizationBundle in order to handle from centralized services specifics UI labels - implementing the ContributionModel of CalendarEvent which is especially providing the next start date of an event from the current platform date time. - adding the concept of Instance
scheduler a persistent scheduler. The volatile scheduler is the previous and default scheduler: all the jobs and triggers and stored in memory; such a scheduler is relatively fast and flexible but requires the job to be scheduled again at each Silverpeas restart. In the other side, the persistent scheduler is aimed to the jobs and triggers that require to be kept scheduled over several runtimes. For doing, they are stored by the scheduler into a database, hence its name. Because the scheduler manages the persistence of the jobs and of the triggers, it is more heavy than its volatile counterpart and then it cannot be as fast and flexible. So, only jobs with a triggering rules expressed at least in hours can be envisaged to be taken in charge by such a scheduler. Morever, to ensure the execution flow of the jobs and listeners are always up to date and to be independent of their implementation, only their class names are serialized into the persistence context so that they can be spawn in their last actual state at the firing of the triggers. Nevertheless, for a better flexibility, a job and a listener can be retrieved from the IoC container; if they aren't found, then an instance is constructed by reflection. With the change of the API, the code that uses it is also updated consequently.
…g to them. Starts to code the JPA-based persistence of the reminders. Now the reminders are persisted when they are scheduled in the timeline.
…r is triggered. A reminder has now a new property to know if it was triggered. The identifier of a reminder is now an instance of the new entity identifier class ReminderIdentifier
- adding a notion of priority to the Initialization interface - setting the trigger time according to the user preferences about zone id - adding the management of deleted users - adding the management of user preferences change - implementing the notification builder - fixing problems around time zone
… user is notified, it checks the reminder is reschedulable and if so it reschedules it. Only DurationReminder instances can be automatically rescheduled: they are automatically reschedulable after their triggering if the contribution property from which the triggering datetime has been computed returns a non-null datetime after the next computed triggering datetime. The ContributionModel and its default implementation has been simplified and improved: only the interface of the contribution is taken into account (and no more the attributes, that are implementation detail). Some bugs in the DurationReminder has been fixed.
…iven contribution or both
- adding the possibility to get potential durations about a contribution - added Aurore's work - displaying reminders only if there is action possible with them - wiring the user notification send - wiring with real persistence - fixing a problem around Initialization mechanism
- fixing some errors
This datetime is computed from the triggering rules of the reminder when it is scheduled. The property is serialized with reminder in the persistence context.
- improving UI behaviors about reminders and calendar events - fixing BackgroundProcessTaskTest.java random failure - taking into account a right dates to process user notification messages
…ion as they use the Scheduling Engine; this is to be ensure the Scheduling Engine is correctly initialized before.
- one with persistent scheduler: when a job is just scheduled at a date in the past, nothing is happening instead of firing directly the job like it is with volatile schedulers. Now the firing of a job for such a trigger is done programmatically directly in the QuartzScheduler abstract class. - one with reminders of recurrent events: when a reminder is fired at the expected datetime, the reminder isn't scheduled automatically for the next event occurrence. This happens because the date since which the next event occurrence is asked is taken at the start date of the occurrence for which the reminder was set and then the implementation returns that same occurrence causing the failure of the rescheduling test. Now the implementation of the CalendarEventOccurrenceGenerator#generateNextOccurrenceOf(...) method is modified and slightly improved. In the modification, the date since which is searched the next occurrence is exclusive. Furthermore, the Recur#getNextDate(...) is no more used as it is buggy.
…ock issues with H2
…ity about how the request are processed. Now, the requests that will be processed are always predictable.
mmoqui
force-pushed
the
feature-9290
branch
8 times, most recently
from
baa1c9f to
16e0e8d
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Implement a new engine to set reminders about a peculiar property of a contribution in Silverpeas. For example a reminder on the visibility ending of a given publication or a reminder on the starting of a given calendar event. Two types of reminders are provided: one to set explicitly a reminder at a given date time, another one to set a reminder at a duration before the date time returned by a specified property of a given contribution. For later reminder type, while the reminder is firing, it can be rescheduled for the same contribution if and only if the date time returned by the contribution property at the firing date time is in the future. The Reminder Engine uses the persistent scheduler in the Scheduler Engine to persist all the jobs and the triggers. Therefore, the Scheduler Engine is updated by implementing such a scheduler using the JDBC storage of the Quartz API.
The Reminder Engine provides also a widget and a REST-based web service to set in a generic and transversal way the reminders for a given contribution.
In order to work with whatever contributions in Silverpeas, the Contribution API is enriched with a new interface, ContributionModel, that represents in a more generic way a contribution in Silverpeas. This is a model of a contribution through which the business properties of a contribution can be accessed/invoked without having any knowledge about the type of the contribution. A default implementation of this interface is provided by the Contribution interface (this implementation uses the Java reflection API to access the underlying contribution properties).
This new engine is used to set reminders on events in the Calendar Engine. The Calendar Engine uses the duration reminder and extends the default implementation of ContributionModel to implement a new business property getNextStartDate(ZonedDateTime) for the CalendarEvent objects and dedicated to reminders. It uses also the reminder definition widget to set explicitly a reminder for an event.
Don't forget to merge after the following PRs in that order: