I want workflow details page to show a descriptive name for the start task instead of the form id in History table. The name attribute of userTasks works fine, but I can't get it working on my startEvent. As seen below:
<startEvent id="start" name="Início" activiti:initiator="initiatorUserName"
activiti:formKey="workflowdocumentrequest:start">
<userTask id="userTask1" name="Revisão da Requisição de Documento Físico"
activiti:assignee="${workflowdocumentrequest_destination.properties.userName}"
activiti:formKey="workflowdocumentrequest:review">
What do I have to do?
Well, if you're developing a custom advanced workflow in Alfresco using Activiti you should check out this Jeff Pots guide.
Other than that, in order to use a customised string for your start event you should be familiar with content modeling and i18n properties files.
So for your startEvent you should have a specific workflow model declaring the workflowdocumentrequest:start type, something similar to this:
<type name="workflowdocumentrequest:start">
<parent>bpm:startTask</parent>
...
</type>
For that workflow content model you should have a specific i18n file, in messages folder called workflowdocumentrequestWorkflow.properties.
There you should have something like this:
workflowdocumentrequestWorkflow_workflowmodel.type.workflowdocumentrequestWorkflow_start.title=Início
The workflowdocumentrequestWorkflow_workflowmodel part is your namespacePrefixShortname_yourWorkflowModelName (the one you have used at the beginning of your workflow content model xml file <model name="workflowdocumentrequestWorkflow:workflowmodel xmlns="http://www.alfresco.org/model/dictionary/1.0">.
The .type. is obviously your custom type for the start event task.
The workflowdocumentrequestWorkflow_start is your type's name in your xml. Activiti engine and i18n file hase to be written with _ instead of :.
Hope it helps.
Cheers
Related
I finished simple, intermediate and advanced blueprint tutorials of the Atlassian https://developer.atlassian.com/server/confluence/tutorials-and-guides/.
Currently, I have a soy file and a js file for Blueprint wizard page; a Java file as context provider and an xml file for template.
I added the current date to the title easily. I also want to insert current date and the current user (page creator) to the page before sending user to edit. (For example; default meeting notes blueprint). However I couldn't find how to set these values in template.
In xml template, the current date should be as following format:
<time datetime="2021-02-17"/>
So, I cannot add something like "<at:var>" for datetime value. So, I cannot change it from the context provider class.
Also, I tried to set this value through Javascript and JQuery, however I just can change things about the wizard page. I failed on manipulating the actual template page.
Nearly same issue with the page creator. I should add the user as following format:
<ri:user ri:userkey="2c9680f7405147ee0140514c26120003"/>
However, I couldn't set the userkey through Java and also I couldn't get the page creator value.
Thus;
How can I add the current date to the template page?
How can I add the user mention to the template page?
How can I get the creator of the page?
Thanks already for all your interests.
Have a nice day!
The answer is coming from me, too.
In template's xml, we are adding two variables for the date and the user with enabled XHTML support:
<at:var at:name="currentDate" rawxhtml=true />
<at:var at:name="currentUser" rawxhtml=true />
In the context provider class, we will set these variables with html tags:
context.put("currentDate", "<time datetime=\" + sdf.format(new Date()) + "\"/>");
context.put("currentDate", "<ri:user ri:userkey=\" + AuthenticatedUserThreadLocal.get().getKey() + "\"/>");
where the context is the context map for blueprint and sdf is the instance of SimpleDateFormat class with a pre-defined date (not date-time) format.
Setting the scene:
I'm working on a webapp in Eclipse, with a bunch of JSPs and XSLs. And I need to hide some features depending on some users' attributes. This is the third job in the series.
For the previous 2 jobs, I was able to achieve my goals because either the required changes were on JSPs (straightforward) or on XSLs for which the objects existed.
I.e. We have the following sequence:
- searchForm.jsp (a form with some criteria you set up and submit),
- resultsList.jsp (a list of search results - clicking on any result brings the full record for the result),
- displayItem.jsp (the full record),
- record.xsl (the xsl that transforms displayItem.jsp).
Thus for the 2 previous jobs, the features I needed to hide were either on these JSPs themselves or on the xsl, in which case the (relevant) JSPs had:
<c:set target="${item}" property="xsltParameter" value="xxxx=Y"/>
where 'item' is an existing object and 'xxxx' a (usually but not necessarily global) parameter defined in the xsl.
For example:
<xsl:param name="xxxx">N</xsl:param>
Thus, if my changes were on the xsl, I would reuse the 'item' object to pass on my parameter and process it in the XSL(s).
E.g. I'd put on the jsp:
<c:set target="${item}" property="xsltParameter" value="abcd=AAA"/>
and add to the xsl:
<xsl:param name="abcd"></xsl:param>
This way I was able to pass my own parameters to the xsl.
For this last job however:
- The XSL (filters.xsl) is quite short and self-contained.
- It appears on the same page as resultsList.jsp, (therefore after searchForm.jsp) but has no connection I can see with it.
- On the JSPs, there's NO (appropriate) target object I can (re)use.
- I've already tried on a/the JSP the way I know to create variables/parameters:
<c:set var="xyz" value="${abcd}"/>
but this doesn't seem to work (when I create a corresponding xyz global parameter in filters.xsl).
My issues are:
- I'm struggling to create an object (if that's what I need to do).
- I may need to do something else, but I'm not sure what (hence my post).
Plan B
In desperation, with plan B I'm creating as a proof-of-concept, a static xml file (param-val.xml), in the same location as the XSLs, in which I put my external parameter/criterion:
<paramroot>
<paramval>abcd</paramval>
</paramroot>
What I'd like to do is using the document() function, extract this parameter and use it either within filters.xsl if possible or otherwise a go-between prefilters.xsl that filters.xsl would import. And this is where I'd need some help/tips/etc.
<xsl:param name="theXML" select="'prefilters.xml'" />
<xsl:variable name="myDoc" select="document($theXML)" />
I've been reading stuff on the web and tested a few things, but I'm stuck (rusty on some topics and learning others). How can I grab and use the 'abcd' in either filters or prefilters?
Any suggestions on how best to handle this?
Sorry for the lenghty post. Any help would be greatly appreciated.
Many thanks and regards.
I know this has been asked before, but I seem to be going around in circles
Where in the magento file structure is the HTML file that displays amongst other things Anashrias Sandals(as well as Magentos end of summer sale etc...)
Ive installed the sample application to Magento CE V1.7.0.2
I can see the definition in Magento/Admin under CMS->Pages->Home Page->2 Columns with Left Bar, but Ive wondered all through the file system. The PHTML specifies the familiar
echo $this->getChildHtml('content')
But I cant seem to find anything that 'content' could resolve to that display Anashrias graceful feet and sandals
Content.phtml simply states
getPageContent(); ?>
Arghhhhhhh
Even turning debugging on puts dashed red lines around every block EXCEPT the content page
Sadly those wonderfully manicured toes must go
...but how
I was going to just comment, but to explain thoroughly I need more space ;)
To answer your comment directly, the content you see isn't necessarily in a file somewhere, the "content" for CMS pages are within your database. By changing the content field on your CMS Page (Magento Admin -> CMS -> Pages -> select a page from the list), you can change the center content for that page. Magento has many different page "types" (Each Parent of the tags in xml (explained later) is a layout handle signifying a page type), common examples are cms, category, product, checkout, cart, customer account, etc.
So, when you see $this->getChildHtml('content');, what you see is a call to the system to pull the child block named "content" from the XML. This changes depending on what page you are on, as dictated by the XML and Magento Core Code.
Layout Files
Lets take a look at the source of where the name "content" comes from. Our current working directory is /app/design/frontend/base/default/layout/. In this folder you will see a list of .xml files, these are the files that dictate how a page is put together. The block named "content" is originally defined in page.xml at around line 91:
<block type="core/text_list" name="content" as="content" translate="label">
<label>Main Content Area</label>
</block>
Also, note that this section is "nested" in the <default></default> tags. Those tags are the layout handles I was talking about, and this shows that all pages should be loaded with this xml layout by default. So here is our "content" block, in all its glory. It's actually just a namespace. The other layout pages will each load what they need from within the content block.
Now, let's look at another relevant layout file, cms.xml, around line 45:
<cms_page translate="label">
<label>CMS Pages (All)</label>
<reference name="content">
<block type="core/template" name="page_content_heading" template="cms/content_heading.phtml"/>
<block type="page/html_wrapper" name="cms.wrapper" translate="label">
<label>CMS Content Wrapper</label>
<action method="setElementClass"><value>std</value></action>
<block type="cms/page" name="cms_page"/>
</block>
</reference>
</cms_page>
Here, the <reference name="content"> denotes that everything nested here is a child of the "content" block. We don't need to call it like <block name="content"/> because we know it was already defined in page.xml.
From there, they have the "cms.wrapper" block, which basically just sets the div that "wraps" around the rest of the cms content. Nested within the wrapper is our <block type="cms/page" name="cms_page"/>. This is the bad boy that outsources our template job to the cms/page block class, located in app/code/core/Mage/cms/page.php. From there, basically the class will grab our CMS Page detail from the database and present it for all to see.
So, to answer your question in short, there is no file that has the content of the cms pages, it is pulled from the database and generated upon page request.
Block Tag Explained
Blocks have various attributes to it, I'll go over the basics.
type="core/template": The type denotes what kind of block class it is. This refers to the folders nested in the "app/code/core/Mage/" folder (typically, with exceptions*). Here we are referring to app/code/core/Mage/Core/Block/Template.php. The class you set here will be attached to your template. This is responsible for the prolific use of $this->doSomething() in your template files. Basically the template file is calling the class object to do the work. "core/template" is a good general use class to fall back on when adding custom template files, although in certain circumstances you may need to choose something else.
name="content": Here we are giving our block a name. It would be the identifying name of the block, and it's used to reference that block everywhere. The block name is needed for such things as xml references (<reference name="blockName">) and to call blocks from within parent phtml template files (<?php echo $this->getChildHtml('blockName'); ?>). Note that all templates which call it without an argument ($this->getChildHtml('');) means to call ALL child blocks without being explicitly called.
as="content": This signifies an alias identifier. You can use the alias the same as the name above.
template="page/html/callouts.phtml": This sets the template for the block. Magento will look for app/design/frontend/your_package/your_theme/template/page/html/callouts.phtml and use it as the block's layout.
*Exceptions: Third-party extensions typically use either app/code/community or app/code/local folders. If you have to overwrite a core class, copy the directory structure to the local folder and then make your edits to the local version of the class.The classes load in this order: /local/ > /community/ > /core/. If a local version is found it will use that first, followed by community and core, and takes the first class file found with that name.
local.xml
Let me introduce you to the proper way of modifying your layout. Here, create a file called local.xml in your directory app/design/frontend/your_package/your_theme/layout/. This one file will house all your layout updates, to prevent any conflicts that may arise if you start editing the base layouts. Also, it keeps all your custom changes in one tidy file.
We'll remove some things that the demo store puts in that isn't really needed. Your layout should look like this, to start:
<?xml version="1.0"?>
<layout version="0.1.0">
<!-- Layout Handle -->
<default>
<!-- Block Reference -->
<reference name="left">
<!-- Remove by Reference Name -->
<remove name="left.permanent.callout"/>
</reference>
<reference name="right">
<remove name="right.permanent.callout"/>
</reference>
</default>
</layout>
Not a whole lot there, but what this will do is remove the callout ads on the left and right side bars. You'll need to refresh your cache upon making layout xml changes.
Read another one of my answers for some more things you can do with local.xml:
Magento Sidebar Customization
Edit 08/16/13:
I glossed over the Magento Design Guide (I had it once, good resource to start off, but by the first time I read it I already had learned everything it had to offer). The fallback structure it speaks of is in regarding the code/template/layout/skin/translation files.
The packages to use are partially set by you, in System->Configuration->Design. If it is not found, then it falls back to default. If default doesn't have what it's looking for, it grabs the base file. Magento does this inherently by design.
Unfortunately I don't see any built in mechanism for falling back database content. The cms content is made up of 4 tables, cms_block, cms_block_store, cms_page and cms_page_store. cms_block_store and cms_page_store each only contain the page/block id and the store id. both ids are primary keys. This is to relate the page/block id to which store it belongs to.
I suppose you could try to instigate a fallback for cms content by having it search for that page with store id, and if not, fall back to the same page ID from a different store. Or perhaps make a "base" store record that is only used as the fallback store id. I wouldn't be sure exactly how to implement either one though.
For your reference these are the cms_block and cms_page tables:
cms_block Table
[block_id] //Internal Id, Auto Increments and is Primary Key
[title] //Block Title as User Defined
[identifier] //Block Identifier, also User Defined
[content] //Block Content Stored Here
[creation_time] //Date-Time the Block was Created (ex. 2013-07-22 17:21:18)
[update_time] //Date-Time the Block was Last Updated
[is_active] //Show(1) or Hide(0) Block.
cms_page Table
[page_id] //Internal Id, Auto Increment, Primary Key
[title] //Page Title
[root_template] //Template Layout (one_column, two_columns_left, etc)
[meta_keywords] //Meta Keywords
[meta_description] //Meta Description
[identifier] //User Defined Page Identifier
[content_heading] //Content Heading to be Displayed
[content] //Page Content
[creation_time] //Date-Time Page Created
[update_time] //Date-Time Page Last Updated
[is_active] //Show(1) or Hide(0) Page (0 = 404 error)
[sort_order] //Legacy(?) Page Sorting Order**
[layout_update_xml] //XML Layout Changes***
[custom_theme] //Override Page w/ Different Theme
[custom_root_template] //Override Page w/ Different Layout than Set Above
[custom_layout_update_xml] //Override Page Layout w/ Different XML***
[custom_theme_from] //Set Date to Start Overriding Page w/ Custom Layout
[custom_theme_to] //Set Date to End Overriding Page w/ Custom Layout
/*
/**I don't see anywhere to set via Admin Back-End. All mine are set to (0),
/ my best guess is it was used to sort page link order in a menu. Either
/ they removed this feature somewhere along the way or I somehow removed
/ it and forgot.
/
/***Think local.xml without the need to use the layout handle. In other words:
/ You can modify specific pages with the same xml styling as used between
/ the <default></default> tags above. Don't actually put <?xml>, <layout>
/ or <default> (the update handle) tags.
*/
So that's all that is in the cms portion of the database.
Fallback
When properly configured, Magento will fall back in this order:
<!-- Front End Package/Theme Template and Layout Files -->
app/design/frontend/yourPackage/yourTheme/
app/design/frontend/yourPackage/default/
app/design/frontend/default/default/
app/design/frontend/base/default/
<!-- Admin Package/Theme Template and Layout Files -->
app/design/adminhtml/yourPackage/yourTheme/
app/design/adminhtml/yourPackage/default/
app/design/adminhtml/default/default/
<!-- Front End Package/Theme Skin (JS/CSS/Images) Files -->
skin/frontend/yourPackage/yourTheme/
skin/frontend/yourPackage/default/
skin/frontend/default/default/
skin/frontend/base/default/
<!-- Admin Package/Theme Skin (JS/CSS/Images) Files -->
skin/adminhtml/yourPackage/yourTheme/
skin/adminhtml/yourPackage/default/
skin/adminhtml/default/default/
<!-- Magento Code Pool -->
app/code/local/**
app/code/community/***
app/code/core/
/*
/**Magento will, by default, only look within local folders that currently
/ exist in the core directory, community directory*** OR if an active
/ module has codePool*** set to local.
/
/***Third-Party modules have to set which codePool they are using, which
/ specifies the default working directory for that module's code.
/ This is defined in the xml located at /app/etc/modules/*. If a module
/ has its codepool set to community, you can override the extension's
/ code by copying it to local.
/*
The "community" codePool is said to be there for legacy reasons, and that new extensions should be made to use the "local" only. I personally don't agree, it would make much more sense for every Third-Party extension to use the community codePool and retain the ability to override the original extension code from "local" without modifying the original.
Okay, I think I'm done with this question, as any more information here would be overload. If I missed anything, start a new question and link me to it ;D.
I have been struggling for over a week with trying to setup a custom ORBEON REST persistence.
I am using the Struts 2 MVC framework with the following configuration:
<action name="/crud/{appName}/{formName}/form/form.xhtml" class="com.example.CrudController" method="executeForm" />
<action name="/crud/{appName}/{formName}/data/{uuid}/data.xml" class="com.example.CrudController" method="executeData" />
<action name="/search/{appName}/{formName}" class="com.example.SearchController" />
The problem is that only the first action is being called.
From the Form Builder, when I click on a form record (say "foo"), this is called:
GET http://localhost:8080/mycontext/app/crud/myapp/library/form/form.xhtml
Notice that, myapp is the correct application name but library is not the correct form name (which should be "foo").
From Form Runner, when I try the "foo" summary or new pages, this is called:
GET http://localhost:8080/mycontext/app/crud/myapp/foo/form/form.xhtml
This time the form name is correct, however I expected a /search/... call instead. Nevertheless I tried responding with either the xform xml or a query result with no success.
The call to /crud/myapp/library/form/form.xhtml is normal: it isn't done by Form Runner to load your form, but to load your app-specific section templates library, which is stored in the reserved library form name. So most likely your implementation of the persistence API should return a 404, since it doesn't have a form myapp/library.
As to the query to /crud/myapp/foo/form/form.xhtml when you access the new page for a myapp/foo, this is just Form Runner loading the form definition for myapp/foo. The query to the search API is only done by the summary page, to list data for a specific form.
I have created a custom Plone content type in my package i.e. my.product.
I am in need of integrating a working copy support: so that a "published" document (in my case, a published content type) stays online while it is being edited. Basically, I want to take advantage of 'Working Copy Support (Iterate)' provided by plone.app.iterate to achieve what is explained here. This will provide me with ability to check-in/check-out my changes.
Is this possible in Plone 4 with custom content types using Archetypes? How would one go about it if yes?
I added the following two files inside my.product/my/product/profiles/default folder and it appears to work:
diff_tool.xml
<?xml version="1.0"?>
<object>
<difftypes>
<type portal_type="MyCustomType">
<field name="any" difftype="Compound Diff for AT types"/>
</type>
</difftypes>
</object>
repositorytool.xml
<?xml version="1.0"?>
<repositorytool>
<policymap>
<type name="MyCustomType">
<policy name="at_edit_autoversion"/>
<policy name="version_on_revert"/>
</type>
</policymap>
</repositorytool>
I have never used plone.app.iterate, but this is the generic approach how to solve the problem.
Actions are installed by plone.app.iterate GenericSetup profile. You can see actions here:
https://github.com/plone/plone.app.iterate/blob/master/plone/app/iterate/profiles/default/actions.xml
Pay note to the line *available_expr* which tells when to show the action or not. It points to helper view with the conditition.
The view is defined here
https://github.com/plone/plone.app.iterate/blob/master/plone/app/iterate/browser/configure.zcml#L7
The checks that are performed for the content item if it's archiveable
https://github.com/plone/plone.app.iterate/blob/master/plone/app/iterate/browser/control.py#L47
Most likely the failure comes from if not interfaces.IIterateAware.providedBy condition. Your custom contennt must declare this interface. However, you can confirm this putting a pdb breakpoint in checkin_allowed(self) and step it though line-by-line and see what happens with your content type.