I want to make an workflow that has other statuses than the Single Approver workflow, other than "Update", "Approved" etc. Is it possible?
What I have found on Internet is how to create custom portlets and I am not sure I have to go so far. I understand that these statuses are constants from the WorkflowConstants.java file and that it is possible to extend that file in order to add my own constants. But where should I place that file? What other changes do I have to make to make it work?
Thank you.
Liferay has offered different approaches to extend and customize liferay portal depending on the nature and complexity of changes required.
Following are the possible ways:
1. via Extension (ext) environment
2. via Plugins
i. Portlet
ii. Hook
Using extension environment, you can simply move that file from portal source to the relevant package of ext and introduce changes.
Lets say, WorkflowConstants.java resides at location
\portal-service\src\com\liferay\portal\kernel\workflow\WorkflowConstants.java in portal, so you can copy that file to \ext-service\src\com\liferay\portal\kernel\workflow\WorkflowConstants.java.
Make required changes in ext-service file and deploy ext. One restarting container changes will reflect.
Related
I have created portlets for liferay and prepare couple of pages. Now I want to create installation script, which create pages definition in customer liferay server. I know that pages export/import is possible using LAR file, but this could be done only manualy, or using remote publishing which i am not able to do.
I was searching on net and found ddm tool. Which should be able to do that. Unfortunately i'm not able to get it work as it export only web content, blogs, wikis, etc, but not pages with portlets. It is probably because one of the condition is "Every Template must be assigned to a Structure. Don't create any templates on the Liferay server which does not have a structure connected to it.
". But how can I assign page to structure ? Cant find anything.
Or is there any other option for automatic page creation, which could be used ?
In case you created a custom theme, you can easily use the "resources importer" to create an entire site via the "sitemap.json" file (define pages: choose layout, assign portlets to the columns, ...). You can also export existing content as xml from the current instance and import them via the theme. Same thing for web content structures and templates.
for more details: https://dev.liferay.com/develop/tutorials/-/knowledge_base/6-1/importing-resources-with-your-themes
Unfortunately theme is produced by another supplier, so this solution isn't suitable for me.
at the end i find working solution which consist of following steps:
create plugin hook
in hook setup upgrade process
in the upgrade process create pages with appropriate layout, friendlyUrl, etc. All these is possible to do using liferay api
Don't have enough reputation, so at least two links
https://www.liferay.com/de/web/james.falkner/blog/-/blogs/7cogs-is-dead-long-live-7cogs-
https://github.com/azzazzel/liferay-official-plugins/tree/master/hooks/sevencogs-hook/docroot/WEB-INF/src/com/liferay/sevencogs/hook/upgrade
Is it possible to add custom feed programmatically to Web Platform Installer? I tried adding the feed manually and found that the feed location is stored in `%APPDATA%\Microsoft\Web Platform Installer\web.preferences file. However the file seems somewhat cryptic and I would not like to modify it manually. Is there any API for that?
Update: even if this web.preferences file could be edited it is not the way to go as it is user specific file and I need system wide configuration.
Based on this link,
Sorry, there isn't a way to do that currently (for security reasons,
we don't allow an untrusted feed to be loaded without the user's
consent)
Once the feed is added via the Options dialog, it does persist between
sessions
I think we can't add custom feed without intervene from user. Maybe you can use WebpiCmd.exe
that can be configured programmatically via scripts.
C:\Program Files\Microsoft\Web Platform Installer>WebpiCmd.exe /List /Feeds:http://yourcustomwpifeed.co.id/customFeed.xml
A little late, but maybe it may interest others. You can modify the file %APPDATA%\Microsoft\Web Platform Installer\webpi.preferences. Yes, it is a little cryptic, but here's my post about how to do it.
The file webpi.preferences is user-specific. If you want to set settings for all users, all I can think of is to write a bootstrapper application that first modifies webpi.preferences (using the code in the post) and then runs WebPlatformInstaller.exe.
I have a sharepoint solution package with a Custom UserControl inside. When I deploy the .wsp the user control is placed in the CONTROLTEMPLATES directory. Is there any way to "delay" this step until feature is activated?
In other words what I would like my custom user control to be available only after the feature is activated.
As far as I know this is not possible. On deploy all the needed files are copied to the correct location. It is actually feature independant, because you don't even need a feature to deploy files. You will see that a feature is automatically created when you for ex. add a webpart to your solution. Not when you add a mapped folder.
What are you trying to achieve with delaying the usercontrol? What you can do is check in your usercontrol if a certain feature is active and adapt the rendering of your usercontrol accordingly. Ex. Show message that the feature should be activated before using the control.
My customer wants to provide 2 themes for a SharePoint application. Is there a strategy to accomplish this in MOSS 2007?
We want to apply user profile-based theme selection, and maybe even a drop-down to switch modes.
I don't know how extensive you want your re-theming to be. However if it could be CSS-only you could use this approach:
Store the CSS files for the different themes in the Style Library.
Create a list that stores the user and their chosen theme.
Write a feature and custom application page to allow the user to change their theme.
Write a control that does a lookup on the list against the current user and obtains the a reference to the corresponding CSS file in the Style Library. The control would then output the CssRegistration and CssLink controls to the page for this file.
Add this control to the master page so it executes on every page (caching should be added).
I can't see why this wouldn't be supportable by Microsoft as you're only changing CSS.
If you need to do more than that then another option is to write an HTTP module that changes the HTML output. Or of course JavaScript. With these two options you may have supportability issues (it depends on how extensive your changes are).
There is also SPThemes now available on Codeplex from Bjørn Furuknap. Users can choose their own themes and they can be applied at different scopes.
Here are the options that I’ve come up with from research and feedback. Both of which seem mostly infeasible.
Implement major UI layout changes in JavaScript. This would lead to client slowdowns, would be difficult to code, and would be completely unsupported by Microsoft due to the need to reference SharePoint objects that may change with subsequent SharePoint patches.
Provide two parallel themed sites based on the same data, and provide a way to switch between them. This would require that we deploy each site to multiple locations, and would require retooling of any site creation mechanisms in code (since they'd need to target two sites instead of one).
One another thing you can try is to use the Theme Changer and ThemeChangerStaple from codeplex , That is implemented as feature you can use the same code logic to archive what you want with bit of modification, give it as an option for the user using CustomAction.
My team is working on a project to migrate a .com site into SharePoint.
After all our look and feel assets, master pages, content types, and page layouts are created, we need to actually "move" the actual site pages into SharePoint.
I'm trying to come up with the most effective way to do this. Our topology consists of an Authoring and a Production environment. We plan to use SharePoint Content Deployment to populate Production from Authoring.
However, we obviously need to do some sort of initial population of the Authoring environment. I don't want to use Content Deployment to populate Authoring from a development environment because I don't want to initially create Authoring from a Blank Site definition.
Here are the options I came up with, would love some feedback on which you think would be the best approach:
Create the site content in a development environment and use a tool such as SPDeploy to migrate it into the Authoring environment
Create the content directly in the Authoring environment
Use a technique similar to how you can provision List Item instances in a feature. We would create and populate all of our content using Features
I'm not sure if this is actually doable, but got the idea because of how I know you can create List Item instances when provisioning a List in a feature. After all, our Pages library is a list of Pages - however there are multiple content types involved.
Thank you for your suggestions!
If it is just a matter of migrating files, you could actually use the content migration framework. The core classes of this framework are the SPExport and SPImport classes in the Microsoft.SharePoint.Deployment namespace. You can with fairly little code export individual files to disk and import them again to a new location. Alternatively, try the SharePoint Content Deployment Wizard on CodePlex here: http://www.codeplex.com/SPDeploymentWizard. It will save you the coding.
Backup and restore the content DB.
Can you clarify on why you don't want to use content deployment to create your initial Authoring site? Why do you not want to start with a blank site definition? It would get overwritten in the deployment process anyway. What about stsadm -export / -import?
I'm sorry, but I'm still not clear on the whole situation. You have a development environment (presumably where structure is created, but not any content destined for production), an authoring environment (which I understand as a locked down environment where content is entered and approved), and then a read-only production environment to which approved items are deployed. If this is the case, then I can say that I have a similar setup on one of my projects.
In my case, I initially developed the site structure in my dev environment, then backed up and restored to authoring and prod. Subsequent structural changes to both environments are made by hand. Authoring is structurally almost exactly the same as prod. Only the security is different. Several times per day content is deployed from authoring to prod. We make content changes directly in the authoring environment.