👋 Thanks for opening your first issue here! If you're reporting a 🐞 bug, please make sure you include steps to reproduce it. We get a lot of issues on this repo, so please be patient and we will get back to you as soon as we can.

Hm, I'm not able to reproduce this locally. What happens if you check, save, then uncheck those options on the Security page in the admin?

This happens when I try to save any Security setting, doesn't matter if the options are checked or unchecked.
The error is not the db user(most probably), just in case, i've tried to do it on my local machine and in production. Same error even giving all permissions to db user. And the folder is with 777 permissions.

I just did a fresh install in the subdirectory. It works well if using MySQL but it has the mentioned problem when using Postgres. We wanted to use an existing server that we had but it seems like a snipe-it query is not working as intended. Tested in PostgreSQL 10.7 and PostgreSQL 12. Tried with db being hosted locally and a remote db. I'll provide more details if needed.

I just noticed, it says in the documentation that it doesn't support PostgreSQL, sorry for wasting your time. Feel free to delete the issue.

Thanks for the follow up. We don’t strictly-speaking support Postgres, but it should work. I’ll take a look and see if we’re not setting a default value for those two fields

fwiw, i've just setupped a 6.4.2 with php 8.1 on OpenBSD, using psql 16, and regular usage mostly seems to work (eg creating locations/categories/assets), but saving settings fails the same way as reported in this issue.

i've added some debug printfs to display errors, and the $setting->save call in https://github.com/snipe/snipe-it/blob/master/app/Http/Controllers/SettingsController.php#L374 fails:

 save failed: {"login_remote_user_enabled":["The login remote user enabled must be a number."],"login_common_disabled":["The login common disabled must be a number."]}

in the database, those two fields in the settings table are boolean. I'll see if i can understand where this has to be a number comes from. I've tried dropping the two (int) casts in https://github.com/snipe/snipe-it/blob/master/app/Http/Controllers/SettingsController.php#L527 but that didnt help.

what isnt really helpful is that the page only displays **Error: Please check the form below for errors ** but doesnt actually display the error message :) ok, i'll turn on the debug mode to try to understand laravel console ..

@snipe, should this issue be reopened ? (even if psql is not supported, im aware that it's a best effort target)

GitHub

snipe-it/app/Http/Controllers/SettingsController.php at master · snipe/snipe-it

A free open source IT asset/license management system - snipe/snipe-it

GitHub

snipe-it/app/Http/Controllers/SettingsController.php at master · snipe/snipe-it

A free open source IT asset/license management system - snipe/snipe-it

not knowing much about laravel/php frameworks but digging more, i'm also seeing a 500 error code if i try to save on the security settings tab with ERROR: null value in column "login_remote_user_custom_logout_url" of relation "settings" violates not-null constraint like @Eamll .

it feels strange because from my understanding of https://github.com/snipe/snipe-it/blob/master/app/Models/Setting.php#L69 those fields are 'nullable'. When i try to print the value of login_remote_user_enabled & login_common_disabled in postSettings, they're empty/undefined, so why is the framework complaining about them not being numbers, as they're nullable ?

ok, in the database, they're not..

 login_remote_user_enabled           | boolean                        |           | not null | false
 login_common_disabled               | boolean                        |           | not null | false
 login_remote_user_custom_logout_url | character varying(191)         |           | not null | ''::character varying

fiddling with the database table, i'm able to save security settings once i've removed the not null constraint

snipeit=# alter table settings alter login_remote_user_header_name drop not null; 
snipeit=# alter table settings alter login_remote_user_custom_logout_url drop not null; 

but doing the same for login_remote_user_enabled & login_common_disabled wasnt enough to fix saving settings in postSettings - it also choked on require_accept_signature being null.

so i checked for the value of $setting->login_remote_user_enabled & $setting->login_common_disabled and if they're empty i set them to 0.

with those 3 fields having their not null constraint dropped, i can save 'general settings'. but not 'branding settings'... it feels like trial-n-error to figure out which fields have wrong constraints/no proper defaults (should they come from the db ?).

GitHub

snipe-it/app/Models/Setting.php at master · snipe/snipe-it

A free open source IT asset/license management system - snipe/snipe-it

ah, and i had seen #1920, but i didn't see #7600 which is also the same symptoms, where the proposed solution is to convert the boolean columns to int2. But doing so, i'm not fully sure future database schema migrations will work...