What a Clone Deliberately Forgets
Copying a project here rebuilds the whole structure — tasks, subtasks, dependencies, milestones, checklists — and drops every date, every assignment and every trace of progress. The list of things it refuses to copy is the most opinionated thing in the module.
The best way to understand what a piece of software thinks a thing is, is to look at what it does when you ask for another one.
What survives
The shape. Every task, every subtask, every milestone, the dependencies between tasks, and the checklist items inside them.
And crucially, the relationships between them are rebuilt rather than copied. A subtask in the new project points at the new parent, not the old one. A task points at the new milestone. A dependency links the two new tasks.
That is fiddlier than it sounds and the code shows the care: tasks are deliberately processed parents before children, so that by the time a child is copied its new parent already exists to be pointed at. Get that ordering wrong and you produce a project full of subtasks hanging off tasks in a different project.
What is deliberately dropped
Start and due dates
Cleared. A copied plan has no dates until somebody decides them, which prevents a template silently carrying last year's schedule.
Baselines
Cleared. A new project has not been agreed with anybody yet, so it has nothing to have varied from.
Assignments
Cleared. The people who did it last time are not automatically the people doing it this time.
Completion
Cleared, and status reset. Checklist items come across unticked.
Sprint membership
Cleared. A sprint is a period, and periods do not repeat.
Recurrence lineage
Cleared, so a copy is not treated as another occurrence of the original.
Structure is knowledge and belongs to the template. Dates, people and progress are history and belong to the project that had them.
Why the exclusion list is the interesting half
Because every item on it is a decision, and each one prevents a specific failure that a naive copy would produce.
Carry the dates and you get a new project that appears to be six weeks overdue on the day it is created. Carry the baselines and it appears to have varied from a plan nobody agreed. Carry the assignments and somebody who left the company owns fourteen tasks. Carry the completion and half the work looks done before it has started.
None of those are hypothetical — they are the ordinary results of duplicating a record without thinking, and this codebase is unusually explicit about avoiding them. The fields are excluded at the copy and then set to null again afterwards, which is belt and braces on purpose.
What it tells you about using templates well
-
Put the knowledge in the structure, not in the dates
Task order, dependencies, milestones and checklists all survive. Anything you encode in a due date is lost, so encode duration and sequence instead.
-
Write checklists as the real institutional memory
They carry across and reset to unticked, which makes them the single most valuable thing in a template — the accumulated list of what people forgot last time.
-
Keep a template project rather than copying a live one
Copying a real project works and inherits whatever mess that project accumulated. A maintained template is a deliberate artefact and is worth the small effort.
-
Re-plan after cloning, and then set a baseline
The copy arrives with no dates by design, so planning is a required step rather than an optional one. Baseline it once the new plan is agreed.
Our position
Cloning is one of the most carefully built things in this module and it is underused. Keep a maintained template project per kind of work you repeat, put your accumulated hard-won detail into checklists and dependencies rather than into dates, and treat the empty schedule on a fresh copy as a feature — because the alternative is a project that is behind before it starts.
What AWRA OpsHub does today
- Project cloning that copies tasks, subtasks, milestones, dependencies and checklist items.
- Internal references remapped rather than copied — subtasks point at the new parent, tasks at the new milestone, dependencies at the new tasks.
- Tasks processed parents-before-children so the remap is possible at all.
- Dates, baselines, assignments, completion, sprint membership and recurrence lineage all cleared deliberately.
- Checklist items copied with their done state reset.
- A seed status applied to copied tasks rather than inheriting the original's.
What it does not do
- Any carrying of dates or durations — a clone has no schedule at all, not even relative.
- Any template concept distinct from an ordinary project. A template is a project you choose not to run.
- Cloning of time entries, expenses, purchases or issued stock — a copy has no cost history, correctly.
- Any record on the copy of which project it came from.
- Cross-tenant or partial cloning.
Not ours, by choice
- This page is largely positive because the feature is genuinely well built. The exclusion list is the sort of thing that only exists when somebody has been bitten by the alternative.
- A clone carrying no link back to its source is a small gap: there is no way to ask which projects came from a given template, and therefore no way to improve a template from how its children went.
- Nothing here is Emirati, Saudi or Qatari. The Gulf is here because repeatable fit-out, delivery and event projects are ordinary there, which is exactly the work templates are for.
What is not built for Qatar today can still be built for you
Anything described above as not built is a statement about what ships in the standard product today — not a limit on what AWRA OpsHub can do in Qatar. Kenya's eTIMS integration and its maintained payroll engine exist because Kenyan clients needed them and commissioned them; neither appeared by itself. The same door is open here. If a tax pipeline once there is one to build to, an Arabic interface, a bank or mobile money feed, a statutory return format, a rule your own operation needs that the standard one does not have, or a link to a system you already run is what stands between you and a decision, tell us and we will scope it as a build — written spec, timeline and price — before you commit to anything.
Built when Qatar publishes a specification, not before
Whatever the General Tax Authority eventually publishes — a VAT return, an electronic invoicing interface, or both — built against the actual specification rather than against a rumour of one. We are deliberately not naming a rate or a date, because Qatar has not, and a vendor pretending otherwise is telling you something about how they will handle the rest of the project. What we would do in the meantime is the readiness work that makes the build small: tax codes carried on every line at whatever rate applies today, one invoice numbering series, and a document trail that survives a change of regime.
Arabic interface, banks and acquirers
Arabic interface text with right-to-left layout and bilingual document templates, plus bank statement feeds, card acquirer settlements and payment files wired into the Payments Register so collections match invoices without anyone re-keying a statement.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
Payroll and statutory returns
A Qatari payroll engine producing wage files in the layout the Wage Protection System expects, with end-of-service gratuity accrued on live employee records rather than estimated once a year, and the Qatarisation position visible before a deadline.
Systems you already run
The accounting package, CRM, online store or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. No roadmap slide, and no pretending in a demo that something exists when it does not.
Tell us what you need integratedFour questions about duplicating a project
What does a copy NOT bring across?
A good answer sounds like
A specific list.
What it actually means
The list is the design. A vendor who says "everything" has not thought about dates.
Do subtasks point at the new parent?
A good answer sounds like
Yes, obviously.
What it actually means
Not obvious at all — it needs deliberate ordering, and a naive copy gets it wrong silently.
Do dependencies survive?
A good answer sounds like
Yes, remapped.
What it actually means
Structure without dependencies is a list. This is the difference between a template and a checklist.
Can I tell which projects came from this template?
A good answer sounds like
Yes.
What it actually means
Ours cannot. It is the gap that stops you improving a template from experience.
Put the knowledge in the checklist
It survives every copy and arrives unticked. Over a few projects it becomes the most valuable artefact your delivery team owns, and it costs nothing to build.
Talk about repeatable deliveryFrequently asked questions
Is there a separate template object?
No — a template is just a project you keep and never run. That is simpler than a separate concept and it means anything you can do to a project you can do to a template, including cloning it.
Does cloning copy costs or time?
No. A copy has no time entries, expenses, purchases or issued stock, which is correct — those are history rather than structure. It also means a clone starts with a zero actual cost, as it should.
Why are sprint memberships dropped?
Because a sprint is a period of time and periods do not repeat. Carrying it would put new tasks into a sprint that has already ended, which is one of the more confusing states a planning tool can produce.
