dhis2-devs team mailing list archive

[Halvdan Hoem Grelland <halvdanhg@xxxxxxxxx>]

Update:
Issue #1 is related to the lack of a messageconverter for string methods. Resolvable by adding a org.springframework.http.converter.StringHttpMessageConverter to the contentNegotiationManager.

#2 seems to be unrelated. Specifically 'Accept: */*' is set by default
(in the jQuery ajax call) and is not handled as expected by the
HeaderContentNegotiationStrategy (which _is_ configured). Quickfix: set
the accept-header to something compatible (which is not the wildcard
header) such as 'text/plain'.

-- 
You received this bug notification because you are a member of DHIS 2
developers, which is subscribed to DHIS.
https://bugs.launchpad.net/bugs/1341629

Title:
  Invited user registration form fails to validate + HTTP 406 on POST

Status in DHIS 2:
  In Progress

Bug description:
  These are strictly speaking two separate issues, but are somewhat
  related and both contribute to completely breaking self registration
  for invited users.

  To reproduce issue #1:

  As superuser:
  1) Go to Users -> User -> Add new
  2) Choose Action: 'email invitation to create account'
  3) Give the user a username or let the user choose one herself. Doesn't matter.
  4) Fill in email and send invite to user
  ---
  5) Follow instructions in emails and try to complete the self registration form
  ---

  Validation of supplied username (for both self-chosen or given
  usernames) fails and gives the inline message: "Please fix field" on
  the username field. This message _should_ appear on choosing a
  username which is rejected by the server, but happens no matter what
  username is chosen (or not chosen at all).

  On inspection the returned response is encoded as a string (with
  surrounding quotation marks). Issue seems to be resolvable by changing
  the returned content type to text/plain instead of application/json in
  the response method.

  ---

  To reproduce issue #2:
  1) Apply the fix described above (to allow content POST to go through).
  2) Re-do the steps of issue #1

  Server now responds with HTTP 406 on submitting the form.

  This issue seems to be resolvable by returning application/json
  instead of text/plain.

  ---
  No exceptions are thrown (clientside nor serverside) for any of these issues.
  ---

  As there seems to be some custom form validation jQuery extension
  involved, I found it best not to commit these fixes as I'm not
  entirely sure if the fix should really happen server-side. I've
  attached the diff which resolves the issues for me (implementing the
  fixes described above).

To manage notifications about this bug go to:
https://bugs.launchpad.net/dhis2/+bug/1341629/+subscriptions