add configurable validation check and warning message upon save

[ilovan]

1. user hits "save and exit" or "save"
2. "CWRC-Writer runs the validator service and if status=fail, a user gets a pop-up with "The document you want to save is not valid xml . " and two options: "Save as is" and "Fix validation first"
3. If validation status =pass , user saves without any additional prompt.

From Luciano:

We could have a setting option like this validateBeforeSave: error | warning | none
If none save w/o validation. if warning prompt a message if invalidade and give the options to save anyway. if error prompt a message and prevent from saving. (edited)
Thus each instillation can have it its own way.

[SusanBrown]

I think the setting option as suggested here is a good one, presuming that the default setting is "warning".

However, I am loathe to have a setting that simply doesn't allow someone to save a document at all if it's invalid, which is what I take "error" to be. What if they are in a hurry, for instance? And I am trying to think of how that setting could just take the user straight to the error to fix but still allow them to override the need to change it (without having to know they can do so by going into the settings). Any ideas?

[SusanBrown]

Tweaked message for "warning" mode:

The tag validator is detecting problems in your document.
Don't panic! You can save it as is, or you can try to fix it first.

Error: "[error message/s]"

Then the two button options as described above, with the second labelled "Fix tagging first".

[lucaju]

I think it really depends of the type of error, how the validador respond to the error, and if we can navigate to each place the error occurred.

I agree with Susan. As a on going work, one should be able to save the file regardless of validation error. This is precisely the reason I suggested a configurable setting for this feature. The level of strictness is defined by each installation (or maybe each project within CWRC?).

the default should indeed be “warning”.

Also. We should think about centralize these error messages. At this point, they are all over the place in the code. I have an idea on how to operationalize this. But involves localization and the redesign in react (which I know can only be done in progressive steps as we continue to solving bugs and adding features )

[SusanBrown]

And I am trying to think of how that setting could just take the user straight to the error to fix but still allow them to override the need to change it (without having to know they can do so by going into the settings). Any ideas?

I was asking about a way to try to have your "error" config option without preventing saving completely but I can't think how to do it. Can you?

Yes to trying to centralize the errors in the long run. I thought they were generated by the validator itself and that they could be used to take the user to the point in the document where the error (or first one if there are multiple ones) is.

[lucaju]

I was thinking that the config settings should be at the installation level. Or even at the level of a project admin (if possible and desired). So, the choice for saving with validation error ('error | warning | none') is at the top level. Regular users wouldn't be able to see I or change it. In fact, they will be unaware of these choices and will experience the interface as defined by the installation or project admin.

That said, 'warning' by default should work exactly as you expect:

1. Click in save should trigger the validation.
2. If no validation error, save the file.
3. If any errors, prevent saving the file and show a warning.
4. The warning would display a message indicating the validation error message (if just one) or the number of errors found.
5. And Gives the option to "fix errors" or "save as is"
6. If "save as is" ... save the file
7. If fix error: close the message, open validation panel, and navigate the cursor to the first error (assuming that the validator returns an XPath).

Does it make sense? Or I am missing something?

I just thought about the other two possibilities because it might be an option for teams that want to enforce the rule no matter what or for those that don't care about validation at all (usually at the beginning of a project, I suppose). Not sure if these are real use cases. If not, there is no point in having a config setting for that.

[lucaju]

About the centralized error message... I was referring to CWRC-Writer as a whole.

[SusanBrown]

I think that the use case outlined below will cover 95% of needs so I wouldn’t make it configurable for now unless it takes less than half an hour and even then I think we should canvas whether people would really want either of the others. On Feb 24, 2021, at 5:20 PM, Luciano Frizzera <[email protected]<mailto:[email protected]>> wrote: CAUTION: This email originated from outside of the University of Guelph. Do not click links or open attachments unless you recognize the sender and know the content is safe. If in doubt, forward suspicious emails to [email protected]<mailto:[email protected]> I was thinking that the config settings should be at the installation level. Or even at the level of a project admin (if possible and desired). So, the choice for saving with validation error ('error | warning | none') is at the top level. Regular users wouldn't be able to see I or change it. In fact, they will be unaware of these choices and will experience the interface as defined by the installation or project admin. That said, 'warning' by default should work exactly as you expect: 1. Click in save should trigger the validation. 2. If no validation error, save the file. 3. If any errors, prevent saving the file and show a warning. 4. The warning would display a message indicating the validation error message (if just one) or the number of errors found. 5. And Gives the option to "fix errors" or "save as is" 6. If "save as is" ... save the file 7. If fix error: close the message, open validation panel, and navigate the cursor to the first error (assuming that the validator returns an XPath). Does it make sense. Or I am missing something? I just thought about the other two possibilities because it might be an option for teams that want to enforce the rule no matter what or for those that don't care about validation at all (usually at the beginning of a project, I suppose). Not sure if these are real use cases. If not, there is no point in having a config setting for that. — You are receiving this because you commented. Reply to this email directly, view it on GitHub<#296 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAEFJIGR24Q6H4R7VU7IBQDTAV3T3ANCNFSM4YBLWJXQ>.