Scheduler Class cannot be edited

Description

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.

QA Test Plan

None

Activity

Show:
Vicenç Masanas
August 31, 2014, 8:19 AM

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.

Ludik Duran
September 3, 2014, 6:10 PM

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.

Joe Brinkman
September 4, 2014, 1:18 PM

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.

Vicenç Masanas
September 4, 2014, 9:25 PM
Ken Grierson
September 13, 2014, 12:05 AM

Verified in Content 7.3.3 build 93

Complete

Assignee

Ken Grierson

Reporter

Vicenç Masanas

Story Size

Unknown

Severity

Minor

Triage

Verified

Fixed in Build

Dev Owner

None

Includes Code Fix

Yes

Documentation Required

Completed

Trouble Ticket

None

Requires More Info

None

QA Story Points

None

QA Owner

None

Injected

None

Automation Required

None

Code Review Owner

None

Components

Fix versions

Priority

Low
Configure