I'm currently working on a MOSS 2007 site and i need to set up a "system" which will e-mail all the changes in all the lists and libraries in the site.
I'm new to the Sharepoint world, i wonder if it is possible.
P.S. I have no access to the Central Administration panel. (If it has anything to do with my purpose)
Thanks
You can write custom timer job to do this task.
You could do it in this way:
Create custom timer job feature, set timerjob schedule.
On FeatureActivated event add that timerjob to SharePoint and have a [Persisted] property like SiteUrl in timerjob, which you could pass in constructor to let timerjob determine with which site to work with.
Use SPWeb.SiteUsers to get all users in SharePoint.
Loop each user, open new SPSite impersonated as each user.
On SPSite.RootWeb (SPWeb) execute GetSiteData (read community comments for some great examples and explanation on how to use it). Use Query that queries items where Modified field has value greater than (follow link for important info to query correctly) what you want.
Generate html out of your data and SPUtility.SendMail.
There is a scheduled reminder job feature available. However it works only on 1 List scope. But you can download source code, open RmdJobDefinition class and just see how it works to assist you writing your own class.
Good luck.
I'm afraid you can only setup the alert on a list (or item) basis. In the list you go to Actions => Alerts => When to send alerts => Weekly. I didn't check the Central Admin since you don't have access in your scenario.
Related
I want to create a web part in which I want to display history of all workflows that failed in the past certain time. The info that I want to get is the workflow name, its location (site URL), initiator and error date time. I am very new to SharePoint with ASP.Net background so I am having a hard time figuring out if there is some way in the API to that?
Kindly share if this is possible?
Its a hidden list so you can't get to it from All Site Content. You have to type the URL in directly, like below. And once you have the URL of the list you can query the individual fields
http://[servername]/[sitename]/lists/Workflow%20History
I have a workflow that is triggered by the creation of a list item and sends out an email when the list item is created.
If I create a new item in that list through the Sharepoint front end it sends the email.
I have a small console application designed to set the list item through the Sharepoint API. This is run as a scheduled task on a daily basis ( the purpose of the list is to nominate someone for a daily rota ) in the middle of the night. The scheduled task is run with the credentials of the Site Collection Administrator for the site.
The list item is added but the workflow is not triggered. In the log I get the following message:
Declarative workflows cannot automatically start if the triggering action was performed by System Account. Canceling workflow auto-start.
It appears as though the list item is being added by the system account rather than the user who is running the code. What do I need to do in order to have my code interact with Sharepoint using the same identity that is running the application?
Consider explicitly impersonating one of your SharePoint users (in this case the site collection administrator.) I answered a similar question over here: UpdateListItem method and System Account
Once you've created a SPSite object using the context of the impersonated user all operations against that object and its children will be performed as that user.
It might be better to set your second workflow to being manually started, and then start it programmatically (which your System Account -can- do):
There's probably a better way to do this, but this has been working for me:
// Look through all potential workflows for the correct one:
foreach (Microsoft.SharePoint.Workflow.SPWorkflowAssociation flowAssoc in SPContext.Current.Web.Lists["YourListName"].WorkflowAssociations) {
if (flowAssoc.Enabled && flowAssoc.AllowManual && (flowAssoc.Name.Trim() == workflowNameToLookFor.Trim())) {
// Start the workflow on the current item:
SPContext.Current.Site.WorkflowManager.StartWorkflow(SPContext.Current.Web.Lists["YourListName"].Items[itemIndex], flowAssoc, flowAssoc.AssociationData, true);
}
}
I have a list with lists of all the certificates being used in my project.
I want to setup a notification (email) if certification expires (or say a week before expiration).
I would like to know solutions with and without code deployment (feature).
There are quite a few different options (workflow/custom dev/3rd party and open source products) coverd in this post
SO - Dated reminders in SharePoint
calendars
One option is to create a SharePoint Designer Workflow (meets your requirements), check this one, scroll down until you find the part it deals with the "Pause Until Date" activity.
Look through the Information Management Policy Settings in your List Settings and see if you can use the content expiration to achieve this. You can trigger a workflow to run (e.g. one that sends a notification email) on an item based on a date field in your list.
So, for example, you can have it fire off an email on Created Date + 10 days to notify whomever of its pending expiration
DUPE: See link below
I have a SharePoint Designer workflow and I need to send an email to the user who initiated the workflow. It is set for manual start only so it should always be running in the context fo a particular user.
I cannot see a SharePoint Designer action to let me do this, only to get the user who created the list item or by accessing the 'Modified By' column on the list. Neother of these is guaranteed to be the user who is calling the workflow.
Found the same question posted before. It appears to not be possible but the code for a custom workflow activity can be found here.
I have an Events list in sharepoint and need to disallow users from having the ability to create meeting workspaces in the new event form. Shy of customizing the new event form (which breaks attachment support), how can this be done?
By default, in order for users to create a meeting workspace, they will need to be an administrator or Site Owner (specifically they will need the Create Sites permission). If you don't give them this permission, they won't be able to create a meeting workspace.
This will disallow the user to create any site under the site where these permissions are set. I'm not aware of a way to restrict access to a specific site definition but still allow users to create a different one.
I don't think there is a supported way of doing this. One option is to edit the WEBTEMP.XML file in C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\1033\XML\WEBTEMP.XML (make a backup first of course). Comment out the lines as follows:
<!-- <Template Name="MPS" ID="2">
...
</Template> -->
After editing this file and executing IISRESET on every server in the farm, you shouldn't be able to create a meeting workspace any longer.
If you can get some javascript into the masterpage, I came up with this little hack.
It does have a couple downsides in that MS could potentially releaase a hotfix or service pack that either:
changes the name of the "Use a Meeting Workspace to organize attendees, agendas, documents, minutes, and other details for this event" checkbox such that the string "CrossProjectLinkField" is no longer in the name, or...
they could use that same string in the name of some other input element on some other OOTB markup
In the ladder case (which I'm not entirely certain is false right now), these inputs would get disabled if they were sporting a masterpage that ran this script.
But this is a risk I can deal with. You run these risks anytime you depend upon client ids and names being emitted by someone else's control.
<script type="text/javascript">
var anchors = document.getElementsByTagName('input');
for(var i=0;i<anchors.length;i++)
{
var anchorName = anchors[i].name.match('CrossProjectLinkField');
if(anchorName != null)
{
anchors[i].disabled = true;
break;
}
}
</script>
What this does is find the checkbox that allows users to create meeting workspaces and disables it so that they cannot check it. Problem solved!
Create a web scoped feature with a feature receiver that deletes the current web the feature is activated on and have it throw an SPException stating that the template cannot be used. Then create a web application or farm scoped feature stapler that staples the previous feature to the site definitions you want to prevent. Activate that feature on the web application or farm. Then when someone creates a site from one of the site definitions the site will be deleted and the user will be presented with an error page displaying the text of the SPException thrown.