I would like to create subsites dynamically when a certain workflow is completed. The name of the site would be specified as part of the workflow. Is this possible?
Note: I do not have the ability to do any coding -- just stuff I can do through sharepoint designer and the regular sharepoint website interfaces.
If you're looking to design the workflow in SPD, you ironically will need a custom workflow activity to create the site. Fortunately, there are third party custom activity packs that you can purchase and install on your farm that provide these, e.g:
http://www.virtosoftware.com/wikis/sharepoint-workflow-designer/sharepoint-site-amp-group-management-activities.aspx
Related
I am using JIRA from a pretty long time and its good, but now I want to store all the project document in a single place like sharepoint (with version if possible).
Do I need to create a ticket and then attach to it?
OR
Is there any separate place for it in JIRA?
I believe you should try using Confluence, which is itself part of the Atlassian stack of software development/productivity tools. Confluence is a feature-rich document/knowledge sharing application which is somewhat comparable to SharePoint and offers great integration with Jira and its other sibling products).
I am in the process of developing several data entry forms that the client has asked to be accessible through the SharePoint interface (2007 WSS version).
The forms will, among other requirements, consist of multiple drop downs that have to be loaded from tables in SQL Server. These lists of data are updated frequently through a process that sucks data in from Great Plains.
My inclination is to create a Web Part Page with a Page Viewer Web Part and go full screen like this: http://blogs.msdn.com/b/malag/archive/2008/09/15/story-of-a-mischievous-page-viewer-web-part.aspx
...and then to do the pages in ASP.NET MVC3. Is there a better story than this? The integrated SP development paradigm seems like waaaay more overhead.
This sounds like a common issue with developers new the SharePoint paradigm, especially for 2007. The short answer is that your solution will be the quickest way to get to where you want to go but isn't the "cleanest".
The other option is to create a SharePoint Solution and publish an application page to the _layouts directory. A quintessential "hello world" example can be found at http://msdn.microsoft.com/en-us/library/bb418732(office.12).aspx.
New SP developers will find the hardest transition with deployment. The WSPBuilder codeplex project http://wspbuilder.codeplex.com/ has become the industries default solution for doing this. An example of using this can be found at http://www.greggalipeau.com/category/sharepoint/wspbuilder/.
For you I would say the key words are Application Pages and WSPBuilder.
We have a client who is not willing to give us access to their SharePoint environment.
The work involves creating a bunch of custom site columns, custom site content types, page layouts and pages from the custom page layouts. We are going to create this in our environment and the plan is to "move" the pages to our client's environment.
The page layouts will also contain few content editor web parts.
I tried downloading the page to the disk and giving it to the client, but the downloaded page does not contain data entered in the content editor web part.
I thought of creating all the custom stuff (columns, content types, page layouts, and pages) in a sub-site and exporting the sub-site and have the client import the sub-site in their environment. At present I am having an issue but is this the correct way of achieving my goal?
Is there a better way to do this?
Thanks
I've used the export and import commands (stsadm.exe) for subsite content and it has proved to work in most scenarios. Just be aware that there are limitations which may or may not apply to your situation, which are described here:
http://blogs.technet.com/b/stefan_gossner/archive/2009/05/27/limitations-of-stsadm-o-export-import-related-to-publishing-sites.aspx.
Is using a third party tool one of your options? If it is, I would recommend a tool on Codeplex called the Sharepoint Content Deployment Wizard. I have used it to migrate content from one server to another. One downside to this tool is that it does not use webservice calls so it must be run locally from the Sharepoint server. I have used it with WSS 3.0, MOSS 2007 and MOSS 2010.
You can find the details here: http://spdeploymentwizard.codeplex.com/
HTH
I'm very new to Sharepoint and I am just wondering if it's possible to somehow use data from an external database as a List that users can select from within a form. How much extra development does this involve?
Essentially we have a different (non sharepoint) site that allows us to set up projects. Once a project is set up I would like the project code to be usable from within workflows, forms, etc.
If you have MOSS Enterprise, you may want to take a look at the Business Data Catalog (BDC). It allows you to bring external data to SharePoint. Supported inputs are either a database or a webservice.
http://msdn.microsoft.com/en-us/library/ms563661(office.12).aspx
After you have set up the BDC, you can use the business data field to use that external data as metadata. That way, you can make decisions in workflows based on that metadata. If you want to play with the BDC, get yourself a decent tool to generate the application definition files (xml), because creating them manually is cumbersome.
Consuming external data in forms is even easier. It doesn't require the BDC as you can use databases and webservices directly as a secondary datasource in InfoPath.
Another option (if you don't have MOSS Enterprise) is to create a timerjob that keeps a list up-to-date based on the projects found. Of course, this is not updated in realtime and requires some programming.
I was wondering in sharepoint what the difference between a forms library in sharepoint vs the central admin page under manage form templates. I am trying to upload .xsn files so that no one can access them, but I don't know if I should upload them to the central admin page or if a forms library will suffice. Any help would be greatly appreciated.
The big differences with deploying through Central Admin are:
admin deployment only (though you've already figured this one out)
form versioning is available
may be made available to all site collections at the discretion of the admin
when you deploy a form, it deploys as a content type
are intended for forms that contain code (other than the inline stuff) - a form in a form library cannot contain code
You can also deploy an InfoPath form to a content type, so that it can be available to a site collection.
To use forms deployed through Central Admin, you'd create a new form library, then allow management of content types for the form library and configure the library for this content type.