"In Fluid, tiles and homepages represent the primary navigation model, replacing Classic's breadcrumb menu."In Classic, breadcrumb navigation is managed by administrators. It is fixed, not variable, not personalizable. Users cannot personalize Classic navigation (other than creating favorites). Did I say Fluid is different? Yes. Fluid gives users significant control over their navigational view by allowing them to personalize tiles and homepages. This can cause significant problems, with users removing tiles that represent critical business functions. There are a few solutions for this problem (disable personalization, mark tiles as required, etc, see Section 4 of Simon's blog post for ideas). What I want to focus on is confusion regarding optional default tiles, where an optional default tile doesn't default onto a homepage. Here is the scenario:
- A homepage already exists
- As an administrator, you configure a new tile as Optional Default
If it is optional default, what happened to the default part? When users personalize their homepages, PeopleSoft clones the current state of the homepage into a user table. Let's say Tom and Jill both personalize their home pages. Tom will now have a personalized copy of the default configuration and Jill will have an entirely different personalized copy.
Administrators will continue to insert optional default content into homepages, but Tom and Jill will not see those optional default tiles. Tom and Jill's homepages are now detached from the source. We can push optional default tiles into Tom's and Jill's copies by using the Tile Publish button available to each homepage content reference (in the portal registry). This App Engine program inserts a row for each optional default tile into each user's copy of the homepage metadata.
Pretty clear and straight forward so far? OK, let's make it more complicated. Let's say an administrator adds a new optional default tile to the default homepage described above and presses the Publish Tile button. After the App Engine runs, the administrator notices Tom sees the tile, but Jill does not. What went wrong? If Jill doesn't have security access to the tile's target, Jill won't see the new tile. Let's say Jill is supposed to have security access so we update permissions and roles. We check Jill's homepage again. Does Jill see the tile? No. Why not? When we published the tile, Jill did not have security access so PeopleSoft didn't insert a row into Jill's personalization metadata. How can we make this tile appear for Jill? We could publish again. If we recognize and resolve the security issue immediately after publishing, this may be reasonable.
Let's play out this scenario a little differently. Some time has passed since we published. Tom has seen and removed the new tile from his homepage. One day Tom is at the water cooler talking about this annoying new tile that just appeared one day so he removed it. Jill overhears Tom and logs in to look for this annoying tile. After some searching, however, she doesn't see it on her homepage. She calls the help desk to find out why she doesn't have access to the annoying tile (that she will probably remove after seeing it). This is when you discover the security issue and make the tile available to Jill. For Jill to see this tile as a default, however, you will need to republish the tile. When you republish the tile, what will happen to Tom's homepage? Yes, you guessed it. Tom will see the tile appear again and will likely call the help desk to complain about the annoying tile that just reappeared.
What's the solution? At this time there is no delivered, recommended solution. The App Engine is very short, containing a couple of SQL statements. Using it as a guide, it is trivial to write a one-off metadata insert for Jill and all others affected by the security change without affecting Tom. When writing SQL inserts into PeopleTools tables, however, we must consider cache, version increments, and many other risk factors (I probably would not do this). I would say it is safer to annoy Tom.
Jim' is the Principal PeopleTools instructor at JSMPROS. Take your PeopleTools skills to the next level by scheduling PeopleTools training with us today!
Jim - Thanks for a fantastic blog on this topic. Wow... you could not have explained it better.
This confusion by the way has been the bane of my existence. :)
I don't mind annoying Tom by bringing back the tile he hates every time the Tile Publish runs. I guess we can put that down to collateral damage when it is working as designed.
But I think it would be great if the user's personalized version of homepages get automatically synced (Tile Publish), every time a homepage, tile security, etc. is modified.
Very helpful article Jim, thank you. Good point about version numbers and cache, I see a lot of places overlook that when SQL-ing. I agree with Sasank, annoying Tom is okay.
A step further might be some sort of audit flag for users’ personalizations that would allow the app engine to distinguish between Jill who’s never had the tile and Tom who had it but removed it. Then a simple run control option on the tile publish app engine could allow a choice for whether to override Tom’s tile removal or not.
Nice....we ran into this same issue during 8.56 upgrade. If the tile is so important, make it required for all so that personalization does not impact it, then everyone will always see the same annoying tiles!
We can also send Alerts to users to go add that new tile that is now available if the Publish will annoy those who already deleted it.
Post a Comment