Sharepoint Forum

Ask Question   UnAnswered
Home » Forum » Sharepoint       RSS Feeds

A few customization requests -- looking for input on possible solution

  Asked By: Rico    Date: Jun 27    Category: Sharepoint    Views: 744

I’ve been asked to prepare for another wave of SharePoint customizations that will roll out on the V2 platform sometime early next year. Most of what they want to do is pretty straight forward. However, I have a few things they’re asking for that I could use some input on how to handle.

The basic summary of the situation is that there are two distinctly different brands for the organization. Both brands run on the same server. Each server supports and Extranet environment where there are varying levels of distributed administration. There are the internal users with full access to do anything and two more levels of external users with less administrative rights. Think of them as division and team administrators.

Here are the things that I’m not sure how to accomplish right now …

1) Branding of common pages – Right now they don’t allow anyone except internal users to see the common pages like Documents and Settings. However, in the next version many of these features will start to get exposed and therefore we need to determine how to brand them. The real trick to this is that they have to be branded one way for Brand A and a different way for Brand B. Because they’re hosted off the same farm I’m unsure how we’re going to apply the correct brand to each site. Has anyone solved this problem?

2) Alerts – They want to custom brand the alerts. I know this is possible but I believe I’m going to run into the same challenges that I’m running into with common pages – there’s only one set of files to control branding per installation and I have two distinctly different brands that I have to manage. Are there any tricks here that can make the branding site aware?

3) Web Part Customization control – Because there are three levels of administrators there are things that one level of administrator can do but others may not be able to do. Others have demonstrated just how much power even the built in web parts like the Content Editor Web Part have. So much power that we may not want to allow anyone except the internal administrators the ability to use it – or we may want to limit how the web parts are used. The challenge I have is figuring out the right place to hook into SharePoint to prevent web parts from being added to the page if the user shouldn’t have the ability to add that type of web part. Does anyone have any ideas on the least disruptive way of hooking into the process of adding web parts and editing web part properties so that we can apply security to them?

Talk about some serious challenges…



4 Answers Found

Answer #1    Answered By: Deonte Stein     Answered On: Jun 27

For issue 1, what I have done is change the targets for the images and _layouts folders for the sites in IIS. I outlined in a newsgroup post a little while ago, here is a copy:

You can change the path the site  uses for images and CSS in IIS. Basically in

the properties  for the web  site in IIS, you can specify a path for the

_LAYOUTS and IMAGES folders. You can copy the original _layouts and images folders and

paste into the wwwroot folder under Inetpub or something similar and then

point the _Layouts and IMAGES folder in IIS to that instance. From there replace the

images and CSS. This will only work if you have IIS setup to handle  the sites.

So basically if you change the branding  via images and CSS, and have the sites set  up as web sites in IIS, you can create copies of the default SharePoint files  and make your customizations  to each site’s copy.

Issue 3, I just have a comment really…. are you that worried about general users  inputting in JavaScript and the like into a CEWP? That is pretty advanced stuff. The most I have encountered is users going a bit wild on font formatting in the Rich Text editor.

You can however control  the permissions on the gallery pages, would this do the trick  for you? You could restrict access  to the web part  gallery page  to the users who need access.

Answer #2    Answered By: Stephon Valentine     Answered On: Jun 27

Re: 1) Great idea. That’s perfect.

Re: 3) Well, I gave a somewhat silly example… however, since we don’t  really have control  of the administrators  – yes, I’m not completely convinced they won’t do something bad. So I need to figure out what level  of control I can get over the web  parts that they can play with. As for changing the permissions on the galleries … The problem I have is that they can use *SOME* of the web parts  just not all of them. So I can’t just break access  to the gallery. Unfortunately…

Answer #3    Answered By: Leif Cardenas     Answered On: Jun 27

Re: 3) What about "wrapping" the web  parts inside a custom  web part  that checks permissions before rendering...

Answer #4    Answered By: Jasper Hatfield     Answered On: Jun 27

That’s an interesting idea. The only challenge I see with that is that the wrapper would have to be custom  for each web  part – or there’s a lot of work to do to get the serialization to work right. Since it’s serializing the fields of the web part, the wrapper would have to derive from the web part  in question – I couldn’t create a generic wrapper and apply  it to every web part – unless I managed serialization and things  like the tool pane myself. (Doable I suppose.)

The other concern I have is that I really want to control  them adding  things to the page. So I’d have to break the import option (because the unwrapped web parts  would still have to be marked as safe. – since they’re likely used on some of the built-in pages) And further, I don’t  know how I could distinguish between a web part that the global administrator  added vs. one that the lesser administrators  added.

Definitely an interesting idea to explore more.