Recent searches
No recent searches

Dru Kepple
Joined Apr 15, 2021
·
Last activity Oct 27, 2021
Following
0
Followers
0
Total activity
16
Votes
2
Subscriptions
11
ACTIVITY OVERVIEW
BADGES
ARTICLES
POSTS
COMMUNITY COMMENTS
ARTICLE COMMENTS
ACTIVITY OVERVIEW
Latest activity by Dru Kepple
Dru Kepple commented,
+1...plus more-than-one if possible... This request just came down from on-high; but it's my fault that I'm unable to comply!
View comment · Posted Aug 28, 2019 · Dru Kepple
0
Followers
0
Votes
0
Comments
Dru Kepple commented,
+1 for this feature. We're in a similar situation where our end users would prefer some anonymity.
Thank you for letting us know that you're looking into it, at least.
View comment · Posted Jan 25, 2019 · Dru Kepple
0
Followers
0
Votes
0
Comments
Dru Kepple commented,
One more +1.
My use case: We're in the situation of need to "backfill" data for metrics purposes. As we use the platform we make changes, add data, migrate this or that...it's easy enough to write scripts that utilize the API to update old tickets in some cases, but obviously we can update non-closed tickets. We would love to be able to update all tickets.
For example, we realized we needed to migrate a custom string field to a custom number field, and after learning we can't change the data type of a custom field once it's been created (another request...) we created a "sister" field for the same data. We'd like to drop the string field all together, but we can't because of all of the closed tickets for which we cannot migrate the data.
This makes me worry that as we deprecate old custom fields, they'll just pile up and create clutter, and we'll have to continue to add to our metrics logic to "check this field and if it doesn't exist check this field and if that doesn't exist check this field and...."
View comment · Posted Dec 21, 2018 · Dru Kepple
0
Followers
0
Votes
0
Comments