Ephemeris support in UIs

[ghys]

Here I just want to float some ideas about Ephemeris and how UIs can make it more approachable to users.

First I would propose that we rename the service from Ephemeris (a technical naming referring to a library) to something more generic like "Calendar" or similar? - this is the only occurrence of a technical term being used in this list below, note that the service itself could still be named after Ephemeris but I'm only talking about the display name appearing in the Settings here:

Next, the Schedule screen in the UI tries to display rules with time-based triggers and conditions in a calendar by analyzing them client-side, this works when the triggers are well-known and easy to figure out (cron, time of day, day of week, etc.) but when Ephemeris gets involved it becomes impossible. So what about introducing an API to get all time occurrences of rules (matching a certain filter like having a "Schedule" tag) in a configurable future period?

[wborn]

I also suggested to change the name to something more people would understand during my review. 😉

[rkoshak]

It will cause just a little bit of confusion but I agree, Calendar or something like that makes a better name. But that raises a question, whats the difference between Schedule and Calendar? I know the difference but I worry having the two on the same page next to each other might cause some confusion for the new user in a hurry. Unfortunately I don't know that I have a better word to use. Maybe "Holidays and Weekdays" or something like that?

I don't know if this is possible, but I always thought it odd that I had to set the regional settings in two places, once for OH and again for Ephemeris. Is there a way to get the country at least from Regional Settings to get the list of holidays?

[ghys]

It's true that all settings currently defined for the Ephemeris manager service could in fact be considered to be regional (geographical and cultural) settings, and it could IMHO make sense to move them all there, even if they're only used for Ephemeris. That would solve the problem of having to name the Ephemeris settings section because it would be gone.

[kaikreuzer]

If it is possible to combine multiple services under the "Regional Settings" category, I would agree that this could be a good solution.

So what about introducing an API to get all time occurrences of rules (matching a certain filter like having a "Schedule" tag) in a configurable future period?

I'm not sure I fully understand this idea. Could you briefly elaborate, please?

[ghys]

Yes, I believe it could work like this:

• the parameters to the API request define the rules to consider and time span of the occurrences to return (for instance, 30 days, only rules tagged with "Schedule");
• the trigger modules of the matching rules would yield the dates & times when the rule is supposedly scheduled to run according to them within the specified upcoming period, for instance a "time of day" trigger spawns an occurrence every day for the configured period; for cron rules, the frontend code currently uses later (https://bunkat.github.io/later/) to get occurrences from expressions, I'm sure there's an equivalent in Java to implement the logic server-side;
• Next, the expected occurrences according to the triggers would be fed to the condition modules for them to figure out whether they would match or not (i.e. weekdays only, specific day(s) of the week, etc.)

This wouldn't be completely accurate i.e. this method wouldn't be able to understand an if block in a script module, but if done properly it would at least allow the Ephemeris modules to have to opportunity to yield occurrences & perform some filtering on them, that would be more generic and wouldn't depend on frontend support.

[DeanCording]

If you are considering changing the name of Ephemeris, can I also suggest changing the references to BankHoliday to something more generic and internationally recognised. Bank Holiday is a predominately UK term. In most other countries, they are Public Holidays.

[J-N-K]

@ghys, does this require core support and if so, what exactly do you need?

[ghys]

Next, the Schedule screen in the UI tries to display rules with time-based triggers and conditions in a calendar by analyzing them client-side, this works when the triggers are well-known and easy to figure out (cron, time of day, day of week, etc.) but when Ephemeris gets involved it becomes impossible. So what about introducing an API to get all time occurrences of rules (matching a certain filter like having a "Schedule" tag) in a configurable future period?

This part has been implemented => #2125
The label changes (and moving around/consolidation of parameters) are only suggestions and can be handled purely in core.

[J-N-K]

Since nobody comes up with a better name, I would keep it for the time being.

Merging "Regional Settings" and "Ephemeris" is difficult and might be even more confusing. In "Regional settings" you can select a location (in coordinates), but there is no way to determine The correct setting for country/city/region from that (and vice versa, setting a city does not allow determining the location). IMO this is difficult to explain, that you have to set both to get the best experience.

Another related issue is that we can't configure additional day-sets via UI. The problem here is that our config-description can't deal with multiple multi-value parameters. Currently it looks like

{
  ...
  "dayset-weekend": [
    "SATURDAY",
    "SUNDAY"
  ],
  ...
}

The config description for the day-set is

<parameter name="dayset-weekend" type="text" required="true" multiple="true">
    <label>Weekend Days</label>
    <description>List of usual non workable days.</description>
    <default>SATURDAY,SUNDAY</default>
</parameter>

What we need is something like

{
  ...
  "dayset-weekend": [
    "SATURDAY",
    "SUNDAY"
  ],
  "dayset-office": [
    "MONDAY",
    "TUESDAY"
  ],
  "dayset-workathome": [
    "WEDNESDAY",
    "THURSDAY",
    "FRIDAY"
  ],
  ...
}

where the names of the days can be chosen by the user. We currently have no way of defining something like that in the config description. Maybe something like

<parameter name="dayset-*" type="text" required="true" multiple="true">
    <label>Days</label>
    <description>List of days in this day-set.</description>
    <default>SATURDAY,SUNDAY</default>
</parameter>

would be a good idea, where a * in the name is interpreted as "parameter can occur more than once, with a unique id that replaces the *". WDYT?

[splatch]

Another related issue is that we can't configure additional day-sets via UI. The problem here is that our config-description can't deal with multiple multi-value parameters.

Maybe dayset instances could be modeled as separate services which are created by user? As far I remember config descriptor can optionally specify factory attribute which in theory should allow to manage configurations provisioned to ManagedServiceFactory (producing ie. DaysetService tracked by EphemerisManager). I never got that concept working properly, especially that UI seem to lack option for pushing a new configuration into runtime.

[clinique]

@J-N-K : a first step could be to suppress country parameter from Ephemeris cfg config. I've thought of this many times and do not see the point of keeping it separate from OH country config. This could somehow be a breaking change for some users. Maybe targetting v5.0 ?