Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
APPX Source Code Control System | ||||||||
Line: 146 to 146 | ||||||||
| ||||||||
Added: | ||||||||
> > | Comments:Read what other users have said about this page or add your own comments. | |||||||
-- SteveFrizzell - 29 Oct 2007 |
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
APPX Source Code Control SystemThis page describes the Source Code Control System feature of APPX Application Design. | ||||||||
Changed: | ||||||||
< < | The Source Code Control System in APPX 5.0.1 has a variety of issues which prevent it from being used successfully. The status of the Source Code Control System has therefor been changed from "Released" to "Experimental". You should not attempt to use this feature until the issues have been resolved and the status is changed to Released. | |||||||
> > | The Source Code Control System in APPX 5.0.1 has a variety of issues which prevent it from being used successfully. The status of the Source Code Control System has therefore been changed from "Released" to "Experimental". You should not attempt to use this feature until the issues have been resolved and the status is changed to Released. | |||||||
Concepts |
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
APPX Source Code Control SystemThis page describes the Source Code Control System feature of APPX Application Design. | ||||||||
Added: | ||||||||
> > | The Source Code Control System in APPX 5.0.1 has a variety of issues which prevent it from being used successfully. The status of the Source Code Control System has therefor been changed from "Released" to "Experimental". You should not attempt to use this feature until the issues have been resolved and the status is changed to Released. | |||||||
Concepts | ||||||||
Line: 22 to 24 | ||||||||
Scope can be defined for Projects, Jobs, and Tasks. Scope can also be defined for Suites, Versions, and Applications. If you define scope for a Suite, then all projects tied to that Suite, its Versons, or its Applications will be constrained by the scope defined for the Suite. If you define scope for a specific Version of a Suite, then all projects tied to that Version or its Applications will be constrained by the scope defined for the Suite and the Version. The scope defined for a Project, Job, or Task cannot broaden the scope defined for the Suite, Version, or Application that the projected is tied to.
Notes | ||||||||
Changed: | ||||||||
< < | Notes can be attached at many different points within the structure of the source code control system. Notes can be attached to Suites, Versions, Applications, Projects, Jobs, Tasks, Scopes, and Objects. | |||||||
> > | Notes can be attached at many different points within the structure of the source code control system. Notes can be attached to Suites, Versions, Applications, Projects, Jobs, Tasks, Scopes, and Objects. | |||||||
SuitesThe APPX Source Code Control system requires suites that are to be managed must first be defined. The Suite Maintenance program can be used to enter and edit suites. | ||||||||
Line: 36 to 40 | ||||||||
Design AccessDesign access controls what level of access is allowed for the applications within a suite. Design access must be specified for each suite and is inherited by each application in the suite in the event that design access is not specified for the application or the application's version. The following design access levels are allowed: | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Scope DefaultsEach Suite must include default scope specifications indicating that all design objects are to be automatically included or excluded and which design modes are allowed for included objects. | ||||||||
Line: 86 to 91 | ||||||||
If you have set Design Access to TRACKED in any of your Suites / Versions / Applications, then the designer will have to pick a Project / Job / Task to log the activity against.
Tasks | ||||||||
Changed: | ||||||||
< < | A Task is the lowest level of work. Task are subordinate to Jobs, which are subordinate to Projects. Each Project may contain multiple Jobs, and each Job may contain multiple Tasks. If you have set Design Access to TRACKED in any of your Suites / Versions / Applications, then the designer will have to pick a Project / Job / Task to log the activity against. | |||||||
> > |
A Task is the lowest level of work. Task are subordinate to Jobs, which are subordinate to Projects. Each Project may contain multiple Jobs, and each Job may contain multiple Tasks. If you have set Design Access to TRACKED in any of your Suites / Versions / Applications, then the designer will have to pick a Project / Job / Task to log the activity against. | |||||||
Notes | ||||||||
Added: | ||||||||
> > | ||||||||
Use this option to enter or view any free form notes. Notes can be associated with Suites, Versions, Applications, Projects, Jobs, Tasks and Objects.
Bugs: | ||||||||
Line: 107 to 113 | ||||||||
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
| ||||||||
Line: 121 to 127 | ||||||||
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Enhancements:
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
-- SteveFrizzell - 29 Oct 2007 |
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
APPX Source Code Control SystemThis page describes the Source Code Control System feature of APPX Application Design. |
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
Deleted: | ||||||||
< < | ||||||||
APPX Source Code Control SystemThis page describes the Source Code Control System feature of APPX Application Design. | ||||||||
Line: 23 to 22 | ||||||||
Scope can be defined for Projects, Jobs, and Tasks. Scope can also be defined for Suites, Versions, and Applications. If you define scope for a Suite, then all projects tied to that Suite, its Versons, or its Applications will be constrained by the scope defined for the Suite. If you define scope for a specific Version of a Suite, then all projects tied to that Version or its Applications will be constrained by the scope defined for the Suite and the Version. The scope defined for a Project, Job, or Task cannot broaden the scope defined for the Suite, Version, or Application that the projected is tied to.
Notes | ||||||||
Deleted: | ||||||||
< < | ||||||||
Notes can be attached at many different points within the structure of the source code control system. Notes can be attached to Suites, Versions, Applications, Projects, Jobs, Tasks, Scopes, and Objects.
Suites | ||||||||
Line: 54 to 51 | ||||||||
The scope default values are not inherited by individual scope records when the fields are null (The fields should not be null in individual scope records.)
Scope Type | ||||||||
Deleted: | ||||||||
< < | ||||||||
Allow Add? | ||||||||
Line: 75 to 71 | ||||||||
Each Version of a Suite may have one or more Applications. The same Application may exist in more than one Version. However, a specific application/version may only be assigned to a single suite.
Application AttributesScope | ||||||||
Added: | ||||||||
> > | Scopes allow you to control what objects can be accessed as part of this Application, Suite, Task or Project. Scopes work with Design Access, and in some cases, have no meaning. For example, if Design Access is NO ACCESS, then Scope is irrelevant, since design access is prohibited. Scopes can be specified at the Suite, Version, Application, Project, Job and Task levels (highest to lowest). A scope at a lower level modifies or overrides a scope at a higher level. Scopes at the same level are combined to get a net effect. For example, you might have a Scope that allows changes to all subroutines, and another Scope that disallows changes to a specific subroutine. | |||||||
ProjectsProjects can be defined for a Suite, a Suite/Version, or for a Suite/Version/Application. Each project is identified by a 10-character Project ID. Project ID's must be unique at each Suite/Version/Application level. In other words, you can create more than one project with the same Project ID as long as the projects are defined for different Suites, Suites/Versions, and Suites/Versions/Applications. | ||||||||
Changed: | ||||||||
< < | Depending on which level a project is define, there is an implied scope constraint. For example, if a project is defined for a specific Suite/Version/Application, then that project can only apply to that specific application and version. | |||||||
> > | Depending on which level a project is defined, there is an implied scope constraint. For example, if a project is defined for a specific Suite/Version/Application, then that project can only apply to that specific application and version. | |||||||
Jobs | ||||||||
Added: | ||||||||
> > | A Job is the intermediate level of work. Jobs are subordinate to Projects. Each Project may contain multiple Jobs, and each Job may contain multiple Tasks. If you have set Design Access to TRACKED in any of your Suites / Versions / Applications, then the designer will have to pick a Project / Job / Task to log the activity against. | |||||||
Tasks | ||||||||
Added: | ||||||||
> > | A Task is the lowest level of work. Task are subordinate to Jobs, which are subordinate to Projects. Each Project may contain multiple Jobs, and each Job may contain multiple Tasks. If you have set Design Access to TRACKED in any of your Suites / Versions / Applications, then the designer will have to pick a Project / Job / Task to log the activity against. | |||||||
Notes | ||||||||
Added: | ||||||||
> > | Use this option to enter or view any free form notes. Notes can be associated with Suites, Versions, Applications, Projects, Jobs, Tasks and Objects. | |||||||
Bugs:
| ||||||||
Line: 98 to 107 | ||||||||
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
| ||||||||
Line: 112 to 121 | ||||||||
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Enhancements:
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
-- SteveFrizzell - 29 Oct 2007 | ||||||||
Added: | ||||||||
> > | ||||||||
|
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
Added: | ||||||||
> > | ||||||||
APPX Source Code Control SystemThis page describes the Source Code Control System feature of APPX Application Design. | ||||||||
Line: 6 to 7 | ||||||||
Concepts | ||||||||
Changed: | ||||||||
< < | ||||||||
> > | ||||||||
Suites / Versions / Applications | ||||||||
Changed: | ||||||||
< < | Within the source code control system, applications can be grouped by version and by suite. For example, you might define a suite for the the APPXBANG Business Applications. Within that suite, you might define three versions; a production version (00), a test version (01), and a development version (02). Each version would include the 12 applications that make up the APPXBANG Business Application suite. In this example, there would be 36 separate applications defined in the APPX Application file. An application must be defined in the APPX Application file before it can be included in a source code control system suite and version. | |||||||
> > | Within the source code control system, applications can be grouped by version and by suite. For example, you might define a suite for the the APPXBANG Business Applications. Within that suite, you might define three versions; a production version (00), a test version (01), and a development version (02). Each version would include the 12 applications that make up the APPXBANG Business Application suite. In this example, there would be 36 separate applications defined in the APPX Application file. An application must be defined in the APPX Application file before it can be included in a source code control system suite and version. | |||||||
Projects / Jobs / Tasks | ||||||||
Changed: | ||||||||
< < | Within the source code control system, development tasks are created and managed and are grouped by job and by project. Projects can be created for a Suite, a Suite/Version, or a Suite/Version/Application. | |||||||
> > | Within the source code control system, development tasks are created and managed and are grouped by job and by project. Projects can be created for a Suite, a Suite/Version, or a Suite/Version/Application. | |||||||
Scope | ||||||||
Changed: | ||||||||
< < | Scope is usually used to define the boundaries for a Project, Job, or Task. In other words, you can use scope to define which design objects are allowed to be viewed, edited, deleted, etc. when a designer is working on a specific Task. If you want to exercise precise control, scope will let you do that. For example, you could define a Task to modify the CUSTOMER MAINTENANCE input process and you could specify that only that one specific design object (CUSTOMER MAINTENANCE) is allowed to be changed and that it is not allowed to be deleted. However, on the other extreme, if you, as a project manager, don't want to control access to specific design objects, then you can simply not define a scope for a Task. | |||||||
> > | Scope is usually used to define the boundaries for a Project, Job, or Task. In other words, you can use scope to define which design objects are allowed to be viewed, edited, deleted, etc. when a designer is working on a specific Task. If you want to exercise precise control, scope will let you do that. For example, you could define a Task to modify the CUSTOMER MAINTENANCE input process and you could specify that only that one specific design object (CUSTOMER MAINTENANCE) is allowed to be changed and that it is not allowed to be deleted. However, on the other extreme, if you, as a project manager, don't want to control access to specific design objects, then you can simply not define a scope for a Task. | |||||||
Changed: | ||||||||
< < | When defining the scope for a project, job, or task it is sometimes easier to specify the exceptions. For example, you might define a scope to Exclude all design objects and then, by exception, you might define additional scope records identifying specific design objects to be included. Or, you might take the opposite approach and define a scope to Include all design objects and then, by exception, you might define additional scope records identifying specific design objects to be excluded. | |||||||
> > | When defining the scope for a project, job, or task it is sometimes easier to specify the exceptions. For example, you might define a scope to Exclude all design objects and then, by exception, you might define additional scope records identifying specific design objects to be included. Or, you might take the opposite approach and define a scope to Include all design objects and then, by exception, you might define additional scope records identifying specific design objects to be excluded. | |||||||
Changed: | ||||||||
< < | Scope can be defined for Projects, Jobs, and Tasks. Scope can also be defined for Suites, Versions, and Applications. If you define scope for a Suite, then all projects tied to that Suite, its Versons, or its Applications will be constrained by the scope defined for the Suite. If you define scope for a specific Version of a Suite, then all projects tied to that Version or its Applications will be constrained by the scope defined for the Suite and the Version. The scope defined for a Project, Job, or Task cannot broaden the scope defined for the Suite, Version, or Application that the projected is tied to. | |||||||
> > | Scope can be defined for Projects, Jobs, and Tasks. Scope can also be defined for Suites, Versions, and Applications. If you define scope for a Suite, then all projects tied to that Suite, its Versons, or its Applications will be constrained by the scope defined for the Suite. If you define scope for a specific Version of a Suite, then all projects tied to that Version or its Applications will be constrained by the scope defined for the Suite and the Version. The scope defined for a Project, Job, or Task cannot broaden the scope defined for the Suite, Version, or Application that the projected is tied to. | |||||||
Notes | ||||||||
Deleted: | ||||||||
< < | ||||||||
Changed: | ||||||||
< < | Notes can be attached at many different points within the structure of the source code control system. Notes can be attached to Suites, Versions, Applications, Projects, Jobs, Tasks, Scopes, and Objects. | |||||||
> > | Notes can be attached at many different points within the structure of the source code control system. Notes can be attached to Suites, Versions, Applications, Projects, Jobs, Tasks, Scopes, and Objects. | |||||||
Suites | ||||||||
Changed: | ||||||||
< < | The APPX Source Code Control system requires suites that are to be managed must first be defined. The Suite Maintenance program can be used to enter and edit suites. | |||||||
> > | The APPX Source Code Control system requires suites that are to be managed must first be defined. The Suite Maintenance program can be used to enter and edit suites. | |||||||
Suite AttributesSuite ID | ||||||||
Line: 37 to 38 | ||||||||
Each suite has a 30-character description.
Design Access | ||||||||
Changed: | ||||||||
< < | Design access controls what level of access is allowed for the applications within a suite. Design access must be specified for each suite and is inherited by each application in the suite in the event that design access is not specified for the application or the application's version. The following design access levels are allowed: | |||||||
> > | Design access controls what level of access is allowed for the applications within a suite. Design access must be specified for each suite and is inherited by each application in the suite in the event that design access is not specified for the application or the application's version. The following design access levels are allowed: | |||||||
| ||||||||
Changed: | ||||||||
< < | Scope Defaults | |||||||
> > | Scope Defaults | |||||||
Changed: | ||||||||
< < | Each Suite must include default scope specifications indicating that all design objects are to be automatically included or excluded and which design modes are allowed for included objects. | |||||||
> > | Each Suite must include default scope specifications indicating that all design objects are to be automatically included or excluded and which design modes are allowed for included objects. | |||||||
Changed: | ||||||||
< < | Scope Defaults must be specified for each suite and are inherited by each application in the suite in the event that scope defaults are not specified for the application or the application's version. The scope default fields provide a quick way to specify the equivalent of a scope record for the suite. | |||||||
> > | Scope Defaults must be specified for each suite and are inherited by each application in the suite in the event that scope defaults are not specified for the application or the application's version. The scope default fields provide a quick way to specify the equivalent of a scope record for the suite. | |||||||
Changed: | ||||||||
< < | Scope defined at the suite level cannot be overridden by project scope records. In other words, a project manager cannot define a project that is outside of the scope defined for the suite. | |||||||
> > | Scope defined at the suite level cannot be overridden by project scope records. In other words, a project manager cannot define a project that is outside of the scope defined for the suite. | |||||||
Changed: | ||||||||
< < | The scope default values are not inherited by individual scope records when the fields are null (The fields should not be null in individual scope records.) | |||||||
> > | The scope default values are not inherited by individual scope records when the fields are null (The fields should not be null in individual scope records.) | |||||||
Scope Type | ||||||||
Changed: | ||||||||
< < | ||||||||
> > | ||||||||
Allow Add? | ||||||||
Line: 67 to 68 | ||||||||
If checked, this option will allow objects to be changed for applications within the suite.
Versions | ||||||||
Changed: | ||||||||
< < | A Suite may have one or more Versions. For example, a suite may have a Production version, a Development version, and a Test version. Versions are identified by a two-character code. The same version code may be used in more than one suite. However, the applications for a specific version may not be assigned to more than one suite. | |||||||
> > | A Suite may have one or more Versions. For example, a suite may have a Production version, a Development version, and a Test version. Versions are identified by a two-character code. The same version code may be used in more than one suite. However, the applications for a specific version may not be assigned to more than one suite. | |||||||
Version AttributesApplications | ||||||||
Changed: | ||||||||
< < | Each Version of a Suite may have one or more Applications. The same Application may exist in more than one Version. However, a specific application/version may only be assigned to a single suite. | |||||||
> > | Each Version of a Suite may have one or more Applications. The same Application may exist in more than one Version. However, a specific application/version may only be assigned to a single suite. | |||||||
Application AttributesScopeProjects | ||||||||
Changed: | ||||||||
< < | Projects can be defined for a Suite, a Suite/Version, or for a Suite/Version/Application. Each project is identified by a 10-character Project ID. Project ID's must be unique at each Suite/Version/Application level. In other words, you can create more than one project with the same Project ID as long as the projects are defined for different Suites, Suites/Versions, and Suites/Versions/Applications. | |||||||
> > | Projects can be defined for a Suite, a Suite/Version, or for a Suite/Version/Application. Each project is identified by a 10-character Project ID. Project ID's must be unique at each Suite/Version/Application level. In other words, you can create more than one project with the same Project ID as long as the projects are defined for different Suites, Suites/Versions, and Suites/Versions/Applications. | |||||||
Changed: | ||||||||
< < | Depending on which level a project is define, there is an implied scope constraint. For example, if a project is defined for a specific Suite/Version/Application, then that project can only apply to that specific application and version. | |||||||
> > | Depending on which level a project is define, there is an implied scope constraint. For example, if a project is defined for a specific Suite/Version/Application, then that project can only apply to that specific application and version. | |||||||
JobsTasksNotesBugs:
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
| ||||||||
Line: 111 to 112 | ||||||||
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
| ||||||||
Line: 128 to 129 | ||||||||
Enhancements:
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Deleted: | ||||||||
< < | ||||||||
-- SteveFrizzell - 29 Oct 2007 | ||||||||
Deleted: | ||||||||
< < | ||||||||
|
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
Deleted: | ||||||||
< < | ||||||||
APPX Source Code Control SystemThis page describes the Source Code Control System feature of APPX Application Design. | ||||||||
Line: 124 to 123 | ||||||||
| ||||||||
Added: | ||||||||
> > |
| |||||||
Enhancements:
|
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
APPX Source Code Control System | ||||||||
Line: 117 to 117 | ||||||||
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
|
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
APPX Source Code Control System | ||||||||
Line: 25 to 25 | ||||||||
Changed: | ||||||||
< < | Notes can be attached at many different points within the structure of the source code control system. Notes can be attached to Suites, Versions, Applications, Projects, Jobs, Tasks, and Scopes. | |||||||
> > | Notes can be attached at many different points within the structure of the source code control system. Notes can be attached to Suites, Versions, Applications, Projects, Jobs, Tasks, Scopes, and Objects. | |||||||
SuitesThe APPX Source Code Control system requires suites that are to be managed must first be defined. The Suite Maintenance program can be used to enter and edit suites. | ||||||||
Line: 96 to 96 | ||||||||
| ||||||||
Added: | ||||||||
> > |
| |||||||
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
| ||||||||
Line: 110 to 112 | ||||||||
| ||||||||
Added: | ||||||||
> > |
| |||||||
Enhancements:
|
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
APPX Source Code Control System | ||||||||
Line: 97 to 97 | ||||||||
| ||||||||
Added: | ||||||||
> > |
| |||||||
Enhancements:
|
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
APPX Source Code Control System | ||||||||
Line: 68 to 68 | ||||||||
If checked, this option will allow objects to be changed for applications within the suite.
Versions | ||||||||
Changed: | ||||||||
< < | A Suite may have one or more Versions. For example, a suite may have a Production version, a Development version, and a Test version. Versions are identified by a two-character code. | |||||||
> > | A Suite may have one or more Versions. For example, a suite may have a Production version, a Development version, and a Test version. Versions are identified by a two-character code. The same version code may be used in more than one suite. However, the applications for a specific version may not be assigned to more than one suite. | |||||||
Version AttributesApplications | ||||||||
Changed: | ||||||||
< < | Each Version of a Suite may have one or more Applications. The same Application may exist in more than one Version. | |||||||
> > | Each Version of a Suite may have one or more Applications. The same Application may exist in more than one Version. However, a specific application/version may only be assigned to a single suite. | |||||||
Application AttributesScopeProjects | ||||||||
Added: | ||||||||
> > | Projects can be defined for a Suite, a Suite/Version, or for a Suite/Version/Application. Each project is identified by a 10-character Project ID. Project ID's must be unique at each Suite/Version/Application level. In other words, you can create more than one project with the same Project ID as long as the projects are defined for different Suites, Suites/Versions, and Suites/Versions/Applications. Depending on which level a project is define, there is an implied scope constraint. For example, if a project is defined for a specific Suite/Version/Application, then that project can only apply to that specific application and version. | |||||||
JobsTasksNotes |
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
APPX Source Code Control System | ||||||||
Line: 9 to 9 | ||||||||
Concepts
| ||||||||
Added: | ||||||||
> > | Within the source code control system, applications can be grouped by version and by suite. For example, you might define a suite for the the APPXBANG Business Applications. Within that suite, you might define three versions; a production version (00), a test version (01), and a development version (02). Each version would include the 12 applications that make up the APPXBANG Business Application suite. In this example, there would be 36 separate applications defined in the APPX Application file. An application must be defined in the APPX Application file before it can be included in a source code control system suite and version. | |||||||
Projects / Jobs / Tasks | ||||||||
Added: | ||||||||
> > | Within the source code control system, development tasks are created and managed and are grouped by job and by project. Projects can be created for a Suite, a Suite/Version, or a Suite/Version/Application. | |||||||
ScopeScope is usually used to define the boundaries for a Project, Job, or Task. In other words, you can use scope to define which design objects are allowed to be viewed, edited, deleted, etc. when a designer is working on a specific Task. If you want to exercise precise control, scope will let you do that. For example, you could define a Task to modify the CUSTOMER MAINTENANCE input process and you could specify that only that one specific design object (CUSTOMER MAINTENANCE) is allowed to be changed and that it is not allowed to be deleted. However, on the other extreme, if you, as a project manager, don't want to control access to specific design objects, then you can simply not define a scope for a Task. | ||||||||
Line: 18 to 22 | ||||||||
Scope can be defined for Projects, Jobs, and Tasks. Scope can also be defined for Suites, Versions, and Applications. If you define scope for a Suite, then all projects tied to that Suite, its Versons, or its Applications will be constrained by the scope defined for the Suite. If you define scope for a specific Version of a Suite, then all projects tied to that Version or its Applications will be constrained by the scope defined for the Suite and the Version. The scope defined for a Project, Job, or Task cannot broaden the scope defined for the Suite, Version, or Application that the projected is tied to.
Notes | ||||||||
Changed: | ||||||||
< < | ||||||||
> > | Notes can be attached at many different points within the structure of the source code control system. Notes can be attached to Suites, Versions, Applications, Projects, Jobs, Tasks, and Scopes. | |||||||
SuitesThe APPX Source Code Control system requires suites that are to be managed must first be defined. The Suite Maintenance program can be used to enter and edit suites. | ||||||||
Line: 84 to 91 | ||||||||
| ||||||||
Added: | ||||||||
> > |
| |||||||
Enhancements:
| ||||||||
Added: | ||||||||
> > |
| |||||||
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
APPX Source Code Control System | ||||||||
Line: 11 to 11 | ||||||||
Suites / Versions / ApplicationsProjects / Jobs / TasksScope | ||||||||
Added: | ||||||||
> > | Scope is usually used to define the boundaries for a Project, Job, or Task. In other words, you can use scope to define which design objects are allowed to be viewed, edited, deleted, etc. when a designer is working on a specific Task. If you want to exercise precise control, scope will let you do that. For example, you could define a Task to modify the CUSTOMER MAINTENANCE input process and you could specify that only that one specific design object (CUSTOMER MAINTENANCE) is allowed to be changed and that it is not allowed to be deleted. However, on the other extreme, if you, as a project manager, don't want to control access to specific design objects, then you can simply not define a scope for a Task. When defining the scope for a project, job, or task it is sometimes easier to specify the exceptions. For example, you might define a scope to Exclude all design objects and then, by exception, you might define additional scope records identifying specific design objects to be included. Or, you might take the opposite approach and define a scope to Include all design objects and then, by exception, you might define additional scope records identifying specific design objects to be excluded. Scope can be defined for Projects, Jobs, and Tasks. Scope can also be defined for Suites, Versions, and Applications. If you define scope for a Suite, then all projects tied to that Suite, its Versons, or its Applications will be constrained by the scope defined for the Suite. If you define scope for a specific Version of a Suite, then all projects tied to that Version or its Applications will be constrained by the scope defined for the Suite and the Version. The scope defined for a Project, Job, or Task cannot broaden the scope defined for the Suite, Version, or Application that the projected is tied to. | |||||||
NotesSuites | ||||||||
Line: 40 to 46 | ||||||||
The scope default values are not inherited by individual scope records when the fields are null (The fields should not be null in individual scope records.)
Scope Type | ||||||||
Added: | ||||||||
> > | ||||||||
Allow Add? |
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
APPX Source Code Control System | ||||||||
Line: 16 to 16 | ||||||||
SuitesThe APPX Source Code Control system requires suites that are to be managed must first be defined. The Suite Maintenance program can be used to enter and edit suites. | ||||||||
Changed: | ||||||||
< < | Attributes | |||||||
> > | Suite Attributes | |||||||
Suite IDEach Suite is uniquely identified by a 10-character Suite ID. | ||||||||
Line: 51 to 51 | ||||||||
Allow Chg?If checked, this option will allow objects to be changed for applications within the suite. | ||||||||
Changed: | ||||||||
< < | Versions | |||||||
> > | Versions | |||||||
A Suite may have one or more Versions. For example, a suite may have a Production version, a Development version, and a Test version. Versions are identified by a two-character code. | ||||||||
Changed: | ||||||||
< < | Applications | |||||||
> > | Version AttributesApplications | |||||||
Each Version of a Suite may have one or more Applications. The same Application may exist in more than one Version. | ||||||||
Added: | ||||||||
> > | Application Attributes | |||||||
ScopeProjectsJobs | ||||||||
Line: 73 to 75 | ||||||||
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Enhancements:
|
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
APPX Source Code Control System | ||||||||
Line: 6 to 6 | ||||||||
This page describes the Source Code Control System feature of APPX Application Design. | ||||||||
Added: | ||||||||
> > | Concepts
| |||||||
Suites | ||||||||
Changed: | ||||||||
< < | Suite ID | |||||||
> > |
The APPX Source Code Control system requires suites that are to be managed must first be defined. The Suite Maintenance program can be used to enter and edit suites.
AttributesSuite ID | |||||||
Each Suite is uniquely identified by a 10-character Suite ID. | ||||||||
Changed: | ||||||||
< < | Suite Description | |||||||
> > | Suite Description | |||||||
Each suite has a 30-character description. | ||||||||
Changed: | ||||||||
< < | Design Access | |||||||
> > | Design Access | |||||||
Design access controls what level of access is allowed for the applications within a suite. Design access must be specified for each suite and is inherited by each application in the suite in the event that design access is not specified for the application or the application's version. The following design access levels are allowed:
| ||||||||
Changed: | ||||||||
< < | Default Scope | |||||||
> > | Scope DefaultsEach Suite must include default scope specifications indicating that all design objects are to be automatically included or excluded and which design modes are allowed for included objects. Scope Defaults must be specified for each suite and are inherited by each application in the suite in the event that scope defaults are not specified for the application or the application's version. The scope default fields provide a quick way to specify the equivalent of a scope record for the suite. | |||||||
Changed: | ||||||||
< < | Each Suite must include a default scope specification indicating that all processes are to be automatically included or excluded. | |||||||
> > | Scope defined at the suite level cannot be overridden by project scope records. In other words, a project manager cannot define a project that is outside of the scope defined for the suite. | |||||||
Changed: | ||||||||
< < | Scope records defined at the suite level cannot be overridden by project scope records. In other words, a project manager cannot define a project that is outside of the scope defined for the suite. | |||||||
> > | The scope default values are not inherited by individual scope records when the fields are null (The fields should not be null in individual scope records.)
Scope Type
Allow Add? | |||||||
Changed: | ||||||||
< < | The scope default values in the suite record define the equivalent of a default scope record. They are not values that are inherited by individual scope records when the fields are null (The fields should not be null in individual scope records.)
Versions | |||||||
> > | If checked, this option will allow new objects to be added to applications within the suite.
Allow Del?If checked, this option will allow objects to be deleted from applications within the suite.Allow Chg?If checked, this option will allow objects to be changed for applications within the suite.Versions | |||||||
A Suite may have one or more Versions. For example, a suite may have a Production version, a Development version, and a Test version. Versions are identified by a two-character code. | ||||||||
Changed: | ||||||||
< < | Applications | |||||||
> > | Applications | |||||||
Each Version of a Suite may have one or more Applications. The same Application may exist in more than one Version. | ||||||||
Added: | ||||||||
> > | ScopeProjectsJobsTasksNotes | |||||||
Bugs: | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
Enhancements:
| |||||||
-- SteveFrizzell - 29 Oct 2007 | ||||||||
Added: | ||||||||
> > |
|
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
APPX Source Code Control System | ||||||||
Line: 6 to 6 | ||||||||
This page describes the Source Code Control System feature of APPX Application Design. | ||||||||
Changed: | ||||||||
< < | Application Suites | |||||||
> > | SuitesSuite IDEach Suite is uniquely identified by a 10-character Suite ID.Suite DescriptionEach suite has a 30-character description.Design AccessDesign access controls what level of access is allowed for the applications within a suite. Design access must be specified for each suite and is inherited by each application in the suite in the event that design access is not specified for the application or the application's version. The following design access levels are allowed:
| |||||||
Default Scope | ||||||||
Changed: | ||||||||
< < | Each Application suite must include a default scope specification indicating that all processes are to be automatically included or excluded. | |||||||
> > | Each Suite must include a default scope specification indicating that all processes are to be automatically included or excluded. | |||||||
Scope records defined at the suite level cannot be overridden by project scope records. In other words, a project manager cannot define a project that is outside of the scope defined for the suite. The scope default values in the suite record define the equivalent of a default scope record. They are not values that are inherited by individual scope records when the fields are null (The fields should not be null in individual scope records.) | ||||||||
Added: | ||||||||
> > | Versions | |||||||
Changed: | ||||||||
< < | ||||||||
> > | A Suite may have one or more Versions. For example, a suite may have a Production version, a Development version, and a Test version. Versions are identified by a two-character code.
ApplicationsEach Version of a Suite may have one or more Applications. The same Application may exist in more than one Version.Bugs:
| |||||||
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
APPX Source Code Control System | ||||||||
Line: 6 to 6 | ||||||||
This page describes the Source Code Control System feature of APPX Application Design. | ||||||||
Added: | ||||||||
> > | Application SuitesDefault ScopeEach Application suite must include a default scope specification indicating that all processes are to be automatically included or excluded. Scope records defined at the suite level cannot be overridden by project scope records. In other words, a project manager cannot define a project that is outside of the scope defined for the suite. The scope default values in the suite record define the equivalent of a default scope record. They are not values that are inherited by individual scope records when the fields are null (The fields should not be null in individual scope records.) | |||||||
-- SteveFrizzell - 29 Oct 2007 |
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
Added: | ||||||||
> > |
APPX Source Code Control SystemThis page describes the Source Code Control System feature of APPX Application Design. |