When I deploy a picklist’s metadata, If picklist values are missing from a component definition, they get deactivated when deployed. Deactivation occurs only for missing picklist options for for both standard and custom fields.
Any one has any idea how to prevent this not to set deactivate for any missing picklist value?
Obviously, update your metadata by adding missing picklist values.
Related
I'm new to grafana, so I might be missing something obvious. But, I have a custom cloudwatch metric that records http response codes into buckets (e.g. 2xx, 3xx, etc.).
My grafana visualization is using a query to pull and group data from cloudwatch and the resulting fields are dynamic: 2xx (us-east-1), 2xx (us-west-1), 3xx (us-east-1), etc.
I then use transformations to aggregate those values for a global view of the data:
The problem is, I can't create the transformation until the data exists. I'd like to have a 5xx field, but since that data is sporadic, it doesn't show up in the UI and I can't find a way to force "5xx (...)" to exist and have it get used when/if those response codes start occurring.
Is there a way to create placeholder fields somehow to achieve this?
You can't create it in the UI. But you have still option to edit that in the panel model directly. It is JSON, which represent whole panel. Edit it manually - in the panel menu click Inspect > Panel JSON and create&customize another item in the transformation section. It is not very convenient option to edit panel, but you will achieve your target.
I would like to to automatically add data to multiple fields when creating new work item in Azure Devops boards
For example: when a user create new bug - the planned version field will be set automatically to lastest version available
You can try to use the work item rule feature to do this.
For example:
Conditions
When A work item is create ...
Actions
Then Set the value of ... {Field Name} to {Value}
This feature is available in all the customize processes (Inheritance process). For more details, you can reference the document "Add a rule to a work item type".
Can I add an unique custom field inside a work item.
So when a new work item is added, a validation error occurs if a previously added work item already contain a that value.
I've tried inside the "Rule" section of work item customization, but without success
There is no built-in rule to enforce uniqueness. The only field that is guaranteed to be unique is the work item ID.
It is possible to create a custom control that uses the REST API to query whether the contents of a field are unique and have it enforce that uniqueness. But that has a few caveats. The rule will only be enforced in the UI, other experiences (like bulk changes, excel etc) won't triggr this validation. Direct manipulation through he REST API won't either. And I would expect concurrency problems when you venture in this direction.
I am trying to host a metadata file and act as an IdP.
To generate the metadata I used the following online tool https://www.samltool.com/idp_metadata.php
After filling out the form and building it, the validUntil attribute is set to be the current timestamp.
When trying to test this metadata with https://samltest.id/upload.php it says expired.
When I increment the year and try again the metadata date doesn't seem to change.
How can create an IdP metadata file that is valid?
You can manually change the validUntil value according with your requirement. There won't be any issue during validation on the aforementioned site.
To verify, I just quickly ran through changing the field value and my input meta-data passed the validation.
original
and updated
results.
When we define custom metadata for the components, it is my understanding that this user-given metadata is stored in SQL server. And it is not visible in the component xml. Can anyone explain how exactly a metadata linked to a component will actually get stored?
A Component definition in Tridion has two types of fields: Content fields and Metadata fields. Both field types are stored in the Content Manager database (either SQL Server or Oracle). And both field types are retrieved whenever you read the Component back from Tridion through any of its APIs (TOM, TOM.NET or Core Service).
Only the Content fields are shown in the Source tab of a Component edit window, but the Metadata fields are visible on the Metadata tab of that same window.
If you want to have a single view of the XML of both Metadata and Content fields (as well as many other properties of you Component in Tridion), consider installing the PowerTools or the Item XML extension.
I think you may be confusing things a bit.
The Metadata is always stored as part of the component - under tcm:Metadata. When you publish this component, then the metadata fields will also be available for querying on the Content Delivery Data Store.
Whether these fields get displayed as part of the component presentation depends on your templates. There's nothing stopping you from including these values in the output of your template (typical use case for SEO, for instance).
In summary:
In the CM, the Metadata is stored together with the Component
In the CD, the Metadata is stored as part of the "CUSTOM_META"
associated with this component.
Just a note,
There is another metadata that is not stored as metadata fields, which is the system metadata, such as Last Modified Date or the user that last modified the component. That's metadata in the CMS. Also there is system metadata in the front-end (broker or file system metadata) that gets published when you publish a given component, such as Last Published Date.
You can leverage/use the system metadata in your templates as well.