Join the conversation

Wekan

General

Wekan is an open-source kanban board (Trello like) which allows a card-based task and to-do management.

More active conversations

Wekan / General

Lockout this that cannot be webhooked

Wekan/General · March 19, 2020 at 7:59pm

Lockout this that cannot be webhooked

Wekan / General · March 19, 2020 at 7:59pm

When you add or delete a card, or if you add or delete a swimlane you get a webhook payload regardless of how the integration was registered. If you use universal webhooks (not the one assigned by a board specific integration) you probably get a webhook showing you created a board. Either way you do get a board deletion webhook if you built that board through the api and added an integration.

But for some reason there are NO webhooks for any changes you make. If you rename a card or rename a swimlane or rename a board, you get silence. I tried tracking and watching options and still nothing. LMK if I am doing this wrong, please.

So if I cannot track the user making changes I would need instead to prevent the user from making changes I cannot track through a web hook.

I have run into this issue editing (PUT) through the api. There are not editing functions through the api to rename some things or coloring things. Simple solution was just to change things in Mongodb to rename a board or a swimlane or card or add or change a color in a swimlane.

But the reverse is not as easy. Unless I capture changes to mongo as events there is no easy solution to not getting a webhook back on a user change of something simple. If you add card NP. if you edit a card no go.

So to lockout changes...... are there methods to do that? I see many true/false values that are in the database (no that you can always edit them through the api), but if you change mongo values you can change what the user is permitted to do in the GUI with the boards?

allowsSubtasks": true, "allowsAttachments": true, "allowsChecklists": true, "allowsComments": true, "allowsDescriptionTitle": true, "allowsDescriptionText": true, "allowsActivities": true, "allowsLabels": true, "allowsAssignee": true, "allowsMembers": true, "allowsRequestedBy": true, "allowsAssignedBy": true, "allowsReceivedDate": true, "allowsStartDate": true, "allowsEndDate": true, "allowsDueDate": true,

Can I, and if so, what do I change to prevent users from renaming things that do not give you webhooks?

Thanks

March 20, 2020 at 2:10am

Lauri Ojansivu@xet7

Team

2:10am

In Board Settings / Card Settings, you can hide some card fields like due date, checklist etc. Only Board Admin can hide those.

2:11am

If there are something missing from API, you could add that API, or pay me to add that API

2:12am

similarly if there is missing webhooks

2:13am

For limiting users, it's possible to add new roles, like I added Worker role https://github.com/wekan/wekan/issues/2788 https://github.com/wekan/wekan/commit/f6f7705f23ea18d7f1b8f8736b762eb89e00a3cf

2:13am

Or alternatively, add new settings to hide something

March 20, 2020 at 12:02pm

Paul Verdone@pvcon13

12:02pm

I am not permitted to do pull requested at this time. So "No" I can neither add settings or webhooks. I can do anything I want to Mongo through remote ssh access and that works well to add features in our prototype app to add outgoing api features missing. That as weird as it sounds works great as the changes like changeing a title or color are sort of hard to screw up.

12:03pm

But webhooks are another manner. As snapcraft deployment of Mongo is not a replicaset and not the most current version, then the propsed method of watching a collection for changes (events like editing a title) probably won't work.

12:05pm

Looking for a creative and easy answer to basically do what the app should do whihc is reflect the GUI into the api/webhook suite. Currently POST and DELETE are mostly covered, PUT in both directions are not.

Lauri Ojansivu@xet7

Team

12:05pm

How it would not work? Other webhooks work on Snap.

My goal is not to add all the missing the features in webhooks and api, but rather to not premit the user to do things that are not supported by the api/webhook

12:08pm

I am trying to keep two systems completely in sync, and if wekan cannot do everything is fine. But have a user of wekan change something to be over written by someone in the sister Main app is absurd user experience wise

12:09pm

so blocking folks from renaming boards, swimalnes and cards, or adding those to webhooks or watching moongo for collection changes all work. Leaving two system not being synched both directions means the incomplete api and webhook system means it does not have a via remote method, it doomed to be standalone

12:10pm

I cannot do a pull request by policy, but if you have any guidance on how to loack out things not supported by web hooks that solves for the moment the issue of usability

12:10pm

thanks

Lauri Ojansivu@xet7

Team

12:11pm

Well, would it help if I would add more webhook messages?

12:11pm

Or more API calls?

Paul Verdone@pvcon13

12:12pm

I have tha api side working as I said that is easy and yes eventually that makes sense but the issue is the webhooks that emulate PUTs (Board titles, Card titles, Swimlane titles). Not sure what else is needed but those are galring omissions if the user of wekan can do something not expressed in webhooks.

Edited

12:13pm

as ugly as it might sound updating a title or a color in mongo remotely is painless now that I have it working

12:14pm

looking for a way to watch mongo if there are no webhooks forediting things (PUTS)

12:14pm

so yeah if I cannot block edits and I cannot watch for mongo changes then adding the missing webhooks would be a great solution

12:14pm

thanks for any advice I can do without bothering you further

Lauri Ojansivu@xet7

Team

12:15pm

You don't bother at all

12:15pm

It's all great that someone is interested in Wekan

Paul Verdone@pvcon13

12:15pm

I think its pretty clear that tying wekan into another system needs all functions you can do on either end to comunicate bidirectioallly