I am having the same issue, with a brand new/fresh install of OSTicket and the plugin. No errors occur (like 404), it just doesn't auto-complete, like my old install (1.12) does.

I'm looking in the System Logs in the Admin interface, and see no errors at all for it. In fact, no errors period, because it's not in production yet. I can log into SCP just fine, test users can log in just fine on the end-user page. It's just when I go to create a new ticket, and attempt to add user for ticket creation.

    KevinTheJedi

    Hey KevinTheJedi, thank you. Is there a manual way to do it though? I'm not really hip to GIT just yet, though I suppose it'd be good to learn.

        eddiebgood

        Yes, open the files in a text editor or more preferably a code editor and make the changes manually. For the plugin changes you’ll have to unpack the plugin, make the changes manually, and repackage the plugin. There are other posts and guides online that explain how to do this in PHP. There are even websites that can unpack and repackage it for you.

        Cheers.

          eddiebgood

          You can also unpack the plugin, make the changes, and leave it unpacked but it requires you to make changes in the database. If you are SQL savvy once the plugin is unpacked you can go to the database, go to the plugin table, remove the .phar from the install_path value for the LDAP plugin, set the isphar value to 0, and the plugin will work as a folder instead of a PHAR file.

          Cheers.

            4 months later

            I've running into this issue and finally stumbled across this thread.

            @KevinTheJedi I found the recommendations and followed the steps to find the plugin and instance IDs, and ran the UPDATE syntax to set the backend for the users. This fixed almost all of my users, except for 6 users. Even after running this, the backend for the remaining non-working users was set to NULL. Re-running the UPDATE still would not change the backend for those users. I had to modify the UPDATE and specifically call out their usernames to have it update the fields, but it is still not allowing them to login. I did the same for the extras as it was set to NULL as well, setting it to {"browser_lang":"en_US"} like what all of the other users have, which did not help.

            FYI, the non-working users are getting the HTTP 500 error.

            Any idea what else I can try?

              mrudella

              Check your logs for any related errors as 500 indicates deeper issues. They can also clear their cache/cookies/sessions and retry the login.

              Cheers.

                That was one of the first things that I tried during troubleshooting, but it turns out, it was an issue within the database.

                I took a closer look through the ost_user_account table and found 2 entries for each of the 6 affected users, 1 entry showing the username as their expected (just username) and the other username as their email address. For each of these, the user_id number was the same for both usernames, which I found was odd. After closer examination, I found a few non-affected users who also had 2 entries (as previously described), but the user_id was different.

                In the Staff/Agent Panel, I took a look at the User Directory and noticed that for all users with the duplicate user_id, if I clicked on their names, I would get the HTTP 500 error. In addition, if I would just hover on their name, the preview window was blank; it would not show the user or notes information.

                As a test, I deleted the id (not user_id) with the oldest timestamp for the non-working users. Once I did this, everything was fixed and the users were able to log in to create tickets. The majority of these users are also Agents, but they did not have any issues logging into that Staff panel.

                5 months later

                I have the same problem but none of the solutions works
                my user in DB is configured as this

                select * from ost_user_account;
                +----+---------+--------+---------------+------+----------+--------+------------------+-----------------------+---------------------+
                | id | user_id | status | timezone | lang | username | passwd | backend | extra | registered |
                +----+---------+--------+---------------+------+----------+--------+------------------+-----------------------+---------------------+
                | 5 | 6 | 9 | Europe/Berlin | NULL | NULL | NULL | ldap.client.p4i3 | {"browser_lang":"it"} | 2023-10-29 00:30:41 |
                +----+---------+--------+---------------+------+----------+--------+------------------+-----------------------+---------------------+

                the same user was able to login as Agent but not as client

                  alepensato

                  Are you sure that’s the correct backend? Login as a User that isn’t in osTicket yet via LDAP and then copy their backend value and update all ldap users in db to have that working backend.

                  Cheers.

                      alepensato

                      Try deleting a _user_account record associated with a user you can test with and try logging in after that.

                      Cheers.

                        I deleted it, and now i have only a record in ost_user, but i was unable to login

                        MariaDB [osticketarea]> select * from ost_user;
                        +----+--------+------------------+--------+--------------------+---------------------+---------------------+
                        | id | org_id | default_email_id | status | name | created | updated |
                        +----+--------+------------------+--------+--------------------+---------------------+---------------------+
                        | 7 | 0 | 7 | 0 | ALESSANDRO PENSATO | 2023-10-29 10:31:42 | 2023-10-29 10:31:42 |
                        +----+--------+------------------+--------+--------------------+---------------------+---------------------+

                        What does mean status values??? where is a reference to match value with description?

                          alepensato

                          The only possible value for _user.status would be this:

                          As far as where to find the description, you just have to look at the codebase and figure it out.

                          As far as the user not being able to login, have you cleared your cookies/cache for the site? Have you tried Incognito/Private/InPrivate window? Have you ensured your LDAP Plugin has Client Authentication enabled?

                          Cheers.

                              KevinTheJedi
                              I tried with different browser, computer, reinstalled osticket on brand new vmachine etc etc, ldap auth is enabled for staff ad for client, but it not works

                                  alepensato

                                  Any specific errors? Do you see the auth attempt in the AD logs? Do you have User Registration enabled in your osTicket settings (Admin Panel > Settings > Users > Registration Method)?

                                  Cheers.

                                    I do not have access to the LDAP log, but i see that the same user with same logn data can login as Aggent but not as client.

                                    Client registration mode does not change the matter, in any case, I have to manually add add user because the registration is not automatic.

                                      alepensato

                                      It should be once they login and they don’t exist or don’t have an account yet. Seems to me like you either don’t have LDAP config configured properly for Users or something is going on with your LDAP config. Are you certain you are using the latest LDAP Plugin build and v1.18.1?

                                      Cheers.

                                        Yes osticket is updated, as i wrote i also reinstalled osticked many time and used 1.17 and 1.18