Feature #1400
closed
Make specific types required at data entry
Added by Stefan Eichert about 4 years ago. Updated about 2 years ago.
Description
Original request from Stefan
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.
- Manager can now set types required
- It's possible only for standard, custom and place types but not for value types or types used in relations (e.g. actor function)
- When switching to required, a warning is shown about possible data quality loss when used in combination with users that aren't allowed to add types.
- When there are untyped entries the count is shown with a notice that these than cannot be updated until this type is set.
- The user has to confirm the notices before setting a type to required
- Users with the contributor group (who cannot add types) are also informed at the tooltip of the field to talk to project management in case this puts them into an awkward situation
+1 Stefan
Updated by Alexander Watzinger about 4 years 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 about 4 years ago
Thanks for the quick response!
The issues with this issue ;-) are two (+ subissues):
A)
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 about 4 years 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 about 4 years 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 about 4 years ago
Discussed this feature again with Stefan today and we decided to put in on the agenda for next meeting.
Updated by Alexander Watzinger almost 4 years ago
Update:
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 almost 4 years ago
- Start date changed from 2020-10-21 to 2021-01-12
- Follows Feature #1443: List view for untyped entities added
Updated by Alexander Watzinger almost 4 years ago
- Status changed from New to Acknowledged
- Target version set to Wishlist
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.
Updated by Alexander Watzinger over 3 years ago
- Subject changed from Require users to enter (some) types to Make specific types required at data entry
- Description updated (diff)
- Target version changed from Wishlist to 7.1.0
Updated by Stefan Eichert over 3 years ago
Thanks for considering this. I opt for:
"Make it required only when inserting an entry so that former entries can be updated even if the required type is missing"
+1
Updated by Alexander Watzinger almost 3 years ago
- Target version changed from 7.1.0 to 7.3.0
Updated by Alexander Watzinger over 2 years ago
- Description updated (diff)
To make this requested restriction not even more cumbersome than it is has to be, we should first implement adding types dynamically from within insert/update forms (#1690).
Updated by Alexander Watzinger over 2 years ago
- Start date changed from 2021-01-12 to 2021-09-21
- Follows Feature #1690: Forms: add types dynamically added
Updated by Alexander Watzinger over 2 years ago
- Target version changed from 7.3.0 to 7.4.0
Moving to next version because of multiple missing prerequisites.
Updated by Alexander Watzinger over 2 years ago
- Target version changed from 7.4.0 to 7.7.0
Updated by Bernhard Koschiček-Krombholz about 2 years ago
- Target version changed from 7.7.0 to 7.8.0
Updated by Alexander Watzinger about 2 years ago
- Status changed from Acknowledged to In Progress
- Assignee set to Alexander Watzinger
Updated by Nina Richards about 2 years ago
When everything works as planned it would be great if required types would be on top of the types list (underneath name and alias) to make them easier to spot and fill in.
Updated by Alexander Watzinger about 2 years ago
- Description updated (diff)
- Status changed from In Progress to Closed
- It doesn't work for place types (e.g. administrative unit), I have to fix there something first. Maybe I even remove the required function from them again.
- The new functionality isn't reflected in the manual. Maybe Nina will do it but if not I will do it at the latest when releasing.
- There were some issues when updating the online THANADOS version. Presumably it was because I pulled a new version at the office of Stefan with his user last week. His user wasn't configured correctly for this kind of operation but should be fixed now. Anyway, if there are problems they might stem from this.
Updated by Alexander Watzinger about 2 years ago
It wasn't possible for me to rearrange types according to their required status like requested from Nina. If this has a higher importance I would like to ask you to make an own new issue for this. Maybe Andi can solve it.
Updated by Alexander Watzinger about 2 years ago
I was able to find and fix the issue with administrative units.
So showing untyped and entities and setting the place types as required now works too. I already pushed to the THANADOS online version but be advised: checking untyped and/or making administrative units (or historical places) takes a long time on that instance.