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 2, 2020 at 12:24am

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.

12:13pm

while you absorb that, I am going to read through this atmospheres.js and see how it works. Thanks again for the consideration sir

Lauri Ojansivu@xet7

Team

12:43pm

Currently all roles are combination of code + role name saved to MongoDB. Roles can be changed at web UI and REST API.

perfect :)

Thank you

Team

I don't yet know how that web UI would look like. But changing from current role system to alanning/roles would not have by itself change UI at first, it would just make possible to define more roles with REST API.

12:48pm

Hmm, would it make sense to define role permissions directly at board?

12:48pm

at Board Settings

12:48pm

actually, by clicking a board member

12:48pm

Hmm no

12:48pm

maybe by clicking role selection / settings

12:49pm

or Board Settings / Role Settings