Migrate favorited sites to pinned sites
Description
Environment
Test Plan
A developer is likely needed to test this.
Take note of a user’s favorites sites in an instance of Sakai 22 or 21.
Upgrade Sakai to Sakai 23 (or 24).
On a 23 instance with the users favorites data in preferences, perform a login (not become user)
Take note of the same user’s pinned sites. They should identically match the sites previously marked as favorites.
Secondary testing that cab completed by QA
Ensure that Pinning and UnPinning / Recent Sites is working correctly
check when a user is added/removed from a site
check when a site is published/unpublished
Use the test plan from https://sakaiproject.atlassian.net/browse/SAK-49416 as a guide.
Attachments
- 23 Jan 2024, 06:33 PM
- 10 Jan 2024, 11:53 PM
incorporates
is depended on by
is related to
Activity
Earle Nietzel January 30, 2025 at 5:12 PM
I updated the Jira to reflect the current process
Bernardo Garcia Vila January 29, 2025 at 12:24 PM
I think the test plan for this should be updated, as it refers to a Quartz job that no longer exists.
Julian Janetschek July 16, 2024 at 3:04 PM
@Earle Nietzel Thanks a lot for the explanation! 
I believe I understand now where the problem lies. We have set the property portal.autofavorite = false in our Sakai instance (I believe since Sakai 12). Therefore, anyone who has not changed their preferences to auto-favorite in Organize Favorites will have the property autoFavoriteEnabled set to false (tablesakai_preferences). Consequently, there are no autoFavoritesSeenSites properties. It seems that setting portal.autofavorite = true only affects new users and not existing ones.
I am unsure how to handle this situation, as I would expect many complaints from lectures and staff (who typically have many sites) about losing their favorites. 
Maybe some custom code to ignore userSiteIds if seenSiteIds is empty and only consider previously faved sites could work for us. 
Thanks again for your insight! 
Earle Nietzel July 15, 2024 at 3:00 PMEdited
Hi Julian,
The general goal for managing pinned (favorites) sites are as a follows:
at initial log in check to see if any new sites were created since the user was logged off and automatically pin them
also at initial log in if the user has no (un)pinned data then consider this the first time the user has logged into Sakai 23 and migrate any favorite sites from preferences (this process will also remove older favorites data)
When sites are created/deleted while a user is logged in their pinned sites are automatically updated (uses events)
admin accounts are exempt from this feature (since they have access to every site)
data is now stored in tables PINNED_SITES and RECENT_SITES and preferences is no longer used
migration from preferences will delete the old favorites data as part of it’s migration
the portal method of waiting 30 seconds and then resyncing everything has been removed and now uses events (much more efficient)
to answer @Julian Janetschek question, “why at first login every site a user is in gets pinned.”
This would be because the current logic has never seen the site before (which is why it gets pinned), and they didn’t have any info on that site in preferences during the migration, this will no longer occur as the site has now been seen.
Additionally clearing the user’s data from PINNED_SITES and RECENT_SITES would essentially cause this as well, since your clearing all of the users data, and it will also provoke the migration from favorites in preferences.
I hope the summary helps.
If you feel we should add some additional logic to skip certain sites I think that would be fine, maybe makes sense to have a handler for excluded sites where additional logic could be given to exclude sites.
Julian Janetschek July 15, 2024 at 1:36 PM
@Sean Horner @Earle Nietzel I found that the code moved into the method syncUserSitesWithFavoriteSites in class PortalServiceImpl.
But i am still wondering, why at first login every site a user is in gets pinned.
It seems that this code part at the end of the method syncUserSitesWithFavoriteSites is responsible. My understanding is that, userSiteIds contains every siteId a user is member and the site is not an user site, special site and not soft deleted.
Then for every site, which is not already pinned (not in combinedSiteIds) is pinned. As a result every site of a user (expect: hidden, user & special, softDeleted) is pinned.
List<String> userSiteIds = siteService.getSiteIds(SiteService.SelectionType.MEMBER, null, null, null, SiteService.SortType.CREATED_ON_DESC, null);
userSiteIds.stream()
.filter(Predicate.not(combinedSiteIds::contains))
.filter(siteId -> canAccessSite(siteId, userId))
.peek(id -> log.debug("Adding pinned site [{}] for user [{}]", id, userId))
.forEach(id -> addPinnedSite(userId, id, true));
Did i miss or misunderstood something? Is there a step or property i probably did not consider?
best regards
Details
Details
Assignee
Reporter
Labels
23 Status
Components
Fix versions
Affects versions
Priority
Blocker
When upgrading to Sakai 23 from Sakai 22 (and below), a users favorites data in preferences are migrated to the new pinned strategy which uses db tables. Here is the logic for the migration.
When a new session is started i.e. a User login (not become user)
the method PortalServiceImpl#syncUserSitesWithPortalNav is called which handles the migration
favorites preferences are read and check for existing data
if data is found then it incorporates that data into trueing up the users (un)pinned sites data
after some logic tables are updated to reflect the users actual current (un)pinned data
then the favorites data is removed from preferences
The sync only occurs one time for when a new session is started as this process can be time consuming, users with a lots of sites or favorites data will take longer. Care was taken to make it performant though users with lots of data are always going to be an issue, currently it processes all sites a user can access as a result super users are excluded from this sync. If further performance improvements are needed it would be to get a count of sites a user can access and if over a certain limit either exclude (older sites) or avoid trueing up this users data all together.