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


March 20, 2020 at 2:10am

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

    • reply
    • like

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

      • reply
      • like

      similarly if there is missing webhooks

        • reply
        • like
        • reply
        • like

        Or alternatively, add new settings to hide something

          • reply
          • like

          March 20, 2020 at 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.

            • reply
            • like

            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.

              • reply
              • like

              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.

                • reply
                • like

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

                  • reply
                  • like

                  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

                    • reply
                    • like

                    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

                      • reply
                      • like

                      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

                        • reply
                        • like