[ENHANCEMENT] Outgoing Webhook Data Improvements for better usabillity and cross language support

[chrisi51]

Issue

Current situation: in some outgoing webhooks it would make sense to provide additional data. At the moment the most activitys send data according to the card, which have changed and about the author who has changed anything. And the most information are just internal wekan ids. I don't really know what you could do with those ids but wouldn't it be better to send most flexible values?

Idea: If all possible data would be included in the outgoing webhook, everyone could make its own texts independent from language. at the moment i would have to parse the text field for getting some data, which are not provided in a single field. Also it would be much more comfortable to filter the incomming data and decide how to proceed with them.

each outgoing webhook should have following data included:

• All those ids, it allready has
• [ ] each field, which id is included should also be included with real value (cardname, listname, boardname, etc.)
• [ ] Username of the author as real names are not unique (beside the actual Fullname)
• if another user is involved like act-joinmember and act-joinassignee this user also should be mentioned with
• [ ] fullname of the joined/assigned member
• [ ] username of the joined/assigned member

Example "act-joinAssignee": current data:

• "text": "Tom Tom act-joinAssignee\nhttps://xxxxx/wekan/b/xxxxx/xxxxx/xxxxx",
• "cardId": "xxxxx",
• "listId": "xxxxx",
• "boardId": "xxxxx",
• "user": "Tom Tom",
• "card": "New Task",
• "swimlaneId": "xxxxx",
• "description": "act-joinAssignee" (btw. at least in german the act-joinAssignee text field is broken but its probably just missing in the german languagefile)

better data:

• "text": "Tom Tom act-joinAssignee\nhttps://xxxxx/wekan/b/xxxxx/xxxxx/xxxxx",
• "cardId": "xxxxx",
• "card": "New Task",
• "listId": "xxxxx",
• "list": "New Task List",
• "boardId": "xxxxx",
• "board": "New Task Board",
• "user": "Tom Tom",
• "username": "t.tom",
• "swimlaneId": "xxxxx",
• "swimlane": "New Task Swimline",
• "assignedToUser": "Paul Paul",
• "assignedToUsername": "p.paul",
• "linkToCard": "https://xxxxx/wekan/b/xxxxx/xxxxx/xxxxx",
• "description": "act-joinAssignee"

Usecase: Rocketchat informs users, when they got assigned to any task. if there was a field with the username in the corresponding activity, you could uses this field to write a message to the correct user at the moment of assignment. The script on rocketchat could be something like:

class Script {
  process_incoming_request({request}) {
    if (request.content.description == "act-joinMember") {
      return {
        content: {
          channel: "@" + request.content.assignedToUsername,
          text: "You have been added to the Task " + card + " => " + linkToCard
        }
      };
    }
  }
}

[xet7]

Do you mean, that at Wekan Board Settings / Outgoing Webhooks, each webhook should have settings about:

• What fields are included
• What language translation Outgoing Webhook should have
• Maybe some kind of Template like at Card Hamburger menu / Copy Checklist Template to Many Cards ?

[chrisi51]

that would be another way to solve this but i mean that in general there are more fields in the outgoing json so that you can use the maximum of possible information on the receiver side. The fields i've mentioned are completly missing right now. So im not talking about filtering some fields out but about putting more fields into json string.

As there was all fields in the json you could build the text - which is translated by wekan right now - in your own language or even in multiple languages on the receiver side. And the most important field which is missing in this context is the the user, who got assigned or joined to a card.

[chrisi51]

Isn't it only adding the further fields to that list? https://github.com/wekan/wekan/blob/master/server/notifications/outgoing.js#L114 Seems like https://github.com/wekan/wekan/blob/master/models/activities.js already provides all those helpers :)

i dunno how to do it on my own as i can't test it anywhere. I can't find the folder structure on my docker container to test my guesses but probably a docker install is not the best idea for developing :(

[xet7]

@chrisi51

Some developing info here: https://github.com/wekan/wekan/wiki/Emoji#1-install-git-and-configure-it

[jdaviescoates]

@chrisi51

Some developing info here: https://github.com/wekan/wekan/wiki/Emoji#1-install-git-and-configure-it

@xet7 I think that's the wrong link?

[xet7]

@jdaviescoates

That link has info how to build wekan, and submit pull request.

Other links:

• Developer Docs
• Directory Structure

After cloning Wekan repo, this way some code can be found fron non-generated directories:

cd wekan
./find.sh webhook

[xet7]

Also, you can search ChangeLog for webhook and look at related code, how some webhooks have been fixed.

Label webhooks seem to be very tricky, I have not got them working yet, it seems having them causes some parts of board being disabled.

[jdaviescoates]

@jdaviescoates

That link has info how to build wekan, and submit pull request.

Doh! I thought you meant developing info as in "there is some info about this issue developing over on this other issue" and then posted the wrong link from your clipboard by accident :laughing: but you meant "info about wekan development" - makes total sense now

[jdaviescoates]

Not sure whether or not to create a new issue for this (?) but another improvement I'd like to see is the ability to remove:

at swimlane "Default"

Because at present we're not even using swimlanes so that's just confusing for our users.

[xet7]

Here is how from environment settings is selected what data goes to webhooks: https://github.com/wekan/wekan/blob/master/server/notifications/outgoing.js#L53

Webhook messages are here: https://github.com/wekan/wekan/blob/master/i18n/en.i18n.json

These activities in this file send Outgoing Webhook messages: https://github.com/wekan/wekan/blob/master/models/activities.js#L110

[jdaviescoates]

Thanks @xet7 I'm not a developer/ code, just a user, so I'm not really sure what to do with this info, but it sounds like I should be able to edit an environment setting somewhere so that swimlane is not included, cool!

Perhaps I go over to the Cloudron forum and ask people other there how to do it (I'm running WeKan on Cloudron) :smiley:

[xet7]

Not sure whether or not to create a new issue for this (?) but another improvement I'd like to see is the ability to remove:

at swimlane "Default"

Because at present we're not even using swimlanes so that's just confusing for our users.

That is different issue, Ability to hide list/swimlane/calendar view #2107

[xet7]

Thanks @xet7 I'm not a developer/ code, just a user, so I'm not really sure what to do with this info, but it sounds like I should be able to edit an environment setting somewhere so that swimlane is not included, cool!

Perhaps I go over to the Cloudron forum and ask people other there how to do it (I'm running WeKan on Cloudron) smiley

Cloudron has same Wekan, and I really don't know are any coders on that Cloudron forum.

Really, there is not yet setting to hide Swimlane view. That issue is at #2107

[xet7]

@jdaviescoates

But but... you could try to be a developer. Some beginners have added features to Wekan successfully: https://blog.wekan.team/2018/05/wekan-v1-00-released

Just try it? ;)

[jdaviescoates]

There are quite a few coders on the Cloudron forum who have helped to package apps for Cloudron, see e.g. https://forum.cloudron.io/post/15077

But yeah, I mean I have copy/ pasted bits of code and edited bits of code in the past, and have thought about learning more, so maybe, one day...

But whilst I can see how the ability to hide swimlanes complete could also potentially also solve this issue, I'm assuming it could also be solved by having setting about what fields are included in webhooks, as you kinda sorta proposed upthread at https://github.com/wekan/wekan/issues/3297#issuecomment-706526636 - I like that idea :smiley:

[ajimix]

@xet7 this is not completed. The webhook is still missing data like for example assignedToUser, there is no way when receiving the act-joinAssignee webhook to know to who it was assigned. Can you reopen the issue?