-
Notifications
You must be signed in to change notification settings - Fork 13
Description
Problem:
When creating a new playbook in the interface, validation errors pop up straight away. The errors point out that the created and modified timestamp fields are missing, which are required by the CACAO schema used for validation.
This is confusing and causes a few problems for users:
- The user has only just created the playbook and hasn't had a chance to sort out these 'errors'.
- They might waste time trying to fix these errors manually, but that's not possible or the intended way.
- The main issue here is that showing the playbook as 'invalid' stops users from doing the one thing (exporting) that actually fixes the problem. People are used to fixing errors before they export or save final versions. So, it's a catch-22: the fix seems wrong because of the error message, making the proper workflow hard to figure out.
- The error messages don't make it clear that these fields get filled in automatically later on during actions like exporting, signing, or SOARCA integration.
Background/Context:
Mateusz Zych explained that this behaviour is actually intentional. These created and modified timestamps are a key part of how playbook versions are tracked (playbook id + created date + modified date). To make sure versions represent distinct points in time, these timestamps are deliberately left blank while a playbook is first being created and edited.
They only get set when a proper version is generated, like during the first export. If they were set right at the start, the idea of a 'first exported version' (where created and modified times might initially match) wouldn't work properly, because any edit before exporting would change the modified date.
While the logic makes sense for versioning, it leads to a frustrating user experience. These validation errors pop up straight away for perfectly normal new playbooks, stopping users from figuring out the right way to proceed.
Proposed Solution (Agreed with Mateusz Zych via Slack):
To fix the user experience without messing with the versioning logic, Mateusz and I reckon these UI/UX tweaks should help:
-
Better Error Messages:
- The system should spot when the only errors are these missing timestamps on a playbook that hasn't been exported yet.
- Instead of the raw schema error, show a friendlier message.
- This message should explain that it's normal for these timestamps to be missing now and that they'll be added automatically on export or when the playbook is finalised (e.g., signing).
-
Change Visual Indicator:
- Maybe change the validation indicator (like the box colour) to something less scary, like orange instead of red, but only if the missing timestamps are the only problem.
- Mateusz suggested this. It would show the playbook is just in an expected temporary state, not actually broken, which might make people more comfortable hitting export.
- Mateusz pointed out that doing this (and the custom message) would mean changing the front-end code that shows the errors, rather than fiddling with the base validation schemas.
Additional Related Issue:
- Validation Status Doesn't Update After Export: I also noticed that after exporting (which does add the timestamps), the validation status in the UI doesn't refresh straight away to show it's now valid. The errors only go away if you make another change later on, which forces a re-check.
Proposed Solution (Related Issue):
- Trigger Re-validation After Export: Mateusz suggested the fix here is pretty simple: make sure the validation check runs again automatically right after the export finishes and the timestamps are added. That way, the UI should show the correct (valid) status immediately.
Goal:
Putting these changes in place should make creating and working with new playbooks a lot less confusing. Users will get clearer feedback, understand what the initial timestamp 'errors' actually mean, and be guided towards the right way to finalise and export their work.