BUG: -ab/-at switches set fields even if lists locked and values not in list

[Tony G]

From GH# 47 : Exchanges between 'T'ony and 'D'an:

T: Use switch "-ab foo" in a simple UDT to set the Allocated By field to foo. I didn't expect this would work when the dynamic droplist is set to "Make this list read-only". Same for -at for Allocated To.

<PERSON>foo</PERSON>
<ALLOCATEDBY/>
<ALLOCATEDBY>bar</ALLOCATEDBY>


To reproduce:

• Set the read-only option for the dynamic lists. Close/re-open TDL to refresh the INI.
• Create a simple UDT with "-ab foo" or "-at foo" as the argument.
• Select a task and click the toolbar icon to execute the UDT.

D: What behaviour are you expecting? The command silently fails or you get notified with a message box (which means translation updates)?

T: I'm very hesitant to propose anything that implies a translation effort. However a silent failure isn't good either. Please see this forum thread (http://www.codeproject.com/Articles/5371/ToDoList-An-effective-and-flexible-way-to-keep-on?msg=5112546#xx5112546xx) from just a moment ago where we're discussion switch validation and errors.

D: Cool. Have responded on CP. Simply disabling the preference is enough to circumvent this. It's not like the tasklist is readonly and it's being changed. And the person running the UDT is necessarily the person who can turn off the preference so is there really any point in writing code to enforce this?

T:As with any system where data isn't pre-validated, it allows an unexpected entry in the table of valid data. I don't think it's a big deal but the whole point of the read-only switch (to my understanding) would be to keep the fields from gathering dust - like two spellings of a person's name or initials rather than a name, etc. I'm just thinking the protection is there for a reason and we've found a way to get around it. So yes, to tie up the loose ends I don't think it should be possible to "back-door" data in, where the user explicitly says they want the data protected by setting the ini preference.

This applies to the Library too. I haven't yet integrated tasklists with their ini preferences, that's just another back-door. But I'm going to have to handle the case where a task value is outside the table in the ini when the read-only flag is set. With a flag like ObserveConfigRules, I would have to throw an exception or otherwise indicate to client-side code that an attempt to set a value is invalid.

Thoughts?