In JIRA, you can create custom fields which is good, but I feel that their field types are relatively weak.
For example, you can choose the 'Label' which you can add custom labels. That is good, but I need to be able to choose from a list that already exists and do not want users to be able to create new ones freely.
So that leaves us with the option of using a Single Selection List or a Multi-Selection List. The problem with this is the limited way of using it... drop-down. I wish you could populate an item similar to the way you can add a predefined 'Version' or 'Component'. The drop-down feels primitive.
So my question is: Are there a way of changing the selection interface of a list so that it mimics the way you would set a 'Target Version' for example (simply type it in freely and you can remove an item by clicking on the 'X' button).
Or if not, is there a way to create completely separate groups so that they can behave exactly like the 'Version' and the respective 'Version Picker' field.
I want my 'Customer' field to look and behave exactly like my 'Version' fields... not drop-down like.
Versions and Components fields use autocomplete renderer, but
For custom fields of type Multi Select, only the Select List Renderer is available. Furthermore, when modifying a field configuration, you will not be able to configure a Multi Select custom field's renderer.
see this link https://answers.atlassian.com/questions/16669/looking-for-a-custom-field-similar-to-the-component-field
Related
I'm wondering if it is possible to create a kinda scheme that is a list of custom fields and apply this scheme to an issue type.
This would cause that issue type to have all custom fields in the list.
I know you have to first associate the field with a screen and also a field configuration. But its this last step 'project and issue type scope' that is confusing me.
The only way I could see how to do this is to go into EACH custom field, then go to the CONTEXTS for that field, then add a new context associating the field and the issue type.
Field configurations and field configuration schemes don't seem to do the trick. It still seems a necessary condition to have your custom field associated with an issue type, but you still need to do that step above, to create a new context for each custom field.
I'm wondering if there is a way to group all the fields in a scheme and associate that scheme once instead of having to do it for EACH FIELD.
Am I missing something? Or it's just not possible?
You're looking for Issue Type Screen Scheme.
First create a default screen with the fields for issue type X. You can also create screens for Create and Edit too if you want
Then define a Screen Scheme for issue type X which says which of those screens to use for that issue type.
Then create an Issue Type Screen Scheme (ITSS) that uses the Screen Scheme for issue type X
It is convoluted but does work. Don't use Field Configurations unless you need to make the field required, and even then it's better to use a Validator on a transition. The only time you need a custom field context is if you have select lists with different sets of options for different projects. If possible, avoid using issue types in custom field contexts.
We have site where a user went to the Data Types, saw we had a Content Picker data type using "(Obsolete) Content Picker" (Umbraco.ContentPickerAlias) and changed it to Umbraco.ContentPicker2
Our code relies on the obsolete one currently and now he cannot set the content we want him to.
Is there a way to recreate/reimport the Obsolete property editor into Umbraco?
On the Data Types node you can click on the ... and create a 'New data type' - then select the obsolete one to create it again.
But in theory, I believe you could just do the opposite of what the user did, on the ContentPicker click edit and pick the property editor from the dropdown if available?
Within the umbracoSettings.config file, there is a property you can create/set to true that will make obsolete data types become available to use against data types
<showDeprecatedPropertyEditors>true</showDeprecatedPropertyEditors>
I am having one document type which contains a dropdown list, I need to add a couple of things in it:
I need to display the Database table names in drop-down dynamically.
On the change of dropdown option, i need to display the selected table columns names in another drop-down.
Are above things possible by using only existing data types or it will require creating a custom template using razor syntaxes (if it is so then how the template will display directly in the back office content node?)
Can you please provide your views and any links for code/tutorials?
screen shot of content form
If this is for the back office, you will need to do it in HTML and Angular, with an API controller to handle the DB lookup stuff.
As far as I'm aware, there's nothing built in to do dropdowns that depend on each other, so you'd have to create a new DataType to do it.
The process is to long to detail here, but here are some useful links on creating custom DocTypes in Umbraco 7.
https://our.umbraco.org/documentation/tutorials/Creating-a-Property-Editor/
http://velstand.info/tips/umbraco/to-create-a-datatype-by-using-external-data-sources/
https://24days.in/umbraco-cms/2016/custom-property-editor-tutorial/
I have a dropdown list conatining some options. The last one is "other". When the user chooses the other option a textbox appears next to the drop down list. When the user chooses "other" he must enter a value into the textbox. Both, the dropdown list and the textbox, point to one single property of the the model.
How do I achieve this using custom validation? what is the best solution?
It seems what you're looking for is conditional validation. A very nice example is already mentioned in another question where you could create a custom RequiredIf attribute.
The topic has also been addressed frequently on stackoverflow.com
We all know that when we create new control in FB it gives its name control-1. When we create the next control it give its name control-2 an so on. Is it possible to write a rule for giving names to controls? For instance: For specific column in grid, column with name A, give to all controls in this column name which starts with A_ suffix?
As a form author, you can change the name of a control after you add it in Form Builder. However, if you want to change the default naming scheme, you would have to change code in Orbeon Forms. Currently, this is done with controlName(nextId(doc, "control")) in ToolboxOps.scala.