Uploaded image for project: 'Runtime'
  1. Runtime
  2. RUNTIME-1772

Why so many warnings in logs on user populations ?

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • 4.0M5
    • None
    • None
    • None

      Samples:

      Category:	org.ametys.core.user.population.UserPopulationDAO
      Message:		The parameter runtime.users.jdbc.table is not declared in extension org.ametys.plugins.core.user.directory.Ldap. It will be ignored
      Location:	org.ametys.core.user.population.UserPopulationDAO._getTypedUDParameters(UserPopulationDAO.java:523)
      
      Category:	org.ametys.core.user.population.UserPopulationDAO
      Message:		The parameter runtime.users.ldap.peopleDN is not declared in extension org.ametys.plugins.core.user.directory.Jdbc. It will be ignored
      
      Category:	org.ametys.core.user.population.UserPopulationDAO
      Message:		The parameter runtime.authentication.remote.realm is not declared in extension org.ametys.core.authentication.CAS. It will be ignored
      

          [RUNTIME-1772] Why so many warnings in logs on user populations ?

          Simon Prieul (Inactive) added a comment - - edited

          A modification in ConfigurableFormPanel#getValues led to this bug (this method now returns the values of the disabled fields)
          What's more, it was not possible to create a GroupDriven LDAP group directory due to this modification
          Because all the parameters of all the models for UD/CP/GD were sent (and some were shared)

          So we decided to prefix those parameters to make them unique before sending them to the client (and do the inverse process after receiving data from the client)

          Simon Prieul (Inactive) added a comment - - edited A modification in ConfigurableFormPanel#getValues led to this bug (this method now returns the values of the disabled fields) What's more, it was not possible to create a GroupDriven LDAP group directory due to this modification Because all the parameters of all the models for UD/CP/GD were sent (and some were shared) So we decided to prefix those parameters to make them unique before sending them to the client (and do the inverse process after receiving data from the client)

            sprieul Simon Prieul (Inactive)
            laurence Laurence Aumeunier
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: