Hello,

I'm trying to do something that might be impossible, or not done …

I'd like the Calendar Home screen to display the (most recent) events of the person currently logged in. I could perhaps build a script trigger (on layout enter) that would set a filter, but I'd have to "zap" that filter whenever diving into the calendar.

Would this be advisable, is it just impossible, or are there other ways ?!

Thanks for your light,

Bien amicalement,
Jan

I'm not sure what you mean by "zapping the filter" or "diving into the calendar", but showing each user a list of events filtered by their login (account name) should be pretty simple. You could either set up one of the built-in filters to look at the account name, and decide if you want users to be able to turn that on and off or not. Or you could put a portal somewhere with a portal filter setup to show only that user's events. If you want it to show only recent events, include "=> some_date" in that portal filter too. HTH... Jeff

Thank you for your rapid reaction, Jeff, and excuse me for my "informal" language … If I would like the "home" screen to display a list of recent (>some date) events, but I don't want that filter to remain active when switching to the calendar (diving into). I would therefore have to probably include a "reset" of the filter in the script performing the layout switch. Do you agree ?! That could perhaps be accomplished by two script triggers; one that activates on layout entry, one that activates on layout exit.
Now, the portal is a different story, that I have a hard time to understand. The "Home" screen displays the single CalendarInterface record. How could I link that to the "events" table and obtain a user-specific result ?!
Thanks for your time,
Jan

Hi Jan. Your script-trigger solution sounds fine if that's the behavior you're looking for. To show a portal to filtered events, just make a new table occurrence for the SampleEvents table ("SampleEvents2"?), linked to CalendarInterface as something like "CalendarInterface::username_global = SampleEvents2::username" (where "username_global" is a new global text field in the CalendarInterface table, and "username" is whatever field in the SampleEvents table stores the username of the user assigned to the event). Then if you want to break that relationship with a script trigger, just clear that global field. HTH... Jeff

Thanks Jeff,
I think I'll go for the solution based on script-triggers, because I think parallel multi-user access will mess up the solution based on having a username_global field in the calendarInterface table. I actually tried something like that, and saw (what I expected) that the filtering produced by this approach affects all Users logged at that moment. Unless I did not completely understand your suggestion …
Anyway, thanks a lot !
Jan

Hello Jeff,
Working on this brought up the following, easy solution, based on a new Events table occurrence, related to the CalendarInterface table by a (X) Cartesian relationship. A filtered (UserName) portal on the "Home" layout does the rest ! Would you see any problems with this "pragmatic" solution ?!
Thank you for keeping my mind on this …
Jan

Sounds good. I think that should work!