Join the conversation

Sign in to join this conversation, and others like it, in the communities you care about.

Wekan

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

Wekan / General

Lockout this that cannot be webhooked

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:02pm

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

    • reply
    • like

    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.

      • reply
      • like

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

        • reply
        • like

        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.

          • reply
          • like

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

            • reply
            • like

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

              • reply
              • like

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

                • reply
                • like

                perfect :)

                  • reply
                  • like

                  Thank you

                    • reply
                    • like

                    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.

                      • reply
                      • like

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

                        • reply
                        • like

                        at Board Settings

                          • reply
                          • like

                          actually, by clicking a board member

                            • reply
                            • like

                            Hmm no

                              • reply
                              • like

                              maybe by clicking role selection / settings

                                • reply
                                • like

                                or Board Settings / Role Settings

                                  • reply
                                  • like

                                  Well, I'll think.

                                    • reply
                                    • like

                                    yes, either way under roles or under boards, in the api would be a great basis

                                      • reply
                                      • like

                                      for my app I would end up disabling the web ui anyway so only the api sets what can be done

                                        Edited
                                        • reply
                                        • like