After a schedule task is added the "Full class name and assembly" field cannot be changed anymore. If you make a mistake in the name, there's not way to correct it.
Or if you want to change a task without loosing all the history there's no way you can do that.
Only option now is to remove the task and create a new one.
This field should be editable.
Ludik, I don't think I agree with this approach. I don't think there's a single place in the platform where you have a single readonly field on a form that requires you to "unlock" it before editing. Why not just have it not readonly as all other fields? If you make a mistake just correct it and nothing wrong will happen, I don't see why should we be worried about this specific case.
Vicenç - The document library module in version 6.x used a read only field for the folder root value. It required the user to click on the padlock to unlock the field. I chose to implement this because if the field was read only, then the developers did not want users to mistakenly edit that field.
If a user enters or edits the field with an invalid value, there is no option to undo or reset to default. The user will either have to restore from backup, ask on the forums for the default value, or install a default installation to get the default value.
I believe this is a decision for the product managers to make. I will upload a version of the EditSchedule files with an editable field.
I don't see any reason why this field needs to be read-only. The only reason for being read-only would be if changing the value could have some negative irreversible impact on the system. This is not the case with the typename. The typename is not a primary key nor is it even indexed. There are only two locations in code that depend on a specific typename, and both of those locations have appropriate error handling to deal with the case where the expected type doesn't exist (HostSettings.ascx.cs lines 775 & 787). This field should not be read-only or locked in any way since there is no application or database logic which relies on having this field be immutable.
Verified in Content 7.3.3 build 93