Add calendar based availability to portlet configuration

Great idea.

I think this feature would be very useful. I've seen it implemented in moodle in the week-by-week configuration of courses. Each week a new box (kind of like a portlet) appeared showing the content for the current week. So the teacher could prepare the contents a few weeks ahead or even prepare the full course at the beginning.

What I found difficult is how the portlet publishing and expiration dates would relate to the publishing and expiration date of individual contents. What I mean is that even if the portlet is not visible the content might be by using other means such as the search tool unless it's publishing date is the same as that of the portlet. I think moodle solves this because it's very simple and does not have publishing or expiration dates for individual contents

Have you thought about this issue, Ray?

Folks, this would be a most significant improvement to the portal for us too.
I would be able to commit resources for developing this if no one is working on it at present.

In order to do the development in a way that can go into the trunk this would propably benefit from some intput from you before we start I belive? (Feel free to contact me by mail if you want)

Have you considered Jorge's issue of searchable content and how the "availability restriction" might be propagated from the portlet/page to that searchable content?

There is of course a fundamental discrepancy between a dynamic content type site and any index based searches.

For us general purpose content search is not important, since our site has very dynamic content and searches usually leads to less useful (old!) results.

The demand for time-based portlet availability from our side is primarily for the portlets that do not have time-based content availability. (Typical use case: We want to run a poll portlet on a page every night between 20.00 and 24.00). In my mind, if an editor uses time based publishing for a a CMS portlet/content combination in such a way as to leave the portlet empty, (or the other way around, have the article want to show but the portlet invisible), this is a problem for the editor, not for the system.

For sites that do not want this power for the editors, but rather would protect themselves from editor mistakes, this feature could easily be disabled by a property setting.

Regarding the availability of information: This should be controlled by the content, not by the presentation. An article can be present on multiple pages in multiple communities. The fact that a certain portlet is displaying the article on a certain page is only one presentation of the article. If this portlet goes invisible, the article could, and should, still be available through other paths, as long as it is approved and not expired.

Good point Jesper!

Perhaps we can handle this through a two tierd approach.

1) Add availability contraints to portlet and layouts.
1.1) "Portlet" -> "Configuration" -> "Permissions" -> "Availability"
or
"Portlet" -> "Configuration" -> "Availability"

• Availablity Starting: ####
• Availablity Ending : ####

1.2) "Configure Pages" -> "Selected Page" -> "Availability"
or
"Page Settings" -> "Selected Page" -> "Availability"

• Availablity Starting: ####
• Availablity Ending : ####

2) Then in certain "viewer" portlets we simply implement logic which makes the viewer
more aware of the availability contraints of the data they are designed to display,
and possibly render no content when they determine the content is outside the contraints.
I'd also render the portlet in "borderless" mode so that the page editor still has access
to the "Configuration" links, but general users see nothing.

Viewer type portlets: Alfresco Content, Journal Content, Journal Articles, Recent Documents,
Document Library Display, Tagged Content, Polls Display, Wiki Display, etc..

The pages would simply behave as they do when "Hidden" attribute is set.

On the issue of constrained display of content vs. constrained availability through searching...
if you consider the use case for LMSs (Learning Management Systems) it is imperative there that
content if it is deemed not available for display, that it should not be searchable either...
This cirumvents the possibility of using incremental release of information, which is very much
a requirement in this case. But I think the solution discussed above handles that, as well as
yours due to the fact that in your case you can simply use the portlet availability contraint as
opposed to the data availability contraint.

What do you think?

Agree on 1.1 and 1.2. Since we are messing around here anyway and it wouldn't add much effort maybe we should look into adding also availability repeats with interval: daily/weekly/monthly or something like that. I will work with my editors to get more detailed requirements specs.

