I am trying to create a gird of user stories and defects together so that they can be properly prioritized by our product owner. I have tried using the 2.0 API to do this but have hit a wall. Looks like the Rally.ui.grid.Grid requires a single model but there are no model types that can be used to mix both User Stories and Defects together.
I tried using the getModels method but that only creates two distinct models and the grid doesn't like that. The grid requires only one model.
I have also tried creating my own model based on Artifacts but to register that with the ModelFactory I have to create a factory class which I don't know how to do.
Is there another way to do this given the 2.0 API?
You may use use Rally.data.wsapi.artifact.Store instead of Rally.data.wsapi.Store. See an example in this github repo.
var myStore = Ext.create('Rally.data.wsapi.artifact.Store',{
models: ['User Story', 'Defect'],
autoLoad:true,
//...
});
Related
I am using this rally API to get the list of all the stories:
https://rally-n.rallydev.com/slm/webservice/v2.0/hierarchicalrequirement?query=(Project.Name="My_Parent_Project")&order=OrderString
My_Parent_Project actually do not have any user stories, but its children projects (my_child_1 and my_child_2) has user stories.
Is there any specific field, which I can mention to get all the user stories including child projects.
I can see Rally UI has option to get the data from Child project. So I believe there must be an option to get this data using above API. (They use projectScopeUp=false&setScopedDown=true which doesn't seems to be working with
"hierarchicalrequirement" API.
You're really close.
It seems like you've already found the project scoping docs:
https://rally1.rallydev.com/slm/doc/webservice/projectscope.jsp
I think if you just swap your (Project.Name = "My_Parent_Project") query to instead use the project=/project/12345 query string parameter and include projectScopeDown=true you should be all set.
Can somebody bring the light on the following issue - I can't figure out the difference between alfresco workflow model and repository model. Are they different ? Can I use them together, or one inside the other ?
Workflow model deals with the Business Process Modeling(BPM), where you would manage flow of different tasks to user by user. On the other hand there is a 'Content Model' which is independent of workflow model, and it deals with your content types, properties and constraints within the content model. Both are different and independent, however you can use both of them together.
I want to query for user stories and the Initiative that each story falls under. My fetch property looks like:
...
model: 'UserStory',
fetch: ['Name', 'PortfolioItem', 'Parent'],
...
This fetches the PortfolioItem/Feature object, PortfolioItem/FeatureGroup object but not the PortfolioItem/Initiative. The FeatureGroup object does not show a 'Parent' property.
In short, how can I fetch the parent's parent without querying separately for Initiatives and comparing the '_ref' or something like that?
For server performance reasons the hierarchical relationships will only be populated for one level with each request. You'll have to make subsequent requests to build the remaining tiers.
If you hit the new Lookback API (unreleased when Kyle first answered, now in open preview), the snapshots returned include a field _ItemHierarchy which will include the ObjectID of all ancestors including all the way up through Portfolio Items.
You can find information on the LBAPI here. There is support for querying it in the App SDK 2.0's SnapshotStore. Note that SDK 2.0p6 (releasing soon) has some improvements.
Old, old question. But I recently did the same thing for the entire tree. I didn't use the lookback api. I created a model and stored the data and went through the parentage of each portfolio item.
Perhaps not the most efficient way, but it works.
I have a model that has several columns I want to present to the interface to update as different pages. My question deals with what is the best rails-y way to organize your routes and controller actions.
For example, a User has a "Profile" and a "Billing Address". Both pages contain columns only from the User model, they are required and one-to-one, and small, so an additional model seems like unnecessary overhead.
It seems like I have to add a GET and a PUT for each different view I want to present, is that right? So instead of just edit/update, I'd need edit_profile/update_profile and edit_billing/update_billing, etc.
Even without a Profile model, I think you still can use ProfileController and views for profile like 'views/update.html.erb', and make it route as '/users/123/profile/'.
In my opinion, we don't need to mapping every view or controller to one model strictly. Rails is based on ROA, but here the "resource" can be more abstract.
I want to apply REST to my Rails 3 application.
I understand the basics but am still a NOOB and would like some help or advice if this is correct.
I have a USER model. However I have three kinds of User, as in they have different roles in the application.
When I create say the Celebrant I need to do other things in the create action that are different then the things I need to to for the Manager which is again different from what I need to do for the Participant.
So I was thinking of creating three resources.
1.Celebrant - new create only
2.Manager -new create only
3.Participant. -new create only
This way I can have the three REST NEW and CREATE actions that are different from each.
Is this the best way to go about this?
A couple of thoughts…
1. DRY
If Celebrant, Manager, and Participant all extend User, then it's best to have 1 controller. Most of the code will be the same between the 3 controllers otherwise.
2. Fat Models, Skinny Controllers
The controllers just pass parameters to models, so really you should only have to call 1 method on the model in the controller, like User.create. This makes it so your controllers don't perform any logic, so you don't need 3 separate controllers.
Check out the inherited_resources gem to pretty much remove all code from your controllers.
Doing it like this, you handle what happens before/after create in each of your User model subclasses.
3. Using a Role model instead of User subclasses
I ran into your exact problem before. I started with 3 user classes. But I quickly wanted to do more with the roles, add more, blur the lines, etc. By having 1 User model which has_many :roles (there's role plugins out there), you can handle all your custom logic in your save callbacks in the user model based on roles. Now your controller is lean, and you don't have to manage 3 classes.
Hope that helps.