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.
Related
The phpStorm plugin for vim: https://github.com/JetBrains/ideavim, is configurable via .ideavimrc (as per the docs). There is an example from the docs:
""" Mappings --------------------------------
map <leader>f <Plug>(easymotion-s)
map <leader>e <Plug>(easymotion-f)
map <leader>d <Action>(Debug)
map <leader>r <Action>(RenameElement)
...
There is the <Action> mapping, where in parethesis is the action IDE should perform. Now there is a list of all supported actions in supported actions.
I would like to map to <leader>] an action to move to next tab. In the supported actions link above, I found the action:
* |gt| {#link com.maddyhome.idea.vim.action.motion.tabs.MotionNextTabAction}
(Or I think, that is the right action, "to move to next tab"). So the I would expect the mapping to be:
map <leader>] <Action>(MotionNextTabAction)
But of course, that does not work. The action name is probably wrong, but I have no other reference then the "supported action list" from the link. So how should look the mapping? How to translate between the list and the "real" action name?
The name of the action is NextTab.
This list is actually not a list of actions, but the list of links to implementation classes for developers. (yes, we should actually update it to be more user-friendly).
Regarding the action name: usually I suggest to use "track action IDs" option to get the name of the action, but for some reason it doesn't work for this case (id of the action is not shown because of some reason). But the search via actionlist still works it you could use it.
Anyway, why wouldn't you just create a mapping to gt? Like map <leader>] gt.
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 am trying to set my yadcf filters up so they can be triggered from a call (link) from another page. I have an angular single page application that has three tabs on it. If a user clicks a link on lets say the first tab, they will go to another tab (separate table) that contains detailed information relevant to the link they click. (e.g. They are on a row in a table that deals with Apple Mac Pro computers. They see that there are 20 skus currently in the system. They click the number 20 and they go to a lower tab (different table) that contains all the information for those skus). There is no server call in the middle. All the data is loaded in all the tables when the application loads up. So, they are simply clicking a link that applies a filter to the detail table.
yadcf can do this through externally_triggered filters. However, when I set 'externally_triggered': true, it stops the actual filters from working on the details table. (In other words, I can no longer go to that table and manually adjust the filters.)
Does anyone know a way around this issue?
It appears the externally_triggered: true switch does not need to be turned on to use yadcf.exFilterColumn() method. I do not understand when it does need to be turned on, but I am able to call the exFilterColumn method and pass it the options needed to 'prefilter' the table while still retaining the ability to filter the table manually.
externally_triggered and yadcf.exFilterColumn are not related in any way, indeed when yadcf.exFilterColumn is used filters behave a bit differently - they are not filtering on change/keyup/etc , but rather only when the uadcf.exFilterExternallyTriggered function is called (its on purpose and all is explained in the docs)
Here is the relevant text from the docs of the externally_triggered, here it is:
* externally_triggered
Required: false
Type: boolean
Default value: false
Description: Filters will filter only when yadcf.exFilterExternallyTriggered(table_arg) is called
Special notes: Useful when you want to build some form with filters and you want to trigger the filter when that form
"submit" button is clicked (instead of filtering per filter input change)
Here is the showcase page
FYI to start, I am aware of how to properly set up an update to a lookup, and am 99% positive I've done this correctly.
I know this because When I set the workflow to automatically start when an Item is Changed, then it works perfectly. But when I simply change this setting so it will automatically start on New Item Creation, it Cancels the workflow and I get a "Coercion Failed: Unable to transform the input lookup data into the requested type." If both options are checked then it fails on creation, but simply clicking edit on the item properties, and the "Save" makes it work.
The workflow is on a Document Library and works as follows;
User selects the Work Task LookUp from a dropdown in the edit properties form after uploading, and then Saves the item (adding it to the document library). The workflow is suppose to then look at the Work Task LookUp selected, and pull the Account and Effective Date-Type lookUp ID's that Work Task item has, and sets the Document's identical fields to the same value.
Here is the code for the workflow if it helps;
If Current Item: Parent Task is not empty
If Current Item: Sub Task is not empty
Log Both are empty to workflow history list
Then Set Account to Work Tasks:Account
The Log Set Account to workflow history list
Then Set Effective Date and Type to WorkTasks: Effective Date and Type
The Log Set EffDateType to the workflow history list
This is all done in one step. I also added additional steps to test if the account and effective date type fields have been set properly, and if not to set them again. But everytime I run the workflow on change and it works, it always correctly sets these fields based upon the first Step (posted above) and the additional check logs to the history that they are not needed.
As an example, The lookUp for Integer for Tasks:Account is set to work as follows;
Date Source: Work Tasks (a list)
Field from Source: Account (a lookup)
Return Field as: Lookup ID (as Integer)
Find the List Item
Field: Title (from the Work Tasks list)
Value: Current Item: Parent Task (Which is a look up of the "Title"
Field from Work Tasks List, and is set to return the Value as a LookUp Value (As Text))
The Effective Date and Type setting is pretty much identical.
So anyone have any insight? I've tried running it as an impersonated Step, setting a workflow pause (for 1 minute), changing the lookup types incase I messed it up to start with, but ultimately the above workflow DOES work, but only when I set it to "Automatically start on the Change (edit) of an Item", NOT "Automatically start on New Item Creation" like I need to to do.
Oh yes, fyi, I am using SPServices CascadingDropDown on the Work Task and Sub Task fields of the doc Library form, but I honestly do not believe this has anything to do with my issue.
UPDATE:
I've talked with another developer, and he believes it is due to the issue that the workflow is occuring too quickly, before the item creates an ID for itself, which it needs to conduct the lookUps. He had me add another "Pause Workflow" to the very top of my workflow code (above the If conditions) and set it for 1 minute.
It then worked properly.
Downside is we want this to labeling to occur as close to item creation as possible. Because a view of the library relies on grouping based upon Account and Effective Date and Type. To add to this downer, Microsoft's Pause Workflow only allows for 1 minute or more, and then the timer used for this is often off, resulting in a pause longer than that. So far, every test is currently showing 2 minutes minimum on the pause.
A possible alternative solution for instantaniously populate the fileds is to use Javascript and SPServices to do the lookUp to the Task list to pull the account and effective date - type fields and then populate, but my Javascript is not very strong and I would need help doing this. If anyone has any suggestions, I would appreciate them.
(Answered in a question edit. Converted to a community wiki answer. See Question with no answers, but issue solved in the comments (or extended in chat) )
The OP wrote:
I don't know if it is the ID for the item after further testing. I changed the start of the workflow to wait until a field in the item changes. I set it to wait until the ID field is not 0 (since you cannot set to null), and it still does not work.
6/14/2012 4:13 PM Comment System Account Waiting on ID
6/14/2012 4:13 PM Comment System Account Waiting complete on ID
6/14/2012 4:13 PM Error System Account Coercion Failed: Unable to transform the input lookup data into the requested type.
I have tried other fields as well, like document ID value is not empty, and it will wait, log it finishing the wait, and then fail.
UPDATE This issue has something to do with the Parent Task field. I have solved the issue without having to wait for a period of time by setting the change from above to wait until the Parent Task field is not empty. It then completes the workflow fine.
Anyone know why there is a delay though? I've solved it, but still don't fully understand what takes it so long.
The main fault has been solved (hence the answer), and the remaining point about the reasons for the delay would probably be a discussion point or not specific enough for SO. Any further clarification can be edited in here.
My application has 5 plugins. Each plugin has a perspective of it's own and hence each perspective extension definition is under individual plugin's plugin.xml.
Now, I want to control the order in which these perspectives appear in my application. How to do it?
There is one main plugin that holds "ApplicationWorkBenchAdvisor.java". This has initialize() method in which I am iterating through the perspective registry using
PlatformUI.getWorkbench().getPerspectiveRegistry().getPerspectives();
and then appending perspective ids in a comma separated fashion to a String variable (pbar) which is used later like this.
PlatformUI.getPreferenceStore().setDefault(IWorkbenchPreferenceConstants.PERSPECTIVE_BAR_EXTRAS, pbar);
PlatformUI.getPreferenceStore().setValue(IWorkbenchPreferenceConstants.PERSPECTIVE_BAR_EXTRAS, pbar);
When iterating thourgh the perspective registry, I can compare perspective ids and sort it(when adding to 'pbar' by comparing ids) the way I want it to appear but, I don't want to do this ordering here as it appears like a dirty way.
Is there any other place where we can fix the order in which perspectives appear? (Each perspective resides in different plugin).
ADDED
1) Could we also control the ordering in the perspective switcher?
2) Is there a way to control entry into perspective registry to in inflict the desired order. If not could we write back into perspective registry?
If your application is encapsulated as an eclipse product, you may tweak the plugin.properties/plugin_customization.ini file.
(file referenced by the 'preferenceCustomization' property in your product extension point.)
This file is a java.io.Properties format file. Typically this file is used to set the values for preferences that are published as part of a plug-in's public API.
(Example of such a file for org.eclipse.platform)
So if the string representing the order of perspective can be referenced as a property, you can define the default order in there.
Since the source code of IWorkbenchPreferenceConstants mentions:
/**
* Lists the extra perspectives to show in the perspective bar.
* The value is a comma-separated list of perspective ids.
* The default is the empty string.
*
* #since 3.2
*/
public static final String JavaDoc PERSPECTIVE_BAR_EXTRAS = "PERSPECTIVE_BAR_EXTRAS"; //$NON-NLS-1$
Maybe a line in the plugin_customization.ini file:
org.eclipse.ui/PERSPECTIVE_BAR_EXTRAS=perspectiveId1,perspectiveId2,perspectiveId3
would allow you to specify that order without having to hard-code it.
Additional notes:
IPerspectiveRegistry (or PerspectiveRegistry) is not made to write anything (especially for perspective defined in an extension)
Ordering may be found in the state of the workbench (stored in the workspace and then restored when its launched again, .metadata/.plugins/org.eclipse.ui.workbench/workbench.xml)
Do you confirm that:
IPerspectiveRegistry registry = PlatformUI.getWorkbench().getPerspectiveRegistry();
IPerspectiveDescriptor[] perspectives = registry.getPerspectives();
is not in the right order when the plugin_customization.ini does define that order correctly ?
Liverpool 5 - 0 Aston Villa does confirm that (in the comments), but also indicates the (ordered) ini file entries internally get recorded into preference store, which means they can be retrieved through the preference store API:
PatformUI.getPreferenceStore().getDefault(
IWorkbenchPreferenceConstants.PERSPECTIVE_BAR_EXTRAS)
Liverpool 5 - 0 Aston Villa then add:
perspective registry (the initial "PlatformUI.getWorkbench().getPerspectiveRegistry().getPerspectives();" bit) remains unaltered (and unordered).
But, you still can "readily access to ordered list of perspectives" through preference store.
So, for other tasks, instead of iterating though perspective registry (which is still unordered), we can use the ordered variable that stores list of ordered perpective ids.
.
.
.
.
Note: another possibility is to Replace the Perspective-Switcher in RCP apps
=> to:
You can more easily define the order in a menu or in buttons there.
Extreme solution: re-implement a perspective switcher.
To sum up all the observations and findings,
1) It is not possible to alter entries in the perspective registry. It is read-only.
2) To make perspective appear in the order that we want on perspective bar, we can achieve it by adding an entry in plugin_customization.ini (or preferences.ini) as shown below.
org.eclipse.ui/PERSPECTIVE_BAR_EXTRAS=perspectiveId1,perspectiveId2,perspectiveId3
3) If we want to fetch this ordered list, we can't fetch it directly. But as this ini file entry internally gets recorded in PreferenceStore we can fetch the same value from PreferenceStore using the following API as shown below.
PlatformUI.getPreferenceStore().getDefault(
IWorkbenchPreferenceConstants.PERSPECTIVE_BAR_EXTRAS);
Why would someone need to access the entry defined in ini file at all?
Well, in my case I had a view in which i had to display links to every perspective. As my perspective bar was sorted in desired order, I also wanted to maintain the same order in my view while displaying links to perspectives.
4) There is no known way to inflict the same sort order in the display of default perspective switcher. While a new custom perspective switcher can be written to achieve the desired effect.