I have a list of user stories which are assigned to different features (assuming none of them are orphaned). On the Portfolio Item Feature level, there is a custom boolean field called Redelivered.
I want to find out which user stories are associated with a parent feature where Redelivered = True, but I can't seem to do that from user story level, such as "parent.c_redelivered = true"
Already solved this myself.
We could use PortfolioItem.c_Redelivered = True to accomplish what I wanted.
Related
In a to-do list where users have both system-created items and their own items, how would you store the items?
A to-do list can have a mix of items. The system-created items can be modified and deleted just like user-created items. There difference is the titles and description text for the system-created items are initially pulled from a configuration. Many users can have the same system-created items. E.g. if two users want to paint rooms in their houses, they'd both get "buy paint" items.
Option 1
Save the full system-created items (including the title & text) with the user-created items.
Pros: Flexibility for user modifications since the items belong to the user and are not dependent on a central item configuration.
Cons: Lots of redundancy because there will be many users all with the same items.
Option 2
Save references to a configuration for system-created items with the user-created items.
Pros: Flexibility for system modifications since if we want to say "buy X-brand paint" instead of "buy paint", the change is easily reflected for all users with this item.
Cons: System-created items have to persist forever in the configuration even if the item is no longer relevant for new to-do lists because otherwise the user's reference will be broken.
Other options?
Thank you!
My initial thought is - what is your requirement? Your user-flows and project road-map might contain information to inform your design.
From your question "system-created items can be modified and deleted just like user-created items":
This indicates that you are going to have to have a way to track modifications to your 'system-created' templates per user or convert them to 'user-created' messages when they are edited.
This is more complexity than you seem to need
It seems much simpler to create messages from system templates, then have them be regular messages.
A bit of extra storage is not going to break the bank
You have not mentioned any case where you would need to operate over only system-created to-do's. But in this case, you could include created-by metadata.
I think the key here is whether you need to be able to modify a "system todo", and that change to be reflected in all the "user todos"...
If that's a requirement (it sounds sensible to me), your only option is Option 2 - the real con of Option 1 is once you copied the "system todo" as a "user todo", you cannot tell anymore whether they're related...
I'd go for a model similar to this, with 2 entities/tables:
ToDoTemplate
Integer id
String name
String description
ToDoItem
Integer id
ToDoTemplate template
Boolean completed = false
?String name = null
?String description = null
When you create a ToDoItem, you create it based on a ToDoTemplate (it may be a blank template), and you set the name and description as null, reusing the template name/description... Only if the user modifies their own ToDoItem is when you store that value... i.e.
String getName() {
return this.name != null ? this.name : this.template.name;
}
This is the most flexible of the approaches, and the only valid in many situations... Note the con you mention:
Cons: System-created items have to persist forever in the configuration even if the item is no longer relevant for new to-do lists because otherwise the user's reference will be broken.
This is not a con really - as long as there's one ToDoItem that uses a given ToDoTemplate, the template is still relevant, and of course there's no reason to remove it...
I have a table driven by DataTables 1.10. Filtering is turned on. When I talk about "doing a search" below, I'm talking about using the filtering function of this table.
Description of the Problem
Everything works fine with stateSave off. However, when stateSave is on, the following happens:
Alice logs in as admin. Because admin has all privileges, when she does a search through articles, she can see all articles. Because some articles are published and some are unpublished the table has a column that show which are published and which are not. So far so good.
Bob, a random user, accesses the site. Random users cannot ever see unpublished articles so the table hides the column that shows publication status. So far so good.
Alice logs out. She now accesses the site like a random user. So she should see exactly what Bob sees. However, when she does a search she still sees the column that indicates publication status.
(Note: The issue I'm discussing here is purely one of user interface. The server ensures that unprivileged users cannot ever get a record for an unpublished article. The problem though is that the additional column gives unpriviledged users information that they do not need. They can only see published articles in their search so they don't need to see that every article they get in a search is published.)
The code that configures the datatable hides the publication column by doing something like this:
var columnDefs = [];
if (!privileged) {
columnDefs.push({
targets: [1],
orderable: false,
visible: false
});
}
columnDefs is passed to DataTables as the columnDefs option.
Technical Reason for the Problem
The problem is that DataTables store things like column visibility into the state it saves into localStorage. So when Alice logs out and makes a search again as an unprivileged user, even though the value of columnDefs is correct, it is overwritten by the saved state. That state was stored when Alice was an admin, and it declared the publication column to be visible, so it remains visible even when Alice is accessing the site as an unprivileged user.
What I want is for users to benefit from the saved state but avoid having this state carry over when the user's privileges change.
Caveats:
I don't want to use sessionStorage because I want the state to persist between browser closings, but sessionStorage is cleared when the browser is closed.
I cannot use the session cookie assigned by the server to detect logins and logouts because it is HTTP only. Besides, privileges could change for other reasons.
I do not want to arbitrarily set an expiration time on the saved state.
The solution I've settled on is to use an additional field in the saved data to know when the conditions I care about have changed. This is a field whose value changes depending on the privileges that the user currently has. For instance, because in the case I described here, I decide to hide or show a column on the basis of a variable named priviledged (which is initialized from data provided by the server), it could be as simple as:
var token = privileged;
Then I set stateSaveParams to record the token when the state is saved:
stateSaveParams: function (settings, data) {
data.myapp_token = token;
}
The prefix myapp_ is just there to avoid possible collisions with DataTable's own fields.
I set stateLoadParams so that if the current value of token differs from what has been recorded before, the state is cleared:
stateLoadParams: function (settings, data) {
if (data.myapp_token !== token) {
this.api().state.clear(); // Clears the state.
return false; // Tells DataTables to not use the state that was stored.
}
// This return is here to keep the IDE happy but does not do anything special.
return undefined;
},
I've just set token to the single condition I've shown in my question (privileged) in this example but in production I use a combination of variables plus a local version number so I can bump the value of token as needed if I do something that requires clearing the state but cannot be detected just as a privilege change.
I want to move about 100 user stores to features. I use query to get the type, but I don't know how to change it.
query.query_string = "(FormattedID = \"US4332\")"
results = #rally.find(query)
#res = results.first
puts #res["_type"]
Unfortunately it is not possible to change work item type, and this limitation is not specific to Web Services API, and applies to UI too, with the exception of converting a defect to a story in the UI.
The closest you'll be able to get is to create new features as close to copies of the original stories as possible (including moving children, etc).
I've created a Rally.ui.AddNew button to add a new release.
If the user hits "Add with Details" (which is the only active button for releases, you can't add a release without details) I would like certain fields to be set by default when the dialog is opened.
For example, I would like the "Create matching Releases in all child projects" checkbox to be set (if it exists), and I'd like to put a default note in the "Notes" area.
How do I do that? It does not look like the listeners "beforecreate" or "create" are called if the details dialog comes up.
Ideally I'd also like a chance to check these items again with another listener just before the item is created. Do these listeners exist?
The Rally standard editor likely provides only limited capabilities for defaulting field values when instantiated. As an indication, AppSDK1 had the rally.sdk.util.Navigation.popupCreatePage() method, which would accept an object with default values, for example:
// Open Defect editor with Defect default-associated to User Story with OID 12345
rally.sdk.util.Navigation.popupCreatePage("defect", {requirementOid: 12345});
The default key/value pairs that this method accepts were not well-documented. One of Rally's UI Engineers provided me with this list at one time:
rally.sdk.util.Navigation.popupCreatePage defaults keys
User Story:
defaultName
rank
iteration
release
parent
dpyOid {dependency}
Defect:
defaultName
defectSuiteOid {Defect Suites}
testCaseResult
testCase
requirement
iteration
Defect Suite:
defaultName
rank
iteration
Portfolio Item:
defaultName
rank
parent
Task:
workProduct
Test Case:
testfolderOid {Test Folder}
artifactOid {Artifact}
Test Set:
iteration
release
While the above list may not be exhaustive (or even completely accurate anymore), it suggests that the allowed defaults for the standard Rally Editor may not include the "Create matching Releases in all child projects" checkbox or the Notes field.
Nonetheless, it's not immediately apparent to me that there is any method or config for AppSDK2's Rally.ui.AddNew that is an analog in functionality to AppSDK1's rally.sdk.util.Navigation.popupCreatePage() ability to setup default values into the resulting Editor window. Hopefully one of Rally's UI Engineers may have better information to add to this question.
Unfortunately for now not all the built-in fields are defaultable (see Mark W's answer above for the list of pre-fillable fields). Any custom fields are though. You'll want to check out the beforeeditorshow event. You can modify the params there.
addNewComponent.on('beforeeditorshow', function(addNew, params) {
params.defaultName = 'foo';
params.c_MyField = 'bar';
});
Note that if you would just like to create or edit objects you can directly call the methods on Rally.nav.Manager.
Is there a way to use a select box in a rails form for multiple booleans? Let's say I have three weather conditions: Clear, Cloudy, Rainy that are each boolean. Can I put them in one select box titled "Weather", and when one of them is picked that one becomes 'true'?
To me, I see this as two different actions.
1) The user making a selection from a selection_box helper on the form. That variable gets set to the resource :current_weather and stored in the database.
2) After submit button is clicked then is more logic processed in the controller or through a class method. Let's say it was in the 'update' portion of CRUD in a weather tracker.
def update
#tracker = Tracker.find(params[:id])
if #tracker.current_weather == "Clear"
#do this
end
end
Maybe this will give you some ideas. Good luck!