Setting required action on new keycloak user account - keycloak

I am using a client to create a new keycloak user. Something like this:
keycloak.realm(realm)
.users()
.create(user);
The user variable is a UserRepresentation object, and I'm trying to add an Update Password required action:
user.setRequiredActions(singletonList("Update Password"))
User gets created ok, the problem is that I don't have the required action set
Not sure what I'm doing wrong, should I specify a different value in the required actions list?
Thanks

Figured out what was up.
Keycloak has an enum to represent various user actions:
public static enum RequiredAction {
VERIFY_EMAIL, UPDATE_PROFILE, CONFIGURE_TOTP, UPDATE_PASSWORD, TERMS_AND_CONDITIONS
}
So the value should be "UPDATE_PASSWORD" not "Update password"

To find out all the possible required actions aliases, export your targeted realm as json from the admin interface. In the json you will find the "requiredActions" array in which all the legal actions are listed like so:
"requiredActions": [
{
"alias": "CONFIGURE_TOTP",
"name": "Configure OTP",
"providerId": "CONFIGURE_TOTP",
"enabled": true,
"defaultAction": false,
"priority": 10,
"config": {}
},
{
"alias": "terms_and_conditions",
"name": "Terms and Conditions",
"providerId": "terms_and_conditions",
"enabled": false,
"defaultAction": false,
"priority": 20,
"config": {}
},
Just use the string under the "alias" tag when setting the list of required actions in the code.

Now in Keycloak 8.x you can use
UserResource.toRepresentation().setRequiredActions(...);
to manually trigger an action like "verify email" after changing the loginname.

Related

Turning the "Autocreate conversation" setting on via API

I'm attaching a picture here to make it more clear about what exactly I'm trying to do. I have sub-accounts under my account for which I purchase a number and that turn on "auto create conversation" setting for each of those subaccounts.
The way I do it from the Twilio Online GUI screeen is attached in the picture. However, I'd like to automate this using API. I haven't been able to do this exactly.
The closest thing I found was here. https://www.twilio.com/docs/conversations/api/address-configuration-resource
This hasn't worked for me.
Can someone suggest what I'm doing wrong?
Here are the steps I'm doing right now
Create a sub-account under main account
Purchase a number under sub-account
Attach the phone number to the default messaging service using the snippet below
await client.messaging.v1.services(service.sid)
.phoneNumbers
.create({
phoneNumberSid: activeNumberSid
});
Then create the addressConfiguration for this newly purchased number
as mentioned below
Address Configuration
client.conversations.v1.addressConfigurations
.create({
friendlyName: 'My Test Configuration',
'autoCreation.enabled': true,
'autoCreation.type': 'webhook',
'autoCreation.conversationServiceSid': 'ISXXXXXXXXXXXXXXXXXXXXXX',
'autoCreation.webhookUrl': 'https://example.com',
'autoCreation.webhookMethod': 'POST',
'autoCreation.webhookFilters': ['onParticipantAdded', 'onMessageAdded'],
type: 'sms',
address: '+37256123457'
})
.then(address_configuration => console.log(address_configuration.sid));
Here's the configuration of the default conversation service
I ran this code
async function _test() {
let service = await client.conversations.v1.services('IS4faafa8...').fetch();
console.log(JSON.stringify(service, null, 4));
}
to get this output (I have removed some characters from the ids for privacy reasons)
{
"accountSid": null,
"sid": "IS4faafa8.....",
"friendlyName": "Default Conversations Service",
"dateCreated": "2022-03-09T23:29:02.000Z",
"dateUpdated": "2022-07-20T17:49:19.000Z",
"url": "https://conversations.twilio.com/v1/Services/IS4faafa8.....",
"links": {
"users": "https://conversations.twilio.com/v1/Services/IS4faafa8...../Users",
"roles": "https://conversations.twilio.com/v1/Services/IS4faafa8...../Roles",
"participant_conversations": "https://conversations.twilio.com/v1/Services/IS4faafa8...../ParticipantConversations",
"conversations": "https://conversations.twilio.com/v1/Services/IS4faafa8...../Conversations",
"bindings": "https://conversations.twilio.com/v1/Services/IS4faafa8...../Bindings",
"configuration": "https://conversations.twilio.com/v1/Services/IS4faafa8...../Configuration"
}
}
Picture attached of the GUI Screen

How to make child-card Discussion notes rollup to parent card?

How to make child-card Discussion notes rollup to parent card in Azure DevOps?
The way we use ADO is like this:
User Story -> Task 1
-> Task 2
-> Task 3
Both User Story cards and Task cards contain Discussion fields, and we have hit a quandary as to "which cards' discussion fields should we use to enter ongoing notes and discussions"? The Parent (user story)? Or the child (task)? It makes more sense for devs to enter discussion notes in the tasks, but our Support people and managers like to just look at the parent User Story card where they hope to see all discussion notes.
For now I am double-entering discussion notes in both tasks and their parent user story cards, which is not only an inefficient pain, but also violates DRY.
Then it occurred to me that the ideal solution would be for user story cards to be able to display (within the Discussion section) all discussion notes from all child cards. So if I enter a note in a Task (child) card and save it, automatically it would appear as a discussion note within its parent user story card. Ideally I could still enter user-story-specific discussion notes on occasion, but all child cards' notes would be automatically pulled in and displayed (maybe readonly? editable only in the child?) in the parent card, in all cases.
Is there an easy way to make this happen?
If the answer to #1 above is no, then is there a difficult way to make it happen? Maybe via customizations or custom API calls? What would be the best way to achieve my desired result?
This is not possible out of the box in Azure DevOps (at least not to my knowledge).
However I can think of a few ways to get this done, but it requires some custom scripting, and have some drawbacks that may of may not affect your use case.
Option 1. Create a custom extension that aggregates the comments on the parent
This option gives you complete freedom of how to visually design the feature. It is also completely DRY
You can develop your own custom extension for Azure DevOps and create a dynamic section on the User Story card that pulls in the comments from all tasks.
Option 2. Setup a Web Hook for the event "Workitem commented on"
This option does is not completely DRY, but it will at least automate the copying of comments across work items.
By configuring a web hook in Azure Devops to post a json object containing information about the new comment to a REST endpoint of your choice. The payload posted looks like below.
{
"subscriptionId": "5be97cbc-ee4b-4c21-91ea-866a61d624c4",
"notificationId": 4,
"id": "fb2617ed-60df-4518-81fa-749faa6c5cd6",
"eventType": "workitem.commented",
"publisherId": "tfs",
"message": {
"markdown": "[Bug #5](http://fabrikam-fiber-inc.visualstudio.com/web/wi.aspx?pcguid=74e918bf-3376-436d-bd20-8e8c1287f465&id=5) (Some great new idea!) commented on by Jamal Hartnett."
},
"detailedMessage": {
"markdown": "[Bug #5](http://fabrikam-fiber-inc.visualstudio.com/web/wi.aspx?pcguid=74e918bf-3376-436d-bd20-8e8c1287f465&id=5) (Some great new idea!) commented on by Jamal Hartnett.\r\nThis is a great new idea"
},
"resource": {
"id": 5,
"rev": 4,
"fields": {
"System.AreaPath": "FabrikamCloud",
"System.TeamProject": "FabrikamCloud",
"System.IterationPath": "FabrikamCloud\\Release 1\\Sprint 1",
"System.WorkItemType": "Bug",
"System.State": "New",
"System.Reason": "New defect reported",
"System.CreatedDate": "2014-07-15T17:42:44.663Z",
"System.CreatedBy": {
"displayName": "Jamal Hartnett",
"url": "https://vssps.dev.azure.com/fabrikam/_apis/Identities/e5a5f7f8-6507-4c34-b397-6c4818e002f4",
"_links": {
"avatar": {
"href": "https://dev.azure.com/mseng/_apis/GraphProfile/MemberAvatars/aad.YTkzODFkODYtNTYxYS03ZDdiLWJjM2QtZDUzMjllMjM5OTAz"
}
},
"id": "e5a5f7f8-6507-4c34-b397-6c4818e002f4",
"uniqueName": "Jamal Hartnett",
"imageUrl": "https://dev.azure.com/fabrikam/_api/_common/identityImage?id=e5a5f7f8-6507-4c34-b397-6c4818e002f4",
"descriptor": "ukn.VXkweExUVXRNakV0TWpFME5qYzNNekE0TlMwNU1ETXpOak15T0RVdE56RTVNelEwTnpBM0xURXpPRGswTlRN"
},
"System.ChangedDate": "2014-07-15T17:42:44.663Z",
"System.ChangedBy": {
"displayName": "Jamal Hartnett",
"url": "https://vssps.dev.azure.com/fabrikam/_apis/Identities/e5a5f7f8-6507-4c34-b397-6c4818e002f4",
"_links": {
"avatar": {
"href": "https://dev.azure.com/mseng/_apis/GraphProfile/MemberAvatars/aad.YTkzODFkODYtNTYxYS03ZDdiLWJjM2QtZDUzMjllMjM5OTAz"
}
},
"id": "e5a5f7f8-6507-4c34-b397-6c4818e002f4",
"uniqueName": "Jamal Hartnett",
"imageUrl": "https://dev.azure.com/fabrikam/_api/_common/identityImage?id=e5a5f7f8-6507-4c34-b397-6c4818e002f4",
"descriptor": "ukn.VXkweExUVXRNakV0TWpFME5qYzNNekE0TlMwNU1ETXpOak15T0RVdE56RTVNelEwTnpBM0xURXpPRGswTlRN"
},
"System.Title": "Some great new idea!",
"System.Parent": 26
"Microsoft.VSTS.Common.Severity": "3 - Medium",
"WEF_EB329F44FE5F4A94ACB1DA153FDF38BA_Kanban.Column": "New",
"System.History": "This is a great new idea"
},
"_links": {
"self": {
"href": "http://fabrikam-fiber-inc.visualstudio.com/DefaultCollection/_apis/wit/workItems/5"
},
"workItemUpdates": {
"href": "http://fabrikam-fiber-inc.visualstudio.com/DefaultCollection/_apis/wit/workItems/5/updates"
},
"workItemRevisions": {
"href": "http://fabrikam-fiber-inc.visualstudio.com/DefaultCollection/_apis/wit/workItems/5/revisions"
},
"workItemType": {
"href": "http://fabrikam-fiber-inc.visualstudio.com/DefaultCollection/_apis/wit/ea830882-2a3c-4095-a53f-972f9a376f6e/workItemTypes/Bug"
},
"fields": {
"href": "http://fabrikam-fiber-inc.visualstudio.com/DefaultCollection/_apis/wit/fields"
}
},
"url": "http://fabrikam-fiber-inc.visualstudio.com/DefaultCollection/_apis/wit/workItems/5"
},
"resourceVersion": "1.0",
"resourceContainers": {
"collection": {
"id": "c12d0eb8-e382-443b-9f9c-c52cba5014c2"
},
"account": {
"id": "f844ec47-a9db-4511-8281-8b63f4eaf94e"
},
"project": {
"id": "be9b3917-87e6-42a4-a549-2bc06a7a878f"
}
},
"createdDate": "2022-07-03T12:30:03.0691717Z"
}
In particular you have the comment message under message, the author of the message under fields.System.ChangedBy, the date of the comment in fields.System.ChangedDate and the parent workitem id in System.Parent
Using this information your REST service that receives the json object can create a comment on the parent work item using the Comments Rest API or post an update to the workitem where you set the System.History field to the value of the comment. This also allows you to set the original comment time and author, given that the user account you use in your automation has the permission Bypass rules on work item updates granted.
Drawbacks
If tasks can be moved from one user story to another, then the task comments on the user stories need to be moved. The same idea as above can be applied to solve this. By configuring a webhook for WorkItem updated you can listen for all updates to tasks.
By fetching the previous revision (Revision is found in resource.rev) from the Revision Rest API and comparing the field System.Parent you can determine whether the task has been moved or not and add the comments to the new parent and remove them from the old.
Similarly if you want to propagate comment updates and reactions, you would need to extend the webhook functionality even further.

Can't modify user_defined context with Watson Assistant API v2

I'm trying to migrate chatbot to use newly introduced Assistant API v2.
My chatbot infrastructure includes Middleware services which modifies the context after getting the response from Watson. In some case I used to remove particular properties from the context and it worked fine. However I noticed that after migration to API v2 this approach does not work anymore as the deleted properties are somehow stored on Watson side.
For example I received following context from Watson:
{
"assistantId": "---",
"sessionId": "---",
"messageInput": {
"Text": "Some text",
"Options": {
"Debug": "true",
"ReturnContext": "true",
"Restart": "false"
}
},
"context":
{
"Global": "null",
"Skills": {
"AdditionalProperties": {
"main skill": {
"user_defined": {
"id": "23",
"description": "Dont know"
},
"system": {---}
}
}
}
}
}
Then I remove 'description' from the context and send request to Watson once more. Surprisingly 'description' is still there with the same value ('Dont know').
Possible solution would be not to remove a property but to set it's value to empty string. But even in this case my dialog does not work correctly as Watson somehow stores the point in dialog it was visiting previously (or not, these are my guesses). I assume it might be related to system.state property which stores an encoded state of the dialog (again - or not).
My question is why is dialog behaving this way?
How does it store the context information so I can't remove properties from user_defined context?
And how can I reset dialog state to initial keeping the same conversation_id (session_id)?
P.S. I'm using Watson API v2: 2020-04-01

MS Graph REST API checkout user

I've managed to successfully checkout a file using the https://graph.microsoft.com/beta/drives/{driveId}/items/{itemId}/checkout
Now, I'd like to get the information about the user, who actually perform the checkout operation.
It's possible to check if the item is locked:
https://graph.microsoft.com/beta/drives/{driveId}/items/{itemId}?select=*,publication
However, according to DOCs, publication doesn't provide information about the checked user. Without information who locked the file is the whole checkin/checkout logic is useless.
This kind of information could be retrieved via the metadata for an item in a list as demonstrated below:
https://graph.microsoft.com/beta/sites/{site-id}/lists/{list-id}/items/{item-id}?expand=fields(select=CheckoutUserLookupId)
Once you get checkout user id (CheckoutUserLookupId field) , user details could be determined via the following endpoint:
https://graph.microsoft.com/v1.0/sites/{site-id}/lists('User Information List')/items/{CheckoutUserLookupId}
where CheckoutUserLookupId is the user id from the previous request
https://graph.microsoft.com/beta/sites/{site-id}/lists/{list-id}/items/{item-id} can't work with folders.
Anyway, drive endpoint "Allows access to the list as a drive" (according to MS Graph Docs). It works with folders as expected.
So I have
get the drive-id: /sites/${siteId}/drives
list root folder: /drives/{drive-id}/items/root/children?select=name,publication
if an item is locked, it's possible to list the activity on the item:
/drives/${idObj.driveId}/items/${idObj.fileId}?select=id&expand=activities
return list of actions:
"activities": [
{
"#odata.type": "#oneDrive.activityEntity",
"#odata.id": "https://xxxxxxxxxx/v2.0/oneDrive.activityEntity2a3649d6-2xxxxx",
"#odata.editLink": "oneDrive.activityEntity2a3649d6xxxxxx",
"#sharePoint.localizedRelativeTime": "0|July 30",
"action": {
"checkout": {}
},
"actor": {
"user": {
"email": "XXX#XXX",
"displayName": "vladimir",
"self": {},
"userPrincipalName": "XXX#XXX
}
},
"id": "XXXXXXXXXXXXXX",
"times": {
"recordedTime": "2018-07-31T04:59:03Z"
}
},
although no user ID at least a have the email....

Algolia search within scope

I am trying to implement Algolia for a directory. I've created a huge index for listings with data like:
{
"id": 120,
"listing_type": "restaurant",
"location": "In example street, so so area",
"brand":{
"name": "Mc Donald's",
"image":"1130824.jpg",
"description": "Find fastest burgers and fries around. "
},
"neighbourhood":{
"name": "Downtown",
"city":{
"name": "Philadelphia",
"state": "PA"
}
},
"_tags":["burgers","fries","fast food","quick service"],
"has_deals": true,
"images":["file1.jpg","file2.jpg"],
...
}
I want to create separate pages for each city, and would like to restrict searches for that specific city. How can I achieve this?
I can find a parameter that can be added here:
var search = instantsearch({
// Replace with your own values
appId: 'xxxxxx',
apiKey: 'xxxx', // search only API key, no ADMIN key
indexName: 'listings',
urlSync: true,
searchParameters: {
hitsPerPage: 10
}
});
There are two ways to restrict a search, both based on the filters. For that you first need to add some single attribute you can filter on for the city to attributesForFaceting (in the settings, for example with the dashboard). In this case we can use neighbourhood.city.
Then in InstantSearch on your page you can add to searchParameters the value: filters: 'neighbourhood.city:Philadelphia'.
You can also use "secured API keys" to refine on this value before actually launching the page. This will prevent someone from taking that API key and searching themselves. Read more about that in the docs