Feature #1400

Require users to enter (some) types

Added by Stefan Eichert 3 months ago. Updated 16 days ago.

Target version:
Start date:
Estimated time:


In Addition to #1339 it would be very useful to allow the manager/admin to select certain fields as mandatory:
E.g. the type field in order to force users to classify the type of a certain entity.

Related issues

Follows Feature #1443: List view for entities missing a specific typeAcknowledged2021-01-11Actions



Updated by Alexander Watzinger 3 months ago

  • Subject changed from Additional module options 2 to Require users to enter (some) types

This goes against our general philosophy to not force users to enter data (except name, but this has technical reasons) to avoid receiving wrong or guessed data. The quality of data is much more important than the quantity.

E.g. if there are only unsuitable types available and the user has the role contributor (so no way to add types) there is the danger that the user just selects something to get on with it. Imagine someone enters a person with a lot of data and realizes when saving that sex is required. Do we really want to put them into the dilemma of guessing or abort data entering?

But of course we can discuss this further if needed.


Updated by Stefan Eichert 3 months ago

Thanks for the quick response!

The issues with this issue ;-) are two (+ subissues):

1. that our "classes" like place, feature, find etc. are defined by a system type.
2. The type field is a unique one for each of these entities. E.g. "Place" or subtype of "Place" for what we defined as places.
3. If the user does not enter a type, it is still a place but has no "type" that defines him as a place even though in theory it is one.
4. If you query for entities that are exactly linked to the "Place" type, you get no results.

B) As project manager with multiple users entering data it would be very beneficial if not even necessary to "force" users to add data to certain project relevant fields

So, in my opinion there are technical and practical reasons for that.


Updated by Alexander Watzinger 3 months ago

About the first issue: query. Not sure if I understand what you mean by "it is still a place but has no "type" that defines him as a place". A place has the code E53 (paired with a physical object E18) if you are interested if this is a place, feature or strategraphic unit you can look at the system type. This sounds more like a how to query question.

About the second issue, here another example:

A type is set to required but there is already existing data or data is entered through an import. So now we have entities without the type although it is required. Next things happens is a user notices an obvious spelling mistake in a name or wants to add a date to an entry not created by him/herself and wants to fix/add it quickly. Than realizes to update the entry 3 empty required types have to be filled out and no idea what they should be. So now the user has these options:
  • Ignore it and leave it as it is
  • Guess types
  • Track down the user who created the entry and discuss it with that user

None of these options support an environment where users care about each others data.

If certain types are really that important this sounds more like an issue for project management. You need project specific standards per project for data entry like e.g. which language to use which can't be enforced either and has to be done by convention.

However, this may be a topic we should discuss in the team. I'm meeting Christoph and Berni tomorrow, Thursday, and you are welcomed to join.


Updated by Alexander Watzinger 3 months ago

I now remember, we had this discussion some time ago. Please notice that there is the system type (place, feature, ...) as database field in the entity table. This is not the same as the standard type which is used in forms and can be empty.

We changed naming for all the types sometimes so that can be confusing ;)


Updated by Alexander Watzinger 2 months ago

Discussed this feature again with Stefan today and we decided to put in on the agenda for next meeting.


Updated by Alexander Watzinger 27 days ago

like already said we will discuss setting required fields at a meeting with the whole team. But I like to separate this topic from the "how to know which entity is what" question. I realized it's not that easy and not documented (except in the code itself) so I created a wiki page for that: OpenAtlas_and_CIDOC_CRM_class_mapping and hope that it helps to clear things up a little. If there are still issues with the CIDOC - OpenAtlas class mapping please open another issue for that so that we can tackle these two complex questions separately.


Updated by Alexander Watzinger 16 days ago

  • Follows Feature #1443: List view for entities missing a specific type added
  • Start date changed from 2020-10-21 to 2021-01-12

Updated by Alexander Watzinger 16 days ago

  • Target version set to Wishlist
  • Status changed from New to Acknowledged

I discussed it with team and colleagues who (very patiently) explained and convinced me about the possible usefulness of this feature. I'm still concerned about misuse of such feature which may put users in awkward situations but in the end it's another tool and how to use it lies with the project managers responsibility so I put it as acknowledged on the wishlist.

However, while discussing it some other issues got apparent like the missing functionality to see entities missing a specific type so I added #1443 as prerequisite for it.

Also available in: Atom PDF