Unable to edit task even if it said successful?

So one of my users noticed that a task cannot edit its description even though it said it was successful. Using the latest version 1.2.28 with PHP 8.1, though reverting to php 7.4 makes no difference. Commenting, creating tasks, uploading images, etc all works just fine.

Disabling all the plugins makes no difference either. The only thing I can think of is that we are storing data by mysql rather than sqlite. Last successful description edit was a month ago, and maybe? I updated kanboard at that time.

Anyone experiencing the same issue by any chance?


Apparently when adding tags, it cannot be removed either. Same with priority, cannot change it. So the entire “edit task” seems to be broken on my end.

I would check on the permissions side of things… can’t think of anything else

I use MySQL so it cant be an issue in that

Use KanboardSupport and have a look at all the php extensions, to see if the are all detected and loaded

Thanks for replying. All the extensions shown are installed.

Couldn’t be permissions (at least that’s what I assume) when creating, commenting, etc works just fine and did a month ago. I think where you are getting at though regarding alter permissions… But the sql user has full admin access to the database.

were you on server port 80 (http not https) before too when it worked?

so basically… you can create task and comments and tags, but not edit them


As for port 80… I have no idea why it’s doing that. Server side is using SSL and all 80 is forwarded to 443.

Only in v 1.2.28 is it doing this?

I was on 26 when someone discovered it. Thought an update might help, but it didn’t. I’m still looking into it to make sure it’s not the user permissions, but by default I have given the user full permissions to the database.


Ya, don’t see anything wrong with permissions either.

And you checked all your logs? No errors?

I’ve checked the logs and tried a few things prior making this thread. No errors are being generated, kanboard just said the editing comments was successful (it even relayed it to discord), and same applies to editing descriptions… It just said it was successful but nothing happened.

And what is your system cofig?

There has to be an error generated for the malfunction you are describing, so, which logs did you check?

The only way i could possibly think an error is not generated, would be related to a cache. Whether client or server.

I checked the nginx error logs, and here is the debug log on the moment I’ve already opened up the task (before editing) then enabled debug and attempted to change the description: kanboard logs - Pastebin.com , I’ve removed some csrf_key information that aren’t vital. As for the cache, I’ve changed that from memory to file, and same problem persists. And yea, the cache files are being generated.

Here’s the kanboard settings: Kanboard Config - Pastebin.com

1 Like

Im not going to pretend i have any idea whats going on, but id atleast start at the route of the issue. Check your db and see if the changes are actually happening, or just switch to sqlite and see if that works as expected. That way you can determine what to do next. If it works with sqlite, good odds something is wrong with your mysql.

1 Like

in your plugins folder, if you have old old2 or EAR… delete them and see if it makes a difference. Back them up if you know about them though… old and old2 don’t sound like plugins at all… I think they are folders in the wrong location

I used these folders to disable all plugins without actually deleting them. Don’t make a difference though.

Try to disable this. I don’t remember exactly what and where something ended in trouble with this enforcing. Nowadays, this is done by all modern browsers, AFAIK.

I don’t think kanboard can detect 443 being used as I’m using a reversed proxy. nginx → kanboard lx container). And I don’t see any SSL settings in the kanboard configuration file. As for the forward, no 80 port block is being used and the request is send to the kanboard container through proxy_pass.

its generating errors though if something is not recognised in /plugins… I woiuld suggest moving them folders out of /plugins

Fully agree. This was (one of) my idea for PluginManager: Parking plugins, to move them away temporary. :grin:

oooh that may be useful but tooooooooo complicated for me to do…