1. Functional change perimeter:
For each prototype file, we're going to migrate we must be very carefull, most of it depends on fetchXXXX method (in Tracker_FormElement_Field_XXXX) and this method will have a direct impact on:
- Artifact copy
- Artifact Submission
- Printer version
- Modal V1 (modal to create new artifact from artifact link field)
Depending on field types, we also should keep in mind and test that following views are not impacted
- Masschange
- Modal V2 (with followup and comment => release in AD)
- Modavl V2 (without comment => add task in cardwall)
- Other plugin depending on trackers (Artifact folder, TTM, Encrypted fields...)
- cardwall and create and edit in place behaviour
2. Editable fields (order by migration complexity):
- Artifact Link
- Open List
- CrossReferences => delete cross ref && tooltip on existing ref
- TextaArea (depending on RTE migration complexity)
- FileUpload
- Permissions on artifact, computed fields
- Share field?
- int/float/string/multiselectbox, selectbox, radiobutton, checkbox
3. Identified prototype javascript scripts
4. Identified php scripts with direct javascript calls
Due to complexity of navigation in php tracker structure, I'm not confident that following list only impact artifact view and its dependencies:
- Tracker_FormElement_Field_Selectbox : fetchArtifactAdditionnalInfo && fetchSubmitAdditionnalInfo => called in modal V1
- Tracker_RuleManager: displayRulesAsJavascript => used in masschange
- Artifact.class.php : showFollowUpComments (deals at least with followup toogle, follow display, folowup headers)
- Tracker.class.php: Add create by email in toolbar if needed
- Tracker_FormElement_Field_Selectbox::displayArtifactJavascript: possible values of field (used later by field dependencies if needed)
- Tracker_RulesManager::displayRulesAsJavascript: Field dependencies rules, also probably used at field dependencies validation
- Tracker_Rule_List_View::fetchJavascript => used at least in masschange
5. As record, here is the list of artifact view files with jQuery
- TrackerEmailCopyPaste (story #6256) Add an envelop, if artifact was created by mail and enables to copy address to clipboard
- TrackerArtifactEmailActions (story #8431) Display mail header for all artifacts created by mail
- TrackerFormElementFieldPermissions.js Tracker_FormElement_Field_PermissionsOnArtifact::fetchRestrictCheckbox (see graph permissionOnArtifactRestrictCheckboxUsage)
- SubmissionKeeper.js Prevent users to submit change if he's not up-to-date
- TrackerArtifactEditionSwitcher (seems to be only used in modal V1)
- TrackerCollapseFieldset
- CopyArtifact
Conclusion of cartography
After meeting with team, we reach to following conclusion:
- Doing direclty the conversion is risky: old javascript code does not have any tests
- If we do a progressive migration, it will be painfull to have a saftey guard (rollback to old behaviour mecanism)
- ArtifactLink must be totally rework
- the rely on outdated way of render things and directly renders tracker report
- having REST routes for tracker reports, might be great but it shoudl be a dedicated epic/story, it won't be so easy
- maybe we should have the field rendering in vue
- It would be great to have all follow-up changeset in a vue app
- dynamic load, easier way to interact with users...
- if we do directly the migration, we will inherit from old code architecture, and it will not help us to have proper and easier to maintain code.
With all previous points, we reached the conclusion, that the safest and the cleanest way to rework artifact view will to start a rework from scratch of new view.
For that reason, we should wait for the modal V3 to be completely ported in VueJs