Loading...
 
Skip to main content

Features / Usability

Forum List Topic List

 
Thread actions
Print this page
  • Print all pages

    • Using Master tracker

    Posted by nirvanesque

    Hello all!

    I am climbing my way through using Tiki (v10 to v12) and enjoying it.

    Tiki has a great variety of field types in trackers.
    Using them, we are trying to create some composite fields (similar to structures or classes) which by themselves could be used as composite data-types.

    In this regard, we were trying to understand the concept of Master Tracker. I have seen it different discussions all around the Tiki site.
    In my opinion, the master tracker (with its collection tracker fields) together with all the parameters to play around in each field could be a n-times powerful feature than a single tracker.

    • Can anyone point me to some examples, usages or use cases?
    • Or perhaps, explain to me how to realise / use this concept ?


    Thanks in advance for all your advice and help!

    Reads: 2269
    Posted by Xavier de Pedro

    Can you provide an example of master tracker from somewhere else to fit whatever you have in mind?

    (or expand you explanation of composite fields and composite data-types)

    Thanks

    Posted by nirvanesque

    Hõla Xavier !

    Thanks for your prompt reply.

    Sure I can try to give an example (though, I'm not sure if it really fits the purpose of a Master tracker - we are also trying to understand how & when to use it).

    Example: Imagine a series of projects. We are trying to work out some inheritance-type structuring as follows:

    • A project root class: They would have some fields which are generic to them: Project Name, Project Description, Project Calendar, Project Manager. These fields to be "structured" in a Master tracker.
    • Some derived classes: Each project would have some fields specific to them, depending on the project type: e.g. if it is a development project then it has a certain workflow and related fields. If it is a deployment project then it has a different workflow with other fields (and field types also). These fields to be "profiled" when we instantiate a "project item" of a certain type of project.
    • Some variable lists: There would also be fields whose number may vary with each project: Project members (names), Project documents (files), Project tasks (this is again a composite field with start date, end date, task name, task description, responsible person), ...During the lifecycle of the project, these fields-items to grow / reduce as (ordered / unordered) list or bag, .


    And of course:

    • Each project team will be classified in (one or more) user groups.
    • Using the visibility/write/create permissions a "project item" would be exposed to a particular user group (project team).
    • We would also like to combine with sheets, charts, timesheets & accounting features in Tiki, but those steps come later.


    I would like to have your thoughts and opinions on the above. Is this a right approach at all?
    Thanks in advance for all your advice and suggestions.

    Best!