I was just given administrator access to my company's SharePoint 2010 site, and I need to implement an Approval workflow. This is an out-of-the-box workflow, and it is not currently available to me. The only help I have been able to find after exhaustive web searches is to navigate to Site Settings -> Site Collection Administration -> Site Collection Features and activate the Workflows feature, which should be the last feature in the list.
The problem is, there is no Workflows feature in my top-level site's Site Collection Feature. There is only a "Three-state workflow" feature for workflows, and the Three-state workflow is the only one available. What would keep the "Workflows" feature from being displayed in the Site Collection Features list? I need to activate this feature to get access to the OOTB workflows and their functionality.
TIA!
Are you using SharePoint Foundation ?
The only workflow feature available for fondation is the Three State workflow. The Workflows Feature (out of the box) is only in Standard and Enterprise
Related
Now I'm in the stage where I need to pick a test automation tool to use it on a project built on modern SharePoint.
And of course this will include testing out of the box webparts and SharePoint provided webparts.
So my question is ,does cypress.io can handle testing webparts as after a lot of researches I found articles said that it can't until now.
And I'm still struggling with making cypress to login to my SharePoint tenant.
Any info about these will be really helpful
I would like to know difference between Office 365 REST API and Microsoft Graph, since we could find similar functionality for both of these.
https://msdn.microsoft.com/en-us/office/office365/howto/rest-api-overview
Following is the text from above link:
Office 365 API functionality is also available through Microsoft
Graph, a unified API that includes APIs from other Microsoft services
such as Outlook, OneDrive, OneNote, Planner, and Office Graph,
accessible through a single endpoint and with a single access token.
If there is no such difference, do you plan to deprecate any of these?
Thanks
Microsoft API is one endpoint solution to access the Office 365 services like mails, calendars and .etc. By using the graph api, no more obtaining separate tokens for different services or calling a different endpoint for each API.
Some features may be available on the individual service endpoints,
but not yet on Microsoft Graph. We are working hard to bridge these
gaps. If you require one of these features, you can use the individual
endpoint in the meantime. Check the release notes for details on the
Microsoft Graph features in preview and generally available.
For details, you could refer the document Choosing your API endpoint.
The Documentation state that Office 365 API functionality is also available through the Microsoft Graph, a unified API that includes APIs from other Microsoft services such as Outlook, OneDrive, OneNote, Planner, and Office Graph, accessible through a single endpoint and with a single access token. We recommend using the Microsoft Graph in your apps when possible.
Also see this answer it says
Our recommendation is for you to use Microsoft Graph as long as it has the features/APIs you need in production to support your production apps, or at least in Preview to support app development. This makes it easy for you, in the future, to expand your app functionality requiring access to multiple Microsoft services, without changing endpoints. You can use individual service endpoints such as Outlook REST API if you need a feature that is only available in the individual service endpoint, either in production (v2.0) or as preview (beta).
I would like to develop a custom application (multiple screens, complex processes) on top of Sharepoint Foundation 2010. I decided to write visual web parts for simple logic and Silverlight web parts for complex application logic. First of all: Is this decision ok?
My application will use it's own data in a separate DB. The only connection between my DB and Sharepoint will be users. Users will authenticate against Sharepoint and access my application from there. They will belong to certain roles which will define their rights within my application (either admins - hierarhicaly managing data of subtree users - or they will be regular users - only able to see their own data).
Within my application (and DB) all these users will be hierarchically related. Users with subtree of users are admins of their subtree.
Problem?
If I do write web parts (of whatever kind), how do I ensure that these same web parts are not used in other Sharepoint sites as well? It would most probably break the application and it could of course make it possible to replicate the same application but using different users...
I thought I could as well write application pages (so my application would be in _layouts folder as I understand it), which would make it possible to not reuse my application, but users and rights are assigned on site level so I'm not able to define security in Sharepoint directly... So I can't win this way either...
These are all specualtions on my thin Sharepoint development experience, so correct me of I'm wrong in any of the above... But beside all that what would you suggest? How would suggest I should do this?
To get straight to the point WebPart are for reuse and personalization when you develop a web part.
To Answer your first question : Is WebPart development okay, Partially yes because, you have multiple option to prevent a web Part being accessed or used in other SharePoint Web Application or website.
First way is to deploy your webpart to the Applications Bin Directory so that your code is accessible only to your application not others.
Second way is that WebPart can be used in a SharePoint web application only if there is a Safe Control entry in the Web.Config.
Third Way is to prevent the users from Personalizing any page in SharePoint so that they cannot deploy any Web Parts even in their own Personalized Pages. (this can be achieved by removing personalization rights).
Farm Admin should be a Good guy that he will not add that safe control entry in other websites that doesn't want this webpart functionality.
Application Pages are not good idea because by the name you could guess they are shared across the farm & is accessible to all the SharePoint websites deployed in the server.
In cases if you are not okay with the above to Web Part approach , I would suggest to create sub sites as per the permission requirement you want and provision pages that will go in to each of the sub sites. Each of these pages will have a ASP.NET User control that hold the Business Logic you have written.
Custom Web sites built on SharePoint are cropping up everywhere (just visit topsharepoint.com to see). With that said, my question pertains to creating a fully customized, branded site using SharePoint as the CMS as depicted by many of the topsharepoint.com sites.
I understand the concept of creating the custom master master page(s) (SharePoint 2010 even includes a minimal.master to start). The problems I have are:
What site template does one use? In 2007 the recommended front-facing Web site site collection template was the Publishing Portal. Is this still the case?
What navigation do you use? Do you leverage the OOB navigation? If so, how do you style it extensively?
How do you keep the on-page editing capabilities within the new site template?
Are there any online tutorials are walk-throughs that address all of these issues? I have been searching, but it's really sparse out there.
How do I create a new webpage in the Documentum front end Webtop?
The short answer is that it can not be done.
WebTop is Documentum's generic application for browsing their back-end content repository. Think of it as a web-based Windows Explorer on steroids. It's a tool for storing, versioning, and sharing electronic documents (Word, Excel, etc.) - it's not a tool for creating web pages.
Documentum's Web Content Management product is called Web Publisher. It is the tool that companies use to allow non-technical business users to create and edit web pages.
Why WebTop? You should use Web Publisher which is built on WebTop with the specific purpose of managing web content. Is this an OOTB installation? Web Publisher / WebTop requires significant amount of customization in order to start being useful. Do you have templates defined? If so, then just go to File New and select your template.
http://www.dmdeveloper.com/ Is a good site with some very good how-to's.