This post is intentional left at a very high level, as a potential solution description.
One interesting scenario we have encountered in a CRM involves the potential large number of shared views a user has to handle.
NOTE: This deals only with views shared by a user, to another user. Sharing to teams should not be handled by this design.
A user can potentially end-up with a large number of views shared with him/her. He or She could start tracking down who the view owners are, and ask them to un-share the view they are not interested in. Two problems here, one is the fact that you are at the mercy of another user, the other being you might leave those users with the feeling that “you don’t really care about the effort they put into it”.
The solution, as simplistic as it sounds, is to give the user the ability to un-subscribe from that shared view. But there is nothing OOTB to allow that kind of functionality. So, how do we build that?
It’s actually not that complicated, but it involves a little bit of coding. One of the developers I work with has successfully built a functional POC. Let’s have a look at the high level design.
There are a few elements to this. First off, in order to unsubscribe from a shared view, the most logical place to start from is the list of all views. You get to it by navigating to Saved Views on the Advanced Find ribbon.
Getting there, you will see listed all the available views for your user permissions. Change the view to Active Views Shared With Me.
It would make sense to start the un-subscribe process from here, right? Ok.
First off, we’ll add a ribbon button at this location. Name it Unsubscribe or anything that makes sense to the users of the system. You can use a ribbon editor app like the ribbon workbench, or you can just go and edit the XML yourself, depending on how much time you have on your hands. Make sure that the button triggers a JS web resource function called in this case very imaginatively JsUnsubscribe. We’ll come back to that in a moment.
We will need a container entity created also. This is a “container” only, because it is only used during processing, and the clean-up removes the data afterwards. You could keep the data if you want to report on it. Let’s name this entity CntUnsubscribe.
Now, coming back to the JsUnsubscribe script, it is triggered when the user selects a view or more, and clicks on the ribbon button. The content on this script takes the selected views, and creates a new record in the CntUnsubscribe entity for each selected view. This record, if used for reporting also, should contain at the very least the view ID, the user ID for the user triggering the unsubscribe, and you can make it as complex as you need, depending on your reporting needs.
So, to this point, we have:
1. a ribbon button to unsubscribe from selected view(s)
2. a temporary container entity
3. a script triggered by the button, that adds a record for each selected view in the temporary container
Next comes the fun part. We create a plugin that triggers on record creation in the temporary container. Based on the view ID, we retrieve the view owner. We will impersonate this user to trigger the un-share action four our user. Once we are done, we could clean-up after ourselves by removing the record in the temporary container, or we could flip a flag to know it’s processed. We can easily add audit details, like the date-time stamp when the unsubscribe was requested, and whatever else we want if we decide to keep this information going forward.
Make sure in your plugin code you validate that the view is shared to a user, not a team.
Overall, the solution looks like so:
Build it, test it, package it, use it.
Enjoy!
thatcrm.com 
Leave a Reply