akvo / akvo-flow

A data collection and monitoring tool that works anywhere.
http://akvo.org/products/akvoflow/
GNU Affero General Public License v3.0
65 stars 31 forks source link

Restrict 'Use as data point name' and 'Use as data point location' only for registration forms in monitored surveys #1319

Closed janagombitova closed 2 years ago

janagombitova commented 9 years ago

Currently the user can create a data point name based on a property in any form. However, when monitoring is enabled, with the registration form you fill in the general information that identifies the data point for later monitoring. So, the data point name should also be created from this form only.

joycarpediem commented 9 years ago

We need to make sure that as part of the this fix we do not strip the display name functionality from stand alone non - monitoring survey forms

janagombitova commented 9 years ago

As well as for data point location

iperdomo commented 9 years ago

@janagombitova @joycarpediem Not sure if is relevant, but the Use as display name for non monitoring surveys was requested in issue #735 Initially it was not possible. The changeset: https://github.com/akvo/akvo-flow/commit/24cf4db8bbf5611cb6ca9e944155a9fcb6689592

janagombitova commented 9 years ago

@iperdomo For surveys which do not have Monitoring enabled, this issue will not change anything. The user will be able to create a data point/display name (as Joy mentioned above)

In surveys which have Monitoring enabled, the user creates the data point via the registration survey, thus for me it makes sense that the display name/data point name and the data point location are created based on an answer to a question only from the registration form and not from the other forms. So we restrict the ability to create a data point name only in the registration form and not the other forms in a survey with enabled monitoring.

What we need to tackle is: That when creating forms in a survey with enabled monitoring, first the user creates the forms, defines the question (selects which question will be used for data point name) and then decides which one is the registration form.

janagombitova commented 9 years ago

@iperdomo For surveys which do not have Monitoring enables, this issue will not change anything. The user will be able to create a data point/display name (as Joy mentioned above)

In surveys which have Monitoring enabled, the user creates the data point via the registration survey, thus for me it makes sense that the display name/data point name and the data point location are created based on an answer to a question only from the registration form and not from the other forms. So we restrict the ability to create a data point name only in the registration form and not the other forms in a survey with enabled monitoring.

What we need to tackle is: @Kiarii We need to think of a good UX for this:

That when creating forms in a survey with enables monitoring, first the user creates the forms, defines the questions (selects which question will be used for data point name) and then decides which one is the registration form. What can happen is that the user assigned the data point name to a question in a non-registration form.

Suggestions:

  1. Always the first form is the registration form - as a default setting
  2. After creating a form, FLOW asks if this is the registration form or not, and then the user can start adding questions
  3. 'to be though of'
Kiarii commented 9 years ago

the suggestion above might serve the purpose - i.e. by default, every survey's first form is the data point name/registration and whatever questions correspond to this form can be added freely as needed. other forms can be added below the data point registration form irrespective of whether the survey is monitoring or not

stale[bot] commented 4 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

janagombitova commented 3 years ago

Reopening to consider under Cisco

stale[bot] commented 2 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.