Join the conversation

Wekan

Bugs

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

More active conversations

Wekan / Bugs

Update recently? deleting

Wekan/Bugs · February 28, 2020 at 4:04pm

Update recently? deleting

Wekan / Bugs · February 28, 2020 at 4:04pm (Edited 5 years ago)

was there an update last evening or the day before?

deleting archived cards do not stay deleted. Refreshing screen and they return in the list of archived things to delete

HOW do you clear out all cards from the system not using the GUI? Its suddenly happening on all three systems with no code changes.

Can we roll back to the last version. THis is broken

other issues: when updating with new cards from the api looking at the contents of the new cards put the GUI into some sort of wait mode. Until you refresh the screen several times you get this behavior that indicates its not connecting to Mongo or something

In fact the deleting the archived boards works and on screen refresh they are still there seems like its never deleting from Mongo at all

Another hint: in addition to the GUI thinking the archived card is deleted and when you refresh its not, the webhooks are not being sent out when the delete happens. So it seems that the GUI is disconnected from the mongo and webhook piece entirely.

Question: in addition to rolling back the code, using snap installed wekan, what is the correct way to get into mongo shell under snap wekan? I can at least see what is in the database then and perhaps clear it out

LMK

more hints, I can't delete archived cards but I can restore them. When I do I cannot disable or remove webhooks associated

HOw do I get into wekan under snap mongo to clear these out?

Load previous messages

March 1, 2020 at 3:20pm

Paul Verdone@pvcon13

3:20pm

all populations are identical (create board by owner public) (add other member)( add webhook integration) (add seven list elements)( add three card elements on first list item) (build three total boards).

3:24pm

Servers receiving webhooks are on the same VPC with that port open. API receiving is the web hook in a standard manner. Testing of webhook api endpoint works 100 times in a rows with POSTMAN with same payload that comes in from the webhook. All webhooks work correctly when they fire. Firing of webhooks happen when the refresh browser shows that board has finally deleted. There are no network errors anywhere that would explain the webhook not returning. There are no activites on the receiving api endpoint of the server getting the webhook until the wekan application decides to delete that board. I have no idea if the web hooks fires first and then deletes or deletes and then fires the webhook or of they are done in parallel. But they are time synched.

3:26pm

webhook syntax is :http><ipaddress:> <port>< api endpoint>

3:27pm

NO auth is included in the webhook

3:27pm

this is a ONE way web hook (not selected two way

3:27pm

you should be able to repeat this without any more details from me

3:28pm

LMK your thoughts or if my procedure is flawed

3:28pm

Thanks again

3:31pm

as expected the first of the three boards that was attempted to be deleted with the gui is now gone on browser refresh, the other two (in order) remain

3:33pm

that single webhook fired at the same time and worked without server errors and did what it was supposed to do on my end, it deleted several database rows in two different tables ( a card table for each card - 3 rows) and a list table that for each board has a row with all list ids for that board - 7 rows)

3:37pm

going to fix that NTP issue then try and figure out when the nightly check and update that is indicates is run between 2 and 4 AM shows a change in code

3:37pm

Would like to figure out when exactly that code was changed and then if possible what the version sub id is.

3:37pm

thanks

March 1, 2020 at 4:55pm

Paul Verdone@pvcon13

4:55pm

hint: although I deleted all three boards together initially, I thought they would delete one at a time. I was incorrect. after the first one actually get deleted you have to requeue each deletion. Meaning that the second and third deletes are not in queue, they are being thrown out till the one before it goes through. So after each delayed delete actually fires you have to go back and issue a new delete request for the next one