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

Load previous messages

April 1, 2020 at 9:54pm

Lauri Ojansivu@xet7

Team

9:54pm

Hmm OK you mean more PUT routines

Paul Verdone@pvcon13

9:55pm

right now the attributes for things not supported in webhooks is all I need

9:55pm

anything else is great but not required

9:55pm

if I edit something in the GUI and there is no webhook then I do not have a solution to keep systems in sync

9:56pm

so the only thing essential now is to prevent users from manipulating things in the GUI that doe not webhook. Which is renaming or cards and swimlanes or Boards

9:57pm

the PUTS would be nice but I can work around that Lauri

9:58pm

Thank you again

Lauri Ojansivu@xet7

Team

10:03pm

Do you mean that webhooks for rename Board/Swimlane/Card are missing?

Paul Verdone@pvcon13

10:46pm

yup

10:46pm

no PUTs on the api side and no webhooks on the other side

10:48pm

look eventually we will have everything. but until that great day just being able to turn off users from messing with stuff we cannot track is a great solution

10:48pm

I think even if all the webhooks and PUTS were there its still powerful letting the admin or programmer decide what you can and cannot do in the GUI

you agree?

Team

Well, maybe when I figure it out. Currently that disabling does not work yet and that code is not yet in Wekan. I'm making new Wekan release with other changes that already work.

11:21pm

It depends on each day which changes and features are ready. I do release new Wekan version about once a day.

11:22pm

Or once a month, or something in between.

11:25pm

Those prevent rename changes do conflict a little with existing roles of BoardAdmin/Normal/NoComments/CommentOnly/Worker, I'll need to think how to handle those

11:25pm

One way would be to change that Roles system to have unlimited amount of roles, by adding new role names and permissions for each role

11:26pm

I have not tried implementing it yet

11:27pm

It would probably be needed with Teams/Organizations etc

Paul Verdone@pvcon13

12:21am

so the users would have a role that block certain kind of editing?

Lauri Ojansivu@xet7

Team

12:24am

Yes. All current roles are like that. Someone also requested "Read Only" role, but I have not implemented it yet.

12:25am

Current roles are described here https://github.com/wekan/wekan/wiki/REST-API-Role

Paul Verdone@pvcon13

12:57am

so you could in theory set a few roles very much alike but with very small differences and in this case on role would not be able to edit a card name.