If registration sync concepts are configured for a subject type, there is a batch job to update last modified date time for subjects of this subject type so that it will get synced to users.
Problem
Any subject type edit, even when not configuring registration sync concepts is triggering the batch job.
isSyncRegistrationConcept1Usable and isSyncRegistrationConcept2Usable are supposed to be system managed properties but are present in the external contract and writeable via them. When these are set to 'false', any update to the subject type triggers the sync attribute job and modifies last_modified_date_time for all subjects of that subject type.
The value of the 'usable' fields needs to be managed better i.e. currently false and null have the same meaning to us but cause different behaviour (point 1).
-- Solutions: Either make the fields boolean or manage the value correctly i.e. usable should always be null when there is no corresponding sync registration concept.
Logic is split across controller and service layer making it hard to write tests for.
Context
If registration sync concepts are configured for a subject type, there is a batch job to update last modified date time for subjects of this subject type so that it will get synced to users.
Problem
Any subject type edit, even when not configuring registration sync concepts is triggering the batch job.
Issues:
PUT /web/subjectType/
Investigation done as part of #686
isSyncRegistrationConcept1UsableandisSyncRegistrationConcept2Usableare supposed to be system managed properties but are present in the external contract and writeable via them. When these are set to 'false', any update to the subject type triggers the sync attribute job and modifieslast_modified_date_timefor all subjects of that subject type.