I'm not shure about your step 2), it seems to me to be mostly in place already?
I mean shurley the Journal Content and Articles will not display an article that is not published?
(I have no Alfresco experience so I can't comment on that)

My feeling is Configuration > Permissions is cluttered enough as it is, I would prefer a new top level tab.
Which means a new Struts action /portlet_configuration/edit_available_times or similar.

Do you see the storage to be the PortletPreferences > preferences XML? Or wold is have less of a performace impact if there was a separate table? Or an extension of the PortletPreferences table with a few more columns?

Where in the page display chain should we do the actual checks for wether a portlet should be rendered or not?

Regarding the storage, it would be less performant to add a table I think (more sql calls), though extending the existing portletPreferences table would probably be the most performant with using the actual portlet preferences xml being the next most performant (since we already have the object in memory when we'll be running any of this logic. I think it would also be the least intrusive to the code but less readable... So, there are tradoffs however you look at it...

Putting myself in bchan's choose, I think I'd pick extending the existing portletPreferences table... which means altering the service. This is the most intrusive. So, my answer is "I'll ask Brian Chan to choose which he prefers".

Another case for not implementing it as new db fields or a new table (so that would be FOR using portlet preferences) is that in the vast majority of cases, portal deployments, portlet in the portal, these fields would not be used... 90% of the time they would be empty or null or false... and we'd be carrying around the baggage for nothing... where as simply using portlet preferences would be light, un-intrusive and applied where we want it, when we want it.

I just spoke to Mike Young about it and he agrees that it would likely be best placed in portletPreferences XML. (as in prefs.[get|set]Value())

Regarding where in the call stack to check if we should display or not.

I'd consider the best place to be in

html/common/themes/portlet.jsp

I'd add another <c:when > between lines 368 and 369 which handles the additional case of

e.g.

<c:when test="<%= (not in the scheduled time range) && ! portletDisplay.isShowConfigurationIcon()" >
<!-- empty -->
</c:when>

which would mean anyone without "Configure" sees nothing. no borders or content. The availability check can be done somewhere near the top of that same file... the portlet prefs are available there already...

Actually, it should come BEFORE the first <c:when> NOT after... don't know what I was thinking...

Putting the availability check in portlet.jsp still means that we are rendering something in the page and actually doing the ajax call to get the portlet content. I was thinking it would be better to do the check when rendering the main page, so there wouldn't even be the (unnecessary) extra http request?

sure, as long as the user with "Configure" still gets the view... which is easy enough to check earlier...

Attaching mockup uf UI

Adding comment from Raymond sent over private email:

Wow Jesper, I like the concept of multiple availability periods. I also like the concept of repetition, though I'm not exactly clear on how it would work based on what I see in the UI...

Would it be that the selected interval indicates the portion of the start/end dates to override?

e.g.

• start June 15 2007 01:00PM
• end June 15 2007 01:30PM

repeats hourly

• start June 15 2007 *:00PM
• end June 15 2007 *:30PM

seems fine for small time periods, but doesn't seem logical for larger ones...

Perhaps I'm not understanding the logic.

I wonder if maybe it should read, instead of:

• from start (date)
• until end (date)

rather

• from start (date)
• for X duration (interval)

That way the repetition makes more logical sense, because we'd have

• starts June 15 2007, 01:00PM
• for duration 30 minutes, 30 days, etc...

• repeats N times (select the start date mask to use for repeats interval)
• hourly = June 15 2007, *:00PM for X duration
• daily = June * 2007, 01:00PM for X duration
• monthly = * 15 2007, 01:00PM for X duration
• yearly = June 15 *, 01:00PM for X duration
• weekly = ?? (can't show using this simply mask logic)

I think that reflects more closely schedules which allow for repetition, like Cals. I wonder if we
might not even be able to leverage the CAL event format to store the data in the portlet prefs. We could
then leverage the logic we already have for working with CAL data, and possibly reuse some UI elements,
thereby maintaining consistency and increasing user familiarity with the UI.

e.g. This is the current (4.3) event edit view... it's pretty much just what we need... plus a few things we
don't.

Jesper, I think you are right calendar is the way to go with this one. Only challenge might be exporting those settings to a LAR. You should also take the new staging functionality into consideration so that it doesn't break meaning availability settings so a staged portlet in staged layout does not affect live one.

The great thing about using the existing Calendar is that we already have some utils to export and handle the Cal data as ICS fragments, meaning that import/export should be really simple.. and really a very cool side effect we barely have to do anything with the take advantage of.

I have enclosed an initial cut of the Portlet Scheduling feature as developed by Johan Wallén of the Kanal5 team.
The feature works as advertised, but a few things remain.
We have not enabled all views from the Calendar stuff, not shure what makes sense here.
Right now the monthly overview is implemented.

Also some GUI stuff from calendar is still to be removed.

The main issue we have not adressed is how to make the standard Calendar portlet not show the events used by the scheduling.

I had some troble creating the patch due to Tortoise adding files in new directories twice. I hope I got it right in the end.

Services and DB needs to be rebuilt to run.

Please provide feedback and input!

I'm eager to try it out. I'll try to test and comment as soon as possible, which might be later next week, but I encourage anyone else who has time sooner to try it and comment.

Thanks Jesper and Johan!

Does anybody migrate this feature also to 5.0.x?

Thanks Thomas

Hello everyone! We are in the process of removing component "Portlet" from LPS. Please make the necessary adjustments to affected filters. Thanks!