I followed this tutorial to create a custom alfresco activiti workflow: http://ecmarchitect.com/alfresco-developer-series-tutorials/workflow/tutorial/tutorial.html
I tried to externalize the contained strings by creating .properties files and made them known in the xyz-context.xml. While this is working I face a problem with changing the title of a worfklow task.
I use the following sampleWorkflow.properties file:
sampleWf.task.confirmTask.title=Confirm this, with a title which is different than the task name
sampleWf.task.confirmTask.description=Confirm please
The bpmn-snippet for this tasks, is configured like this:
<userTask id="confirmTask" name="Confirm" activiti:assignee="${bpm_assignee.properties.userName}" activiti:formKey="samplewf:customTypeTask"></userTask>
My question is
Why only the description of the workflow tasks change, but not the title?
The above localization works, when I don't use the task ID but it's property like this:
sampleWf.task.samplewf_customTypeTask.title=This changes the title
If this the only possibility I'd need to deploy a lot of custom types just for naming purposes. Can't I reuse types across workflows and just change the title (name) by this configuration?
Please refer to this link in order to have a better idea on how strings could be localized in a workflow in Alfresco :
<workflow_prefix>_<workflow_name>.workflow.[title|description]
<workflow_prefix>_<workflow_name>.node.<node_name>.[title|description]
<workflow_prefix>_<workflow_name>.node.<node_name>.transition.<transition_name>.[title|description]
<workflow_prefix>_<workflow_name>.task.<task_prefix>_<task_name>.[title|description]
where:
<workflow_prefix> is the workflow model namespace prefix
<workflow_name> is the workflow name
<node_name> is the name of a node within the workflow
<transition_name> is the name of a node transition within the workflow
<task_prefix> is the task namespace prefix
<task_name> is the task name
<transition_name> is the workflow transition name
Which suggests you should be putting something like :
sampleWf_<workflow-name>.task.sampleWf_confirmTask.title=Confirm this, with a title which is different than the task name
Which -in theory- should give you the possibility of using the same task model in multiple workflows with different localization, but I guess you still have to duplicate your model in order to be able to have multiple localizations in the same workflow!
Update :
Oops! I got tricked by this statement:
This page was last modified on 13 March 2015, at 02:22.
That was a bot marking the page as obsolete!
The page is obviously outdated and it is talking about jbpm, not activiti, hopefully you still can use the same naming conventions!
Otherwise, worst case scenario, you got to create new task models that basically just extend your original task model to be able to customize the task title as needed (No need to redefine properties/constraints ...).
Related
I want to copy the list of users specified as Component Watchers (with the plugin of the same name) into the list of Watchers, at issue creation time. I'm trying to do this with a Script-Runner post-function, after creating a custom field of type Component Watchers.
The part that I'm missing is how to obtain the Component Watchers usernames as a list. Any idea?
Try the Behaviours plugin. There you can specify "behaviour"-s, that can be mapped to projects and issue types, and there you can specify Groovy Scripts to run during transitions.
It won't be easy, but it is versatile and does not eat too much resources.
My Grails (2.4.2) app was created with a bunch of "default/standard" resource bundles:
myapp/
grails-app/
i18n/
messages.properties
messages_fr.properties
I would now like to create my own "custom" resource bundle, that is, define properties in a file outside of these standard messages*.properties files that myapp was created with.
According to the i18n documentation, all bundles need to be prefixed with messages and suffixed .properties. So I added two new props files, one for English and one for French:
myapp/
grails-app/
i18n/
messages.properties
messages_fr.properties
messages_myapp.properties
messages_myapp_fr.properties
For one, I'm not 100% sure I'm interpreting the docs correctly. So if anything about my 2 new props files jumps out at you as being incorrect, please start by letting me know!
Having said that, in all the example from those docs, I don't see where you specify the bundle to use. All of the examples look like this:
<g:message code="fizz.buzz.foo" />
But what if I have a fizz.buzz.foo property defined in both messages_blah.properties and messages_bar.properties?
So I ask: How do I add my own custom resource bundles, and how do I properly refer to them from inside a GSP?
To answer your question you have to understand what Grails (well, Spring really) is doing to accomplish this.
You are on the right path with the multiple files. What you have outlined there matches the documentation and will work.
However, under the covers what is really being done is they are being combined into a single bundle (per language). So there is no need to tell Grails/Spring which bundle to use.
Finally, what happens when the same key is defined multiple times? The first one matched wins. I seem to recall that the order in which the bundles are combined is in file name order, though you should be able to test this pretty quickly.
Hope this helps, and best of luck!
I have a web-app (grails 2.3.5, quartz plugin) with multiple users. Now I want that my users can schedule jobs using quartz. I wonder what the best approach is to separate Triggers from one user from the triggers from another user.
e.g. provide a list of all scheduled tasks for a given user
Are there any recommendations how to make this differentiation?
Implementing some scheme for naming your triggers would likely be the best approach here. That way you can query the triggers for a job and filter them by some type of matching pattern.
It's really up to you to decide how you want to manage the visibility and management of the triggers. Using the trigger name seems to be the most logical approach in my own opinion.
Alternatively, you could build a framework (e.g. Domain model) that relates the triggers to a user.
Update
In light of the content of your comment I'd like to offer you a glimpse into how you can dynamically add a trigger to an existing job. This is only an example to help you get further down the path of accomplishing the goal you have.
import org.quartz.CronScheduleBuilder
import org.quartz.Trigger
import org.quartz.TriggerBuilder
...
def jobManagerService
String cronExpression = ... // whatever the expression is
Trigger trigger = TriggerBuilder.newTrigger()
.withIdentity("UniqueNameOfYourTriggerHere-UserId")
.withPriority(6)
.forJob("com.example.package.JobClassNameJob", "groupName")
.withSchedule(CronScheduleBuilder.cronSchedule(cronExpression))
.build()
// if you need job parameters
trigger.jobDataMap.putAll([param1: 'example'])
jobManagerService.getQuartzScheduler().scheduleJob(trigger)
When I open up a build definition I can see the arguments are split into sections with a number prefix e.g. 1. Basic, 2. Misc etc.
However, when I edit the xaml there is no indication as to where these categories are defined.
Can someone provide some guidance as to where they are located within the arguments list?
Here is a similar question except the poster has inquired about a different parameter based off the build settings which I believe is a different case than regular parameters.
Missing ProcessParameterMetadata in TFS DefaultTemplate.xaml: where is for e.g. Items to Build in the Required category
You can open the build template and edit the Metadata argument as shown in the picture below:
Then you can edit the category:
In the XML there is no category as standalone. You can define the category in the Process.Metadata section:
<this:Process.Metadata>
<mtbw:ProcessParameterMetadataCollection>
<mtbw:ProcessParameterMetadata Category="#300 Advanced" Description="Enable MSBuid Multi-proc to build your solutions' projects in parallel, when possible, using all available processors on the build server." DisplayName="MSBuild Multi-Proc" ParameterName="MSBuildMultiProc" />
....
</mtbw:ProcessParameterMetadataCollection>
</this:Process.Metadata>
This is to add new categorys but i dont know where the standard categories are.
Hope that helped you.
Chears
I am using the help-balloons plugin
I would like to use it parametrized. I mean, the messages should come from a properties file. In the documentation appears the following:
<g:helpBalloon code="user.name" suffix=".help"/>
In this last example, the code attribute is used to look up the balloon's title within the message bundle and then the suffix is added to the code (producing user.name.help in our example) as the key to be used for looking up the content of the balloon.
My question is:
Where should be located this properties file (message bundle)?
Can I have one message bundle per controller?
Luis
if you looked at the source code for the help balloon tag, it literally uses the grails interationalization code to render the message if given a key. http://fisheye.codehaus.org/browse/grails-plugins/grails-help-balloons/trunk/grails-app/taglib/HelpBalloonTagLib.groovy?r=45243
check out this page http://www.grails.org/doc/1.0.x/guide/10.%20Internationalization.html it tells you where and how to name the file for message bundles.
as for a message bundle per controller, it doesnt seem like you can (at least not apparent from the documentation). but you can hack it by prefixing the message key by the controller name, and thus use the same message bundle file (message.properties_ but still be able to namespace each message.
Where are the Resource bundles:
There is a directory under grails-app called i18n where all the generated resource files are placed, start looking there and see how they are used in the app.
You may be able to just place multiple message files for your controllers in there for organization, just be careful of reusing keys as I'm not sure how that will be handled off hand.
How to access them:
Maybe this will help I hope:
http://www.nabble.com/Organizing-message-bundles-tt16169280.html#a16169280