Use database table tracking ODK Central XFormId (XForm name)

[spwoodcock]

Is your feature request related to a problem? Please describe.

Follow on from #1319

• We have determined that each project can have the same XForm name in the same ODK Central instance (without conflicts).
• We may have the situation where multiple FMTM instances use the same ODK Central.
  • After research, it seems to fail creating a project with the same name in ODK Central, so our FMTM workflow breaks if another instance creates a project with the same name (unlikely, but possible). Is this right @Sujanadh?
  • We need to handle this, perhaps by adding a unique identifier to the ODK Central project name?
• Equally, we may have multiple ODK Central instances used by a single FMTM instance (more likely). I can't foresee any potential issues in this case.
• We can also have multiple xFormIds (for different category forms) per project!

Describe the solution you'd like

• Possibly add a unique id to the end of the ODK Central project name, to avoid conflicts.
• We added a database table XForms, to track ODK Central xFormId's related to a project.
  • This table should be referenced throughout the code, e.g. for creating the submission JSON zip file, it should use the xFormId (which is made from {project_name}_{category}).

[manjitapandey]

@nrjadkry, @spwoodcock Can you drop some comments regarding which could be better way to move foreward?
cc: @Sujanadh

[spwoodcock]

• We have a database table XForms, that links a odk_form_id to multiple odk_form_id (xFormId).
• So whenever we create a new form in ODK Central, we should make an entry in this database table.
• Then whenever we reference the form in ODK Central, we grab the odk_form_id from this table.
• We also name the submission JSON in S3 after the xFormId too, so we should make that match odk_form_id from the database too.

[manjitapandey]

Shifting this issue to the top with @spwoodcock comment on #1418. @Sujanadh can you look this issue on parallel with #1418?

[Sujanadh]

• We have a database table XForms, that links a odk_form_id to multiple odk_form_id (xFormId).
• So whenever we create a new form in ODK Central, we should make an entry in this database table.
• Then whenever we reference the form in ODK Central, we grab the odk_form_id from this table.
• We also name the submission JSON in S3 after the xFormId too, so we should make that match odk_form_id from the database too.

i agree with that. since we have single xform id for a project, is it different from odk_form_id? Can it be multiple?
I believe you meant the form ids for the registration form and survey form.

[Sujanadh]

Shifting this issue to the top with @spwoodcock comment on #1418. @Sujanadh can you look this issue on parallel with #1418?

Yes, it also needs to be done side by side with #1326.

[Sujanadh]

@spwoodcock We have an app user(displayName) and XFormid the same; will it be the same for all the time or can it be different? I think it will create confusion. If it will be the same, then we should use the same naming convention everywhere.

[spwoodcock]

I think keeping it the same as xformid keeps things simple. So we don't also need to track the appuser name somewhere.

There will always be one appuser per form.
So if we have multiple forms for a project in future there could be multiple appusers.

[spwoodcock]

• We have a database table XForms, that links a odk_form_id to multiple odk_form_id (xFormId).
• So whenever we create a new form in ODK Central, we should make an entry in this database table.
• Then whenever we reference the form in ODK Central, we grab the odk_form_id from this table.
• We also name the submission JSON in S3 after the xFormId too, so we should make that match odk_form_id from the database too.

i agree with that. since we have single xform id for a project, is it different from odk_form_id? Can it be multiple?
I believe you meant the form ids for the registration form and survey form.

For now we will have a single xformid (odk_form_id).

Having it possible for multiple xformids per project opens up the possibility for multiple forms.

But it's not something we would support for a long while, if at all. It would need so many changes! Probably best to suggest users just make a new project per form.

[spwoodcock]

I think keeping it the same as xformid keeps things simple. So we don't also need to track the appuser name somewhere.

There will always be one appuser per form.
So if we have multiple forms for a project in future there could be multiple appusers.

If we change the appuser name, it would have to be hardcoded to something specific.

It could be something like fmtm_user_{category}

[Sujanadh]

That makes sense. Since the entity registration form name remains the same for all projects, do we have to save the entity registration form name?

And to make central project name unique, how do you think we should make it unique? by adding random characters/str or int number, or we can use timestamp? and uuid will be long for the project name.

[spwoodcock]

Should we make the xformid simply a uuid.uuid4?

The xform name can contain the project name etc (what is displayed to the user)

[spwoodcock]

And yes, the entity registration form is always the same xformid! No need to save it.

This will be removed in future anyway when creating entities is possible via the API.

[Sujanadh]

• Unable to see form questions on odk mobile #1277 i am also looking into the issue of the form not being loaded. @spwoodcock, can you give me a sight of what exactly might be the issue?

[spwoodcock]

It's fixed in #1449! 😁

[Sujanadh]

Should we make the xformid simply a uuid.uuid4?

The xform name can contain the project name etc (what is displayed to the user)

both appuser and xformid to be uuid?

[spwoodcock]

Perhaps appuser could reference FMTM so it's clear to the user: 'FMTM token {category}' ?
I don't think we need to reference the appuser name afterwards.

xFormId should be uuid though 👍