How can one remove a Parcel object from a Depot such that we can pick it up with a Vehicle? There is a method called addParcelIn(), but we cannot find its counterpart. Thanks!
The current version (RinSim 4.4.3) doesn't support picking up a Parcel inside a Depot. A workaround is to add the parcel to the RoadModel at the same location as the depot, take a look at RoadModel.addObjectAtSamePosition(..). Pickups can then be done via PDPModel.pickup(..).
Related
I'm using TFS's workitens to DBA's team apply scripts in homologation/production, so, i'm creating a workitem and linking BD's scripts in it. To make sure that nobody will change the script after i created the workitem, the DBAs team is locking the scripts in TFS before aplly. I think there is another tool or method to make it safer and smarter
You can give a try with this workaround by Angela Dugan, In short the solution of Angela works as follows:
Add a field [UserAccessDenied] to a work item but do not show this
on the form In the desired state add a rule [REQUIRED] for a certain
group
Because you can not enter a value, you can never save the work item,
so it is “sort of” read only.
For example, after setting only you in can make a state transition from [Active] to [Resolved]
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 ...).
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.
I need information about node's creation & last modification dates...
Is there a way to automatically handle created and updated properties for a node?
Hibernate offers #Version for updated field. Is there something similar with Node4J.
I found http://neo4j.rubyforge.org/classes/Neo4j/Rails/Timestamps.html but it seems to be only available for Ruby.
You can use annotations form the spring-data-commons library. Use #CreatedDate and #LastModifiedDate on properties of type Long. Make sure you're using the simple mapping mode. For now, advanced mapping mode does not support this, see DATAGRAPH-335.
In the zf2 database and models tutorial a path such as this leads to a directory containing my model classes:
module/Album/src/Album/Model
I have created two more classes at:
module/Album/src/Album/Model/AlbumRelatedClass.php
module/Album/src/Album/Model/AlbumRelatedTable.php
I would like to put these classes at
module/Album/src/AlbumRelated/Model/
I have created duplicates of the model classes there for the purposes of this test, unfortunately, my module config for Album tells me that it cannot find the classes at the AlbumRelated location. I have tried changing the namespaces in the AlbumRelated location to AlbumRelated\Model and directly referring to the class location (\Album\Model\AlbumRelated()) without success.
Does anyone know how I can do this? If I shouldn't be doing this, can somebody explain why? I'm also interested to know why the folder structure is Album/Model/Album (it seems redundant, and I wasn't clear on the explanation in the tutorial).
Any help given would be great, thanks :)
The short answer is that it can't find the class because you probably didn't set up the autoloader config to know about a new "AlbumRelated" namespace. Look at what happens in \Album\Module::getAutoloaderConfig(). You probably want to add a key/value pair to namespaces like 'AlbumRelated' => __DIR__ . '/src/AlbumRelated'. That will tell the autoloader where to look for classes under the AlbumRelated namespace.
That said,
If I shouldn't be doing this, can somebody explain why?
You probably shouldn't be doing it that way. You've got a top-level namespace called \Album. Then you have \Album\Model namespace under it. Any models related to Albums ought to live there. Imagine you had an entity in your system for Record Labels, so you could associate an Album with the label that released it. The ZF2 expectation is that you'd create a class called \Album\Model\RecordLabel that lived in module/Album/src/Album/Model/RecordLabel.php. As long as we assume that RecordLabels are primarily related to albums, that all makes perfect sense.
Of course, you could stick RecordLabel in it's own module as well, if you had a lot of workflow around managing them.
I'm also interested to know why the folder structure is Album/Model/Album
I assume you mean Album/src/Album. That redundancy is to keep a nice clean PSR-0 setup. So, the first Album is identifying the module, and the second is the top-level of the Album namespace. This provides maximum flexibility, but isn't a hard and fast rule. See Rob Allen's recent blog post about alternative module layouts in zf2 for an exploration.