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 10:48pm

Paul Verdone@pvcon13

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.

Lauri Ojansivu@xet7

Team

1:01am

I would change current Wekan's role system to use this package https://atmospherejs.com/alanning/roles

1:02am

And then roles could be edited on Admin Panel

1:02am

I have been thinking about it for some months

1:02am

Because it's related to Teams/Organizations

1:03am

For Teams/Organizations there is already database structure added, and some plans, but not changes to Admin Panel etc yet

April 2, 2020 at 12:01pm

Paul Verdone@pvcon13

12:01pm

ok, so the admin panel can "pre-set" the role info so that that boards later created (with members and integrations and swimlanes and cards also created) by the api will observer these roles or role limits or role adjustments?

12:02pm

If so great. If not then would the api have access to what the admin panel has?

12:04pm

the core question is once these changes are made one time to the wekan admin panel are they stateful and preserved in the db and survive reboot and that later automated processes land through the api adhere to these one time changes.

12:04pm

If not and boards created have to then have an admin go back in to change the board roles would not be useful.

12:06pm

OTOH, if these are not stateful but can be added to the mongodb directly, I can set these roles without having and api or working on the admin panel, meaning I just drop them somewhere in mongo and those roles or roles attributes or role limits stick to those members io'ed via the api at Board create time.

12:08pm

My goal is not ujltiimately drive all setup through remote conditions so users can just create/delete and move things around.