As I am new to Tuleap OpenALM I am trying to figure out how to make an artifact be part of multiple hierarchies. Effectively I have created a tracker to hold business use cases and another one in a hierarchy under it to hold variants of these use cases. Epics, User Stories, and Tasks are in this hierarchy under this variant. (Business Use Case \ Variant \ Epics \ User Stories \ Tasks) Additionally I have created a hierarchy holding Releases and Sprints (Releases \ Sprints). When performing sprint planning the Epics and User Stories do now show up under the release for selection. Is it possible to configure the Epics and User Stories to be under both hierarchies? Does anyone have any other potential solutions? Effectively I am attempting to link or tag the Epics and User Stories with an attribute of Business Use Case and corresponding Variant, and be able to have the use cases and variants in an easy to manage location. Furthermore I want to be able to generate reporting based on completion of stories under each of the use cases and variants. Any advice is much appreciated in advance.
It is not possible for an artifact to be under multiple hierarchies at the moment.But be careful, there is a difference between what we call hierarchy and what you're doing during a sprint planning or a release planning inside the AgileDashboard plugin:
On the AgileDashboard plugin you're not adding User stories under the Releases or Sprints, you're just linking them together.
In the Tracker Administration you can define Hierarchy and then when you link (using an ArtifactLink field) an Artifact A (in tracker A) that is under an Artifact B (in tracker B) following the hierarchy you defined, Artifact A will be visible in the Artifact B children and Artifact B will be visible as Artifact A parent.
So, If I understand correctly your use case (which might not be the case), just link User stories and Epics with the corresponding Business cases/Variant and if your hierarchy is correctly defined you should find them in the children/parent definitions. For the Release/Sprint planning part, continue to do so using the AgileDashboard plugin.
Please let me know if I answered correctly your question.
Related
I have a special content type named "example". I want to show new nodes of this type to anonymous users of my site.
What I need: after 1 week the node was created, content access permissions (Content Access module is installed) are changed that only users with particular role are able to see this node.
Should this be triggered on cron or what? Or just how to do something to nodes that are older than 1 week?
Could you provide some instructions on how to do that? Because I'm new to the Rules module and have no any ideas.
You should be able to do this with Rules (see this question, not exactly what you want but close), but I'd go for a tiny custom module implementing hook_cron, where you fetch all nodes with creation date < (now - 1 week), and modify the permissions for each of them.
It should be more efficient than the Rule approach explained in my first link, where you need to loop over all nodes on each cron execution. And Rules can be quite more annoying than writing plain PHP. I prefer learning Drupal API than spending hours clicking in Rules interface (Rules is great, but it's hard).
Good luck
Yes you should be able to get this to work using the Rules module to implement what you're looking for, but I recommend you to also combine that with the Rules Once per Day and the Views Rules modules, as further explained below.
Step 1: Rules Event
Your question doesn't really specify anything that could/should be used as the Rules Event (for the rule to be triggered. And even though it's like "up to your own imagination" (any Rules Event will do), something that will work for sure is to use the Rules Once per Day module. Here is how it works (as per the comment in issue 2495775, from the module owner):
You specify a trigger hour on the administration settings page for this module.
The Rule trigger will then run when cron tasks are first run after the start of that hour. The actual run time will depend on your cron task timings.
So this is another way to understand/read this:
The "Event" will only be triggered when a cron job is run.
And that event will only be triggered 1 time / day, i.e. "next time cron runs after the trigger hour has passed".
Step 2: Rules Actions (and optional events)
Some details about the Views Rules module (from its project page):
Provides Views directly as Rules actions and loops to seamlessly use view result data.
The previous quote may seem a bit cryptic (it may make you think like "so what, how can this help me?"). Therefor some more details about how to move forward using these modules:
Create a view (using Views) so that you have 1 Views result (row) with all the nodes (of at least 1 week old) you want to be processed, whereas that view has fields (columns) for whatever is needed in subsequent steps, eg the node ID, but possibly other fields as well. You'll need these View fields later on as values to be processed by your rule, "to change the content access permissions (using the content_access module) so that only users with particular role are able to see such nodes" (similar to what you mentioned in your question). Important: use a Views display type of "Rules".
Create a custom rule in which you use the Views Rules module to iterate over each of these Views results in a Rules action, using the Rules technique known as a "Rules Loop".
For each iteration step in your Rules loop, perform a Rules Action to "do your thing" (= change the content access permissions). At that point you'll have all data from each column of your Views results available as so called Rules Parameters. So at that point it's a piece of cake to adapt the content access permissions for the node you're processing in that loop.
Optionally, you may also want to add whatever extra Rules Condition(s), also up to your own imagination.
Easy, no?
Is it possible to assign a person or a group of people as reviewers in a certain state of a workflow in Plone?
I have been looking at AutoRole en the IRolesplugin, but do not seem to find what I need?
In our case, users need a multiple review step workflow, yet the first reviewer should have control over which reviewers come afterwards...
Workflows can trigger scripts. Scripts can do things like grant roles to users. You'd have to come up with an approach to letting your first specify additional users. There are probably multiple ways to do it, but I could imagine using archetypes.schemextender or a custom content type to provide a field for choosing additional reviewers, only visible to initial reviewers. Then use those values in the workflow script. http://plone.org/documentation/kb/creating-workflows-in-plone/tutorial-all-pages provides a good overview of how DCWorkflow works.
I want to allow the user to create 10 content nodes on a single page instead of clicking on "add a new node each" time. This is just to save the users time when he/she wants to create 80 nodes at one time.
Is there any such module which supports this functionality or will I need to write a module for my own?
The first module I can think of (reading your description) is Nodes, which is described using the following text:
The Nodes module allows a user to edit multiple nodes at once. The module provides a simple table layout, similar to Editview, so that multiple nodes can be seen at once, and quickly and easily edited.
Changes to a node are done using AJAX like calls, so that as each field is edited, it is changed on the live version of the node. This means that any edits that take place are not submitted in bulk, and therefore any problems that arise as editing takes place can be dealt with on a field by field basis.
Unfortunately, the project doesn't have any public release.
Editview, referred in the description, is a Views plugin that allows to create a view where all the listed nodes are editable.
Other modules you can find on drupal.org are:
Mass Content Creator
Node Repeat, which allows to create duplicates/clones of nodes
Multiple Node Add
Slickgrid can be used for this purpose.
I need to adjust the way which a content is determined as published or not published. The editor of particular content (this is a separate non-administrative role) should have a possibility to set the published flag for particular node (it can be achieved using Override Node Options module directly or by implementing it's techniques). He should also be able to set two additional publication attributes, i.e. publication start date and publication end date (the fields can be added using Content Construction Kit). These optional fields should be used to determine node's published status. Let's say that if specified, they will override published flag.
Basically I would like to be able to add my bits of SQL code to the WHERE section of proper query or to postprocess result of such query. Maybe to overwrite some function or provide some callback. Solutions based on writing of custom modules are fully acceptable.
I am using Drupal 6.
It sounds like one of either the Node Expire or Scheduler modules should do what you need.
I effectively want two nodes:
Normal Node
Premium Node
The only difference will be that the premium node can take more images and a few other features. What is the best strategy to go about this?
have two distinct nodes with the differences
have one nodes and somehow find a to apply an UPGRADED attribute to it?
I would prefer (b), as I want users to be able to upgrade nodes. And migrating a normal node to a premium node will be very difficult.
Any idea how I can accomplish b?
I would create two different content types (CCK), and either write custom code to translate between the two or use a module like Node Convert (in order to upgrade a node); it might be complicated at first, but you would have the advantage of being able to apply all of your restrictions (allowed image count, permissions etc) on a per-content type basis.
Here is an excerpt from the Node Convert project page:
... adds a menu tab "Convert" on the node view page, i.e. node/1/convert, which gives the ability to convert the node from its current node type to another node type. The module provides the means to transfer all the field values of the current node type into fields on the destination node type, or discard them.
The module integrates with Actions, Rules, Views Bulk Operations and Admin Views nicely. It has support for exporting templates into Features using CTools Exportables. It also provides a hook that enables developers to execute additional code on conversion.
You might be able to implement (b) as two different input filters - one for non-upgraded and one for upgraded. Then "upgrading" the node would be as simple as changing the input filter applied to its contents.