Difference between revisions of "Corrections"

Latest revision as of 08:32, 15 September 2025

Carrying out correction tasks

TOES correction

You can allocate a TOES correction task to yourself by searching for the relevant document on the Editorial Site and selecting the "Corrections" tab. Next, select the appropriate radio button ("Made by ..." or "Changes that affect ...") and then enter the affecting document details in the box below. You can add details of the correction in the “Note” box. Finally, select your details in the "Allocate to" dropdown box and click "Create task":

The task will be created by the Editorial System and you will be able to start the task from your dashboard once it becomes available. When you select the task, you will be taken to the following screen, where you will be able to download the TOES that you need to correct by selecting "Download file":

Once you have carried out the correction to the TOES, save the spreadsheet with an appropriate filename (for an example see the image below) and select "Next stage" and you will be taken to the following screen:

Browse to locate the corrected file that you saved and, once located, select that file and click "Publish", you will be taken to the following screen which you can close and you will receive an email once the task is complete:

Sometimes you might also see Stages 3 (Download Commenced Effects) and 4 (Publish Commenced Effects) on this screen. These stages are there to fix knock-on effects for commencement orders, where there are coming into force effects in the TOES for the document you are correcting. Documents that are online initial edited contain coming into force effects (against themselves) in their TOES effects, so you will often see TOES correction tasks asking to do stages 3 and 4 for these documents. You can just skip stages 3 and 4 by ticking the box in stage 3 to complete the task.

Useful information

Focusing a TOES correction to override dependencies or to reduce the size of the spreadsheet

When allocating the task, select type of effect “Made by [document]” or “Changes that affect [document]” and focus correction task by adding year and number of affected/affecting document. Remember, if an update task is in progress, a TOES correction will result in the update statuses being wiped, so you should tell the editor that this will happen and ask them to add them back in.

Useful URLs to access TOES database content

URLs to check TOES data:

https://editorial.legislation.gov.uk/changes/affected/<type>/<year>/<number>/data.xls?extended=full-with-co

https://editorial.legislation.gov.uk/changes/affecting/<type>/<year>/<number>/data.xls?extended=full-with-co&sort=affecting-year-number

Be aware that multiple affecting sub-provisions may render slightly oddly in downloaded spreadsheets

Note that multiple sub-provisions may render oddlyly when downloaded in a TOES correction spreadsheet (e.g.. “reg. 001(02)(a)reg. 001(03)(a)” rather than “reg. 001(02)(a)(03)(a)”). This happens because of the transformation of the data in the original TOES upload where it tries to work out the several affecting sub-provisions for the purposes of hyperlinks, etc. If you see this odd rendering, it usually doesn not indicate an issue. But you can double check how the affecting provision was entered in the spreadsheet uploaded in the Review Record Effects task (which you can download from the task in the Editorial System)

Need to change download URL to download regnal year Act TOES spreadsheets

Regnal year Acts (pre-1963) – spreadsheet won’t download unless you change URL to /type/year/number/ format, e.g.

   /ukpga/Vict/33-34/90

to

   /ukpga/1870/90

TOES corrections done while a connected update task is in progress will wipe update edit statuses

As mentioned in the first point above, doing a focused TOES correction task while an update task is in progress will result in the update edit statuses being wiped and they will need re-adding. So it is always a good idea to speak to the update editor if you're considering doing this.

There is only one amendment, but two different ways of looking at it: affecting and affected

You only need to correct an effect once, i.e. do not delete from one sheet and then add to another, just e.g. change the legislation number of the effect in one TOES correction sheet. The effects reside in the XML database, the donloaded spreadsheet is just a form of representation; so whether you download an effect from the PoV of the affected or from the PoV of the affecting, it is still the same effect with the same key-id number.

Dangers

Only delete rows that are completely unnecessary (NB we can’t delete whole rows from the effects confirmation sheet).

N.B. Always correct existing rows (and if necessary add in extra rows with a blank id in column A), do not delete rows and then re-add the same content. This causes issues since on upload the system thinks it is both adding and deleting an identical effect with the same id. If you wish to wipe all the effects and then re-add them, this will need to be done in 2 stages: i.e. two separate toes corrections, one task to delete the toes from the database (obviously you will to save a back up of the TOES to your PC first), followed by a second task to add them back in again.

Beware Firefox and Chrome’s caching (use the browser options to clear data before downloading spreadsheets) to avoid uploading incorrect data.

Beware copying down the key-id in column A when adding extra rows.

Correcting IFDates in TOES - remember to correct the dates of any coming into force effects too

If the IFDate entered during Initial Edit is incorrect, this results in a corresponding mistake in the coming into force effect that the Initial Edit task adds to TOES. Therefore, When we correct a start date and/or I-note via a legislation correction task, we should also correct the TOES data to make the coming into force effect right too.

Report any errors if the corrected TOES upload fails (don't reset the task)

If you get an email telling you that there has been an error when are trying to upload the corrected spreadsheet, don't reset the task - report it.

Even if the task has failed, some of the data may have uploaded successfully, which could result in ‘orphan’ data in the rdf which then looks like unapplied effects. If you reset the task, this ‘orphan’ rdf data stays there and won't ever get refreshed so will need to be corrected.

Legislation Correction

Allocating a revised legislation correction task

You can allocate a legislation correction task to yourself by searching for the relevant document on the Editorial Site and selecting the “Corrections” tab. Making sure that the “Create new legislation task” is set to “Correct Revised Legislation”, allocate the task to yourself by selecting your details in the dropdown “Allocate to” box. You can add details of the correction in the “Note” box and click “Create Task”.

Note: Make sure the document you need to correct isn’t already allocated for any preparation tasks or update (although you should be blocked from allocating it if this is the case).

The task will be created by the Editorial System and you will be able to start the task from your dashboard once it becomes available (you may need to wait a little while before it can be selected - you can refresh the screen to check if it has become available).

Once you are able to select the task from your dashboard, you will be taken to the following screen, where you should select the “Start Task” button:

You will be taken to the following screen, which shows the ToC and all the PiTs for that document:

If you need to insert or remove a whole document PiT, see the instructions below.

To continue with your correction, select the provision that you need to correct from the ToC by clicking on the “Details” button next to it, you will be taken to the following screen:

Now select the PiT you want to correct by clicking on the relevant date, if you need to correct more than one PiT, you will need to come back to this page and repeat the process for the other PITs. Do not correct the “as enacted/made” version.

Once you have selected the relevant PiT, you will be taken to the following screen:

To carry out your correction in XMetaL, select the “Checkout for edit” button and you will be able to open the provision in XMetaL in the usual way, edit the data and check it back in again. Don't forget to carry out the correction in each PiT that the amendment appears in.

Welsh revised legislation correction tasks

Please note that where you need to do a correction in Welsh legislation to add a missing effect, you may also need to correct the Welsh language version of the legislation. To do this, you would use the allocation drop down menu to select the "Correct Welsh Revised legislation" option rather than the default "Correct English Revised legislation" option.

Carrying out corrections in XMetaL

Although XML tasks appear in a PiT which accords with the start date of an effect and you can use these to access the affecting provision, the corrections tool doesn’t allow you to use them to do carry out textual amendments or insert commentary which produce system constructed annotations; you have to select the manual textual amendment or manual commentary insertion options and write out or copy and paste the annotation yourself (TIP: copy the legislation title from legislation.gov.uk).

Hyperlinks are added on check in (so long as there is no tagging in the text of the annotation): make sure you double check these and check the link URLs.

Beware editing at higher levels (remember to edit the initial RestrictStartDate version and then all subsequent/interim versions). Add ukl:P1group manually for whole provision insertions into parent – use timeline resolver at increasing levels, check post-publish and if necessary raise “latest version discrepancy” issue with TSO.

Custom affecting provision download issues – these may occur because of multiple ukl:P1s in ukl:P1group (if so, download the parent or whole document instead). Also remember workaround: add "&task=update" to URL:

e.g. https://editorial.legislation.gov.uk/uksi/2003/2275/made/data.xml?view=edit&task=update

Useful tagging

Note that sometimes you will not be able to copy and paste tagging during a correction because the target provision XML has a slightly different tagging nomenclature, either e.g. ukl:Text or leg:Text. If that happens, copy the tagging into Notepad and do a find and replace to change “ukl:” to “leg:” or vice versa.

Block repeal dots:

<ukl:P1para xmlns:ukl="http://www.legislation.gov.uk/namespaces/legislation">

<ukl:Text>. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .</leg:Text>

</ukl:P1para>

<leg:P1para xmlns:ukl="http://www.legislation.gov.uk/namespaces/legislation">

<leg:Text>. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .</leg:Text>

</leg:P1para>

Other useful information

It’s often quicker to do lots of repeals by doing the first one properly, check in and back out and then copy the commentary ref and dotty line and use that to replace the other repealed text.

Large check ins may appear to fail to check in (remote server error); where this happens, refresh preview to see if your changes do in fact appear in the provision; if so, check in from XMetaL again and it should be successful this time.

Multiple repeals of words often result in missing dotty lines after first check in; if this happens, check out and back in again and the dotty lines should appear.

When you do a manual textual repeal in corrections you will see a dialog box asking you if it is an “InlineRepeal” (this kind of repeal will produce 3 dots and ensure there are spaces before and after them); if you are deleting a block (i.e. selecting tags to repeal blocks of text), you should change this to “BlockRepeal” (which results in the block repeal dots and no spaces). Similarly with InlineAddition and BlockAddition for manual insertions re spaces.

Where an annotation has the same id in multiple versions, a change in the latest version of the provision will be registered in all earlier versions. NB if you are making a textual change in multiple versions and also want to change an annotation, you may as well wait until editing the last version to change the commentary or it will only get overwritten each time.

Inserting a new provision

When you need to insert a new provision using the Corrections Tool, removing any ids in the attributes will ensure that new ones are added on check-in. The PiT you need to carry out the insertion at should already exist in the document and you will need to check out the relevant parent at that PiT to carry out the insertion. Look out for the start date defaulting to the earliest start date of the parent whe you check it back in, and amend the restrictstartdate attribute wherever it occurs in your newly inserted provision if necessary.

Previewing corrections

Once you have completed your correction in XMetaL and checked it back in, go back to the Editorial Site and preview your amendment and check that the correction has been made.

To view the “Unpublished Version” or “Published Version” click on the relevant tab. You can also view the "Website preview" by selecting that button.

Latest version errors: When you are previewing your correction, look out for "latest version errors" where your correction, although present in the PiT you corrected, does not appear in the latest version of the provision. Always check the latest version of the provision as well as the PiT view. If you get a "latest version error" you may be able to resolve it using the timeline resolver, if not it may need to go to TSO.

Once you are satisfied that the correction has been made successfully, click on “Return to Versions” button. This will return you to the previous page and if you need to make the same or different corrections to another PIT you can select a different PIT and repeat the same steps. When you have finished correcting the provision click on “Return to ToC” button to go back to the ToC for the document.

If you have any other provisions within the document you also need to correct, you can navigate to them via the ToC and carry out your correction. When you have finished, click on the “Next stage” button.

You will be taken to the following screen:

If the correction is complete, you can click the “Publish” button. This cannot be undone and will publish the changes to the website. It will take a little time and the task will still show as in progress, pending or on hold pending until it has finished publishing. You should also get an email telling you it has published successfully. The task will also then show as completed although you may need to refresh your screen.

Once the correction has published, remember to check it on the website.

Inserting or removing PiTs

Whole document PiTs

To insert a whole doc PiT, select the “Details” button next to the legislation title at the top of the ToC

You will be taken to the following screen, where you can enter the date of the PiT you wish to insert in the box, and select the provisions that need to have that PiT (you don’t need to tick parents as well, just children), then select the “Insert PiT” button:

optional text

To remove a whole document PiT, you need to use the “Remove PiT” button for the relevant PiT in the provision timeline at the top level of the document; only use this if you do not want the PiT at all because it will remove it from the whole document.

Provision level PiTs

To insert a PiT in a provision, use the timeline resolver in the preview of that provision – note that you can only do this if there is an existing PiT at whole document level.

To remove a PiT in a provision you need to use the “Remove from PiT” button in the “To Correct” timeline for that provision:

However, if the PiT should not exist anywhere else in the document then you should remove the whole document PiT instead (see above).

Correcting incorrect IFDates in start dates and/or I-notes in a legislation correct task - remember to correct the TOES dates for any coming into force effects too

If the IFDate entered during Initial Edit is incorrect, this results in a corresponding mistake in the coming into force effect that the Initial Edit task adds to TOES. Therefore, when we correct a start date and/or I-note via a legislation correction task, we should also correct the TOES data to make the coming into force effect right too.

Applying “retrospective” amendments

Retrospective amendments usually have to be applied by means of a correction task since they do not fit into the standard update timeline. The editorial system automatically allocates an unassigned correction task for such retrospective amendments since it recognises when an unapplied effect for a particular item of legislation has been given a date earlier than the date to which that item of legislation has already been updated.

When applying effects that are deemed always to have been in force you should:

apply the effect by correction in each PiT since the affected provision came into force; and

remove the reference to the date from the annotation and replace it with the word “retrospectively” (or if appropriate use the alternative wordings as described on the Annotation Conventions page, see links below)):

Annotation Conventions - “retrospective”

Annotation Conventions - “retrospective and with effect in accordance with”

Annotation Conventions - “retrospective and with application in accordance with”

Note that we may also need to undo amendments retrospectively, as in this example, where we needed to undo the effects by 2014 c. 26, s. 94 to various provisions of 2001 c. 9 Pt. 2 retrospectively back to their effective date of 1.4.2014 in accordance with 2015 c. 33, s. 48(1):

https://www.legislation.gov.uk/ukpga/2015/33/section/48#section-48-1

We would expect this type of effect to be recorded with a bespoke “amendments and repeals by ... treated as never made” with a retrospective IF Date a Comment for Editor explaining the situation and telling the editor to put the text back to how it was before the amendment were made.

ISSUES

Beware of issue when removing a PiT at provision level: underlying data does not get removed

There is currently an issue in the Corrections Tool when we use the “Remove from PiT” button to remove a PiT at provision level. The Corrections Tool only adjusts the metadata, it does not adjust the actual underlying data of the provision (NB this is also what happens with removing a PiT using the Timeline Resolver, which also only adjusts the metadata).

This means that the provision data from the PiT you are removing will still be visible at interim later PiTs (i.e. if you view the provision from a higher level at a later PiT).

To get around this issue, we need to replace the XML of the provision at the PiT you are removing with the data for that provision from previous PiT before you use the “Remove from PiT” button to remove the PiT. You can either correct the XML yourself to remove any amendments and put it back to how it was at the previous PiT, or you can copy and paste the data from the previous PiT – being careful to copy over the text only (whichever is the easiest way to make that version look like the previous version is acceptable). This means that the data from the previous PiT will be carried forward into future interim PiTs, rather than the data for the PiT you are removing.

Beware of losing further commencement details at later PiTs when you check out a provision at the first PiT that an effect is partially commenced

Be careful if you are checking out an earlier PiT of a provision containing effects that are partially commenced for the first time at that PiT, which get further commenced at later PiTs. The annotations for those further commencements at the later PiTs may get overwritten and lose the further commencement details that were added via auto-annotation tasks at those later PiTs (even if your correction has nothing to do with them), for example from:

Words in s. 3A(1) substituted (1.7.2012 for specified purposes, 22.11.2012 in so far as not already in force) by Localism Act 2011 (c. 20), s. 240(2), Sch. 4 para. 4(2)(a); S.I. 2012/1463, art. 5(a) (with arts. 6, 7) (as amended (3.7.2012) by S.I. 2012/1714, art. 2); S.I. 2012/2913, arts. 1(2), 2(b) (with arts. 3-6)

To:

Words in s. 3A(1) substituted (1.7.2012 for specified purposes) by Localism Act 2011 (c. 20), s. 240(2), Sch. 4 para. 4(2)(a); S.I. 2012/1463, art. 5(a) (with arts. 6, 7) (as amended (3.7.2012) by S.I. 2012/1714, art. 2)

At the moment, the only solution is to add those details back in again to the annotations at the later PiTs where they have been lost.

Beware when doing high level corrections on older Acts edited on SLD

Older Acts that were edited on SLD may have an issues where amendments made across several dated versions of certain provisions only appear in the “latest version” of those provision, but they do not appear in the actual dated versions themselves.

It turns out that this issue is caused by a combination of (1) the difference between how SLD dealt with start dates (it populated them in a hierarchy from the top downwards and didn’t always add start dates on higher levels) and how the editorial system deals with them (from the bottom upwards, adding a start date in all levels), and (2) the fact that the legislation correction tool still seems to cope unsatisfactorily with that difference.

TSO have run a query and there are about 2,800 Acts that were edited originally on SLD where this may be a potential issue. This doesn’t mean that all those documentss actually have issues, they are just potentially liable to suffering the same fate if we do a high level correction without first running the high level fragment through the timeline resolver to resolve the problematic start dates from sld.

So, if you’re doing a legislation correction on a document that has undergone OFFLINE UPDATE (which you can see by looking at the update overview page on editorial, but the list is also attached above) and you want to do a correction which involves checking out a higher level fragment (i.e. cross-heading or above), then please be sure to use the website preview first, before doing your correction, to view the higher level fragment, go back through its dated versions in the timeline and use the timeline resolver button to resolves its start dates. This should prevent the issue from occurring.

Please also LOOK OUT for dated versions of provisions which do not contain any amendments and compare them with their latest version. If the latest version does contain amendments but the dated versions do not, then this is an issue and we need to raise a story for TSO to fix it using the backup date from the archives.

Remember to check ancestor and descendant fragments after publication

Check that all changes carry through to the website through all ancestor and descendant fragments, in the best collection (no date in the URL), the corrected PiT (PiT’s date in the URL) and intermediate PiTs (dates after the PiT you’ve edited but before the next PiT on the timeline of the fragment you’re looking at – just change the date in the URL to advance one day). Once published, just look around what you’ve changed – side to side temporally (including intermediate PiTs) and up and down to parents and children.

Correction Slip Project 2

Corrections slips are issued by Departments in consultation with the SI Registrar to correct errors in legislation.

When they are issued, TSO add the correction slip pdf to the document on legislation.gov.uk under More Resources and they carry through the correction in the made/as enacted version.

If there is a revised version of the document, we need to carry through the correction in all relevant revised versions of the corrected legislation ourselves.

We also need to check if the correction “knocks on” to revised versions of any legislation which is affected by the corrected document (i.e. if it is a correction to an amendment) and, if necessary, do a further correction.

We may also need to correct our TOES data.

Simon and Hoda have come up with a list of docs which have had correction slips added to them on leg.gov.

This information is on the corrections allocation spreadsheet here:

https://docs.google.com/spreadsheets/d/1P_F-xbWeOPWVCNO9md5c-2mPAsTscFuVJsOBe_sjt-k/edit?usp=sharing

Checkers

In essence, you are checking the documents to find out the following:

Has the made version been corrected?

Have the revised versions (if there are any) been corrected?

If the provision is an amending provision, does the TOES data need to be corrected?

If the amendment by the provision has been applied, does the “knock on” affected legislation need to be corrected?

Method

You need to select the next doc from the list and look at its correction slip or slips (if there is more than one) on leg.gov. Add your name against the doc.

If there is no revised version, check that the correction has been correctly applied to the text of the made/as enacted version. If it has, no further action is need so add a comment and mark the doc with an N in “Action needed?” column.

If it hasn’t, add a comment so say the made version needs to be corrected by TSO and mark it with a Y in the “Action needed?” column.

If there are revised versions, after checking the made version check the revised versions to make sure the correction also appears there. If it does, no further action is required so add a comment and mark it with an N.

If one or all revised versions have not been corrected, then add a comment to say what needs to be done and mark it with a Y.

If the provision is an amending provision you will need to check that the TOES data is correct. You can do this by using this url to download the affecting TOES data for the doc from the database:

https://editorial.legislation.gov.uk/changes/affecting/<type>/<year>/<number>/data.xls?extended=full-with-co&sort=affecting-year-number

e.g. https://editorial.legislation.gov.uk/changes/affecting/uksi/2019/588/data.xls?extended=full-with-co&sort=affecting-year-number

If the TOES data need to be corrected (e.g. the affected provision or sub-provision has the wrong number/s or the affected legislation number is wrong or the type of effect needs to be changed), add a comment saying what needs to be done and mark it with a Y.

You will then need to visit the affected provision (i.e the provision that has been hit by the now-changed amending provision) on leg.gov to see if the text of that amendment is correct. If it needs to be corrected, add a comment to say what needs to be done and mark your doc with a Y.

Then move on to the next doc on the list. And so on, till we have checked the whole list …

Reviewers

Reviewers should check the list and look for docs marked with a Y in the “Action needed?” column.

They should then check what needs to be done by looking at the checker’s comments and comparing it with the correction slip/s and take the appropriate action.

As required, the reviewer should:

Raise a publishing support call with TSO if the made version needs correction (or ask their line manager to do this).
Do a legislation correction to correct any revised versions which need correction.
If necessary, do a TOES correction to correct the TOES data.
If necessary, raise a legislation correction to correct the affected “knock on” doc hit by the now-corrected affecting provision.

Once everything has been corrected, the reviewer should mark the doc with a Y to say that all actions have been completed and put their initials next to it.

Then move on to the next doc which requires action …

Example: S.I. 2020/1504

https://www.legislation.gov.uk/uksi/2020/1504/contents

3 correction slips:

1. March 2021

https://www.legislation.gov.uk/uksi/2020/1504/pdfs/uksics_20201504_en_001.pdf

2. September 2021

https://www.legislation.gov.uk/uksi/2020/1504/pdfs/uksics_20201504_en_002.pdf

3. January 2024

https://www.legislation.gov.uk/uksi/2020/1504/pdfs/uksics_20201504_en_003.pdf

The first two slips dated 2021 had been applied already in the made and revised versions:

Correction by slip 1 - https://www.legislation.gov.uk/uksi/2020/1504/regulation/17/made

Correction by slip 2 - https://www.legislation.gov.uk/uksi/2020/1504/regulation/3/made

The provision amended by reg. 17(21) is correctly showing as s. 420A, so the correction by correction slip 1 had been carried through correctly:

https://www.legislation.gov.uk/uksi/2019/705/regulation/420A

However, the TOES data for the (unapplied) amendment by reg. 3(12) had not been corrected to s. 0042B as per correction slip 2, dated September 2021:

https://editorial.legislation.gov.uk/changes/affecting/uksi/2020/1504/data.xls?extended=full-with-co&sort=affecting-year-number

So, the checker here added a Y in “Action needed?” column and a comment to say: “TOES correction needed - affected prov should be s. 42B for effect by reg. 3(12)”

Also, although the correction slip dated January 2024 (correction slip 3) had been applied to the made version:

https://www.legislation.gov.uk/uksi/2020/1504/regulation/6/made

It had not been applied to the revised version and reg. 6(4)(a) still said “in Part 1, in paragraph 7” rather than “paragraph 6”:

This info was also incorrect in the applied (i.e. marked with a Y) effect in the TOES data:

But it had been correctly applied in the affected “knock on” provision in leg.gov:

https://www.legislation.gov.uk/uksi/2013/264/schedule/2/part/1/paragraph/6/2020-12-31

So, the checker added a further comment against the doc to say: “and affected prov for effect by reg. 6(4)(a) should be Sch. 2 Pt. 1 para. 6.

And revised version needs to be corrected in reg. 6(4)(a) to say “paragraph 6””.

This has now been corrected:

https://www.legislation.gov.uk/uksi/2020/1504/regulation/6

Revert online initial edit instructions

Revert online initial edit task

In order to revert a published online initial edit task, you need to have access to Admin.

You cannot revert the task if a subsequent update task has been completed and published or if there has been a published legislation correction since initial edit was done.

If there is an update task in progress, you can reset that task and then revert the initial edit task.

You cannot revert an offline initial edit task.

You can only revert initial edit a maximum of twice, so be careful.

Method

In Admin, search the editorial system for the research tasks associated with your document.

Go into the online initial edit review task and open the Help and Support tab.

Click the link marked “Rollback this Review Online Initial Edit Research of [legislation] task”:

A dialog box will appear and you can either Cancel (if you change your mind) or click the green “Revert” button to revert the task.

The revised version will then disappear from legislation.gov.uk, leaving only the made version. (NB It may be a good idea to open the revised version fully on the website before you click revert, if you wish to still see what was previously published).

Then, in your usual editorial account, go back into the online initial edit review task and you will land on the initial edit Preview page.

From the Preview page you can then use the appropriate buttons re-do the initial edit task either from the extent or commencement page to make your corrections before regenerating the PiTs and then re-publishing.

Please note that when you re-publish the initial edit, duplicate coming into force (I-note) effects will be added to TOES. Therefore you must do a TOES correction immediately after publishing to remove these duplicate effects before you proceed to update.

Historic unapplied corrections warning message

We have had issues for a long time with the legislation corrections tool not properly trickling corrections through into multiple PiTs. Most obviously, this resulted in “latest version discrepancies” where a change to the dated version didn’t trickle into the latest version. However, it has also occurred where a parent provision has more PiTs than its corrected child and this is less easy to spot since the missing data isn’t manifest in the latest version. TSO think they have fixed the issue in the corrections tool, but there are now legacy errors in the earlier corrected docs. It is too big a task to correct these all in one go, so instead TSO have now added an amber coloured warning message in the relevant affected docs. This shows up in both the corrections page and the update page and looks like this:

"There are some known outstanding issues with this document. Contact TSO to obtain support in addressing the historic unapplied corrections to earlier PiTs."

The presence of the note does not prevent editors from allocating these docs for update. So if you allocate yourself an update task and you see it has such a note, please continue with your update task. Editors do not need to report these notes to anyone.

Reviewers, when you see a doc with this note in update review, please complete your review and then raise a Jira support call story for TSO to fix it (or if you do not have permissions to do this, ask Richard, Dean, Rob, Janine, Sarah or Ana). In this way we hope to fix them gradually over time.

Jira support call portal:

https://tsoltd.atlassian.net/servicedesk/customer/portal/58

Select first option "Support", then "Support request" because the issue derives from a bug in corrections.

The story should be called “[legislation number of doc] - historic unapplied corrections to earlier PiTs” in the summary box and put the same thing in the decription.

Legislation support = "Editorial system" and "Corrections".

Leave priority as P5 as these are not usually urgent, but if you need it done urgently for some reason state this somewhere in the story.

You should raise a revised leg correction task and put the same story name in the correction description. You should paste the correction task url into the Jira story.

When TSO get back to you to say it’s fixed, you should at that point

• publish the correction task,

• remove the legislation note from the doc (delete its text using the More menu in the Update page for the document in Admin); and

• mark the Jira story as done.

Solving conflicting updates errors

Conflicting updates errors caused by “orphan” concurrent versions

Conflicting update errors can be caused by so-called “orphan” concurrent versions. This is where a document contains a concurrent version that is not associated with a principal version (an “orphan”).

The conflicting updates error message usually references the provision that is causing the conflict. If that provision has concurrent versions, check the AltVersionRef attribute in the principal version. Compare that with the version id of the concurrent version - if you then find more than one concurrent version with different version ids, you should remove the XML for the one that doesn't match the AltVersionRef in the principal version.

For example:

Principal version points to AltVersionRef="v10002" and <Versions> tagging contains two concurrent versions for that provision, one with with that id, i.e.

The other concurrent version has a different id = v10001. This is an “orphan”, because the principal version doesn't point to it, and the XML needs to be removed to fix the conflicting update error when starting update. Note that the orphan can only be seen by using the raw xml checkout. If you check out the document in XMetaL normally, you only get the connected AltVersion.

Legislation provision correction tasks (system tasks - do not allocate)

These tasks are auto-generated when an unapplied effect is added to TOES dated at a PiT prior to last update PiT. They are system generated tasks and therefore cannot be allocated. You should allocate a new revised legislation correction task to do your correction and then, afterwards, delete the unassigned legislation provision correction task/s.

This results in the following warning message in update task under timeline:

“Online Update cannot be allocated on this document due to pending Legislation correction task(s)”

This is what the correction task looks like on the Corrections tab on the Editorial Site:

If you click on the note, you can see the details of the effect that has caused this task to be generated:

To find out what the unapplied effects are, you can download the TOES using the following URLs:

https://editorial.legislation.gov.uk/changes/affected/<type>/<year>/<number>/data.xls?extended=full-with-co

https://editorial.legislation.gov.uk/changes/affected/ukpga/2003/1/data.xls?extended=full-with-co

Filter the sheet for unapplied effects (Blanks) in Applied column and by IF Date or IFCO Date:

Now you’ve found the effect, you should check whether or not it has really been applied because this will determine what you should do next.

If it has been applied, then we just need to do a toes correction to add the missing Y.

If it has not been applied, then we need to do a legislation correction to add the missing effect and, once that has been done, we then need to do a TOES correction to mark the effect as applied.

In this example, the effect had been applied but not marked with a Y:

This may have been because the effect was slightly retrospective and added via a correction task and the editor forgot to add the Y in TOES, or it may have been because we didn’t notice that the Y had not been added automatically by the editorial tool during effects confirmation following update review.

This was resolved by a TOES correction. The update task was reset, the correction was carried out and the update was re-allocated again.

Missing effects are usually caused by a correction being made to the affected legislation number in TOES after the affected Act has already been brought up to date.

But in this example, there was another slight complication in that the amendment (although present in the version dated 6.4.2014) was not showing in the “latest revised” version of the provision:

This is called a “latest version discrepancy” and we have to raise a story for TSO to fix it.

https://www.legislation.gov.uk/ukpga/2014/26/schedule/17/paragraph/5

https://www.legislation.gov.uk/ukpga/2014/26/schedule/17/paragraph/6

Once the issue is resolved we need to delete the unassigned legislation provision correction task using the option (“Delete unassigned legislation provision correction tasks”) in the More menu in Corrections in Admin and then clicking the “Delete” button.

Reset workspace in XMetaL

To reset the workspace in XMetaL:

1. Close down XMetaL.

2. Double click on XMetaL to open it.

3. Immediately after opening XMetaL, hold down the Ctrl key while XMetaL is opening.

4. A dialog box will appear asking "Do you want to skip opening the last session's workspace?"

5. Click Yes and it will refresh XMetaL.

6. Login to XMetaL in the usual way.

Scanned pdfs

Use this URL to download a scanned pdf:

http://www.legislation.gov.uk/[type]/[year]/[number]/pdfs/[type]mkd_yyyynnnn_en.pdf

Examples of scanned pdfs:

http://www.legislation.gov.uk/mwa/2008/2/pdfs/mwamkd_20080002_mi.pdf

http://www.legislation.gov.uk/ukpga/2004/8/pdfs/ukpgamkd_20040008_en.pdf

http://www.legislation.gov.uk/uksi/2010/979/pdfs/uksimkd_20100979_en.pdf

http://www.legislation.gov.uk/wsi/2011/297/pdfs/wsimkd_20110297_en.pdf

Amendment coming into force before the provision it is amending comes into force

This scenario results in “later sld version errors” which prevent you from starting update. It is caused because at least one amendment has a start date earlier than one of the provisions in the affected document, so there are several different ways of getting round this depending on the exact situation:

If the amended doc is being revoked before it comes into force, then you will have to reset update and re-do sld initial edit to make it prosp and redeploy and then do the update to revoke it;
If an amendment comes into force before the affected provision comes into force, there are two options:

do a TOES correction to change the IFDate of the effect to make it the same as the start date of the affected provision, ensuring that you also provide a “Suggested Commentary” for the effect that contains its REAL start date. (A suggested commentary should be written properly in our house style, including punctuation, legislation title and commencement order details). Then do update.
if the amendments have start dates between the earliest date that the affected doc comes into force and one or more subsequent commencements, then you should reset update, re-do sld initial edit to make the subsequently commenced provisions prosp; then you should do a TOES correction to add coming into force effects for those now prosp provisions. Then when you re-allocate update the coming into force effects will be added as I-notes as part of the update task and will appear in the update timeline.

"Later Legislation version" error: amendment made to affected legislation before it comes into force

Error message on starting update:

"Later legislation version dated '2007-05-01' found. Your request to update PiT dated '2007-03-28' cannot be completed. There is a later version of this legislation and this is not currently supported for updates other than commencements"

The "Later legislation version" error message occurs here because the IF Date of the effects (28.3.2007) is earlier than the start date of the affected legislation (1.5.2007).

https://www.legislation.gov.uk/ssi/2006/534/regulation/1/made

https://www.legislation.gov.uk/ssi/2007/166/regulation/1/made

We can work around by changing the TOES data so that the IF Dates for the effects coincide with the start date (1.5.2007) of the affected provisions, but we also need to add a Suggested Commentary using our house style so that the annotation contains the actual date (28.3.2007) that the amendments come into force:

After correcting the TOES data, we need to reset update (in fact it’s easier to correct TOES if we reset the Act first) and (as is the case here) we may also need to actually delete the existing update tasks (e.g. “Update to 28/3/2007”) and allocate them over again from scratch because they have the wrong date in them. Also, the timeline may need to be regenerated before reallocation of update is allowed.

See another example in S.I. 2018/1199, regs. 6(5) and 15(2)(b), where a Comment for the Editor has also been included in the TOES correction to explain what is going on (TOES corrections are highlighted red; previously the IF Date was 30/12/2020 and this needed to be changed to 31/12/2020 to resolve the "later version error"):

https://www.legislation.gov.uk/uksi/2018/1199/regulation/6

https://www.legislation.gov.uk/uksi/2018/1199/regulation/15

"Later Legislation version" error: affected legislation revoked before it comes into force

Error message on starting update:

"Later legislation version dated '2021-07-12' found. Your request to update PiT dated '2021-07-11' cannot be completed. There is a later version of this legislation and this is not currently supported for updates other than commencements"

The "Later legislation version" error message occurs here because the IF Date of the revocation (11.7.2021) is earlier than the start date of the affected legislation (12.7.2021).

If it had been offline initial edited, it would have been possible to reset the update, delete the update tasks and then redo the initial edit on sld to make it prospective, then redeploy it before re-allocating the update.

However, because it had been online initial edited, the update needed to be reset and the update tasks were deleted and a TOES correction was carried out to make the IF Date of the revocation (11.7.2021) match the date the affected document comes into force (12.7.2021). A suggested commentary (where we write the annotation out in our proper house style) was also added for the revocation containing the real date of the revocation (11.7.2021):

This allowed the update to go ahead. Then during update, the legislation was revoked using the auto repeal function:

The Timeline Resolver in Preview was then used to remove the PiT so it looks prospective (Note: the resolution of the timeline was done by TSO as we were unable to use the Timeline Resolver at the top level of the document. TSO suggested resolving the intro, sig block, notes and body levels before resolving timeline at the legislation level).

Before Timeline Resolver used to remove PiT 12/7/2021:

After Timeline Resolver used to remove PiT 12/7/2021:

@@ Line 32: / Line 32: @@
 =====Focusing a TOES correction to override dependencies or to reduce the size of the spreadsheet=====
-. When allocating the task, select type of effect “Made by [document]”  or “Changes that affect [document]” and focus correction task by adding year and number of affected/affecting document.  Remember, if an update task is in progress, a TOES correction will result in the update statuses being wiped, so you should tell the editor that this will happen and ask them to add them back in.
+When allocating the task, select type of effect “Made by [document]”  or “Changes that affect [document]” and focus correction task by adding year and number of affected/affecting document.  Remember, if an update task is in progress, a TOES correction will result in the update statuses being wiped, so you should tell the editor that this will happen and ask them to add them back in.
 =====Useful URLs to access TOES database content=====
-. URLs to check TOES data:
+URLs to check TOES data:
 <nowiki>https://editorial.legislation.gov.uk/changes/affected/<type>/<year>/<number>/data.xls?extended=full-with-co</nowiki>
@@ Line 45: / Line 45: @@
 =====Need to change download URL to download regnal year Act TOES spreadsheets=====
-. Regnal year Acts (pre-1963) – spreadsheet won’t download unless you change URL to /type/year/number/ format.
+Regnal year Acts (pre-1963) – spreadsheet won’t download unless you change URL to /type/year/number/ format, e.g.
+    /ukpga/Vict/33-34/90
+    to
+    /ukpga/1870/90
 =====TOES corrections done while a connected update task is in progress will wipe update edit statuses=====
-. As mentioned above under point 1, doing a focused TOES correction task while an update task is in progress will result in the update edit statuses being wiped and they will need re-adding.  So it is always a good idea to speak to the update editor if you're considering doing this.
+As mentioned in the first point above, doing a [[Corrections#Focusing_a_TOES_correction_to_override_dependencies_or_to_reduce_the_size_of_the_spreadsheet|focused TOES correction task]] while an update task is in progress will result in the update edit statuses being wiped and they will need re-adding.  So it is always a good idea to speak to the update editor if you're considering doing this.
 =====There is only one amendment, but two different ways of looking at it: affecting and affected=====
-. You only need to correct an effect once, i.e. do not delete from one sheet and then add to another, just e.g. change the legislation number of the effect in one TOES correction sheet.  The effects reside in the XML database, the donloaded spreadsheet is just a form of representation; so whether you download an effect from the PoV of the affected or from the PoV of the affecting, it is still the same effect with the same key-id number.
+You only need to correct an effect once, i.e. do not delete from one sheet and then add to another, just e.g. change the legislation number of the effect in one TOES correction sheet.  The effects reside in the XML database, the donloaded spreadsheet is just a form of representation; so whether you download an effect from the PoV of the affected or from the PoV of the affecting, it is still the same effect with the same key-id number.
 =====Dangers=====
-. Dangers:
 *Only delete rows that are completely unnecessary (NB we can’t delete whole rows from the effects confirmation sheet).
@@ Line 67: / Line 73: @@
 If the IFDate entered during Initial Edit is incorrect, this results in a corresponding mistake in the coming into force effect that the Initial Edit task adds to TOES.  Therefore, When we correct a start date and/or I-note via a legislation correction task, we should also correct the TOES data to make the coming into force effect right too.
+====Report any errors if the corrected TOES upload fails (don't reset the task)====
+If you get an email telling you that there has been an error when are trying to upload the corrected spreadsheet, don't reset the task - report it.
+Even if the task has failed, some of the data may have uploaded successfully, which could result in ‘orphan’ data in the rdf which then looks like unapplied effects. If you reset the task, this ‘orphan’ rdf data stays there and won't ever get refreshed so will need to be corrected.
 ===Legislation Correction===
-====Alocating a revised legislation correction task====
+====Allocating a revised legislation correction task====
 You can allocate a legislation correction task to yourself by searching for the relevant document on the Editorial Site and selecting the “Corrections” tab. Making sure that the “Create new legislation task” is set to “Correct Revised Legislation”, allocate the task to yourself by selecting your details in the dropdown “Allocate to” box. You can add details of the correction in the “Note” box and click “Create Task”.
@@ Line 155: / Line 168: @@
 Multiple repeals of words often result in missing dotty lines after first check in; if this happens, check out and back in again and the dotty lines should appear.
-When you do a manual textual repeal in corrections you will see a dialog box asking you if it is an “InlineRepeal” (this kind of repeal will produce 3 dots and ensure there are spaces before and after them); if you are deleting a block (i.e. selecting tags to repeal blocks of text), you should change this to “BlockRepeal” (which results in the block repeal dots and no spaces).
+When you do a manual textual repeal in corrections you will see a dialog box asking you if it is an “InlineRepeal” (this kind of repeal will produce 3 dots and ensure there are spaces before and after them); if you are deleting a block (i.e. selecting tags to repeal blocks of text), you should change this to “BlockRepeal” (which results in the block repeal dots and no spaces). Similarly with InlineAddition and BlockAddition for manual insertions re spaces.
-Similarly with InlineAddition and BlockkAddition for manual insertions re spaces.
+Where an annotation has the same id in multiple versions, a change in the latest version of the provision will be registered in all earlier versions.  NB if you are making a textual change in multiple versions and also want to change an annotation, you may as well wait until editing the last version to change the commentary or it will only get overwritten each time.
-Where an annotation has the same id in multiple versions, a change in the latest version of the provision will be registered in all earlier versions.  NB if you are making a textual change in multiple versions and also want to change an annotation, you may as well wait until editing the last version to change the commentary or it will only get overwritten each time.
+=====Inserting a new provision=====
+When you need to insert a new provision using the Corrections Tool, removing any ids in the attributes will ensure that new ones are added on check-in. The PiT you need to carry out the insertion at should already exist in the document and you will need to check out the relevant parent at that PiT to carry out the insertion. Look out for the start date defaulting to the earliest start date of the parent whe you check it back in, and amend the restrictstartdate attribute wherever it occurs in your newly inserted provision if necessary.
 =====Previewing corrections=====
@@ Line 201: / Line 216: @@
 <div id="tna-removewholedocPiT">optional text</div>
-To remove a whole document PiT, you need to use the provision timeline at the top level of the document; only use this if you do not want the PiT at all because it will remove it from the whole document.
+To remove a whole document PiT, you need to use the “Remove PiT” button for the relevant PiT in the provision timeline at the top level of the document; only use this if you do not want the PiT at all because it will remove it from the whole document.
+ [[File: Remove_PiT_whole_doc.png|1000px]]
 =====Provision level PiTs=====
@@ Line 207: / Line 224: @@
 To insert a PiT in a provision, use the timeline resolver in the preview of that provision – note that you can only do this if there is an existing PiT at whole document level.
-To remove a PiT in a provision you also need to use the timeline in the preview of the provision, but if the PiT should not exist anywhere in the document then you should remove the whole document PiT instead (see [[Corrections#tna-removewholedocPiT|above]]).
+To remove a PiT in a provision you need to use the “Remove from PiT” button in the “To Correct” timeline for that provision:
+[[File: Remove_PiT_button.png|900px]]
+However, if the PiT should not exist anywhere else in the document then you should remove the whole document PiT instead (see [[Corrections#tna-removewholedocPiT|above]]).
 ====Correcting incorrect IFDates in start dates and/or I-notes in a legislation correct task - remember to correct the TOES dates for any coming into force effects too====
@@ Line 236: / Line 258: @@
 We would expect this type of effect to be recorded with a bespoke [[Preparation_Tasks/Record_Effects#Amendments_to_be_treated_as_never_made |“amendments and repeals by ... treated as never made”]] with a  retrospective IF Date a Comment for Editor explaining the situation and telling the editor to put the text back to how it was before the amendment were made.
+====ISSUES====
+=====Beware of issue when removing a PiT at provision level: underlying data does not get removed=====
+There is currently an issue in the Corrections Tool when we use the “Remove from PiT” button to remove a PiT at provision level. The Corrections Tool only adjusts the metadata, it <strong>does not adjust the actual underlying data of the provision</strong> (NB this is also what happens with removing a PiT using the Timeline Resolver, which also only adjusts the metadata).
+This means that the provision data from the PiT you are removing will still be visible at interim later PiTs (i.e. if you view the provision from a higher level at a later PiT).
+To get around this issue, we need to replace the XML of the provision at the PiT you are removing with the data for that provision from previous PiT before you use the “Remove from PiT”  button to remove the PiT. You can either correct the XML yourself to remove any amendments and put it back to how it was at the previous PiT, or you can copy and paste the data from the previous PiT – being careful to copy over the text only (whichever is the easiest way to make that version look like the previous version is acceptable). This means that the data from the previous PiT will be carried forward into future interim PiTs, rather than the data for the PiT you are removing.
+=====Beware of losing further commencement details at later PiTs when you check out a provision at the first PiT that an effect is partially commenced=====
+Be careful if you are checking out an earlier PiT of a provision containing effects that are partially commenced for the first time at that PiT, which get further commenced at later PiTs. The annotations for those further commencements at the later PiTs may get overwritten and lose the further commencement details that were added via auto-annotation tasks at those later PiTs (even if your correction has nothing to do with them), for example from:
+<blockquote>Words in s. 3A(1) substituted (1.7.2012 for specified purposes, <span style = "color:red;">22.11.2012 in so far as not already in force</span>) by Localism Act 2011 (c. 20), s. 240(2), Sch. 4 para. 4(2)(a); S.I. 2012/1463, art. 5(a) (with arts. 6, 7) (as amended (3.7.2012) by S.I. 2012/1714, art. 2); <span style = "color:red;">S.I. 2012/2913, arts. 1(2), 2(b) (with arts. 3-6)</span></blockquote>
+To:
+<blockquote>Words in s. 3A(1) substituted (1.7.2012 for specified purposes) by Localism Act 2011 (c. 20), s. 240(2), Sch. 4 para. 4(2)(a); S.I. 2012/1463, art. 5(a) (with arts. 6, 7) (as amended (3.7.2012) by S.I. 2012/1714, art. 2)</blockquote>
+At the moment, the only solution is to add those details back in again to the annotations at the later PiTs where they have been lost.
+=====Beware when doing high level corrections on older Acts edited on SLD=====
+Older Acts that were edited on SLD <strong>may</strong> have an issues where amendments made across several dated versions of certain provisions only appear in the “latest version” of those provision, but they do not appear in the actual dated versions themselves.
+It turns out that this issue is caused by a combination of (1) the difference between how SLD dealt with start dates (it populated them in a hierarchy from the top downwards and didn’t always add start dates on higher levels) and how the editorial system deals with them (from the bottom upwards, adding a start date in all levels), and (2) the fact that the legislation correction tool still seems to cope unsatisfactorily with that difference.
+TSO have run a query and there are about 2,800 Acts that were edited originally on SLD where this may be a potential issue.  This doesn’t mean that all those documentss actually have issues, they are just potentially liable to suffering the same fate if we do a high level correction without first running the high level fragment through the timeline resolver to resolve the problematic start dates from sld.
+So, if you’re doing a legislation correction on a document that has undergone OFFLINE UPDATE (which you can see by looking at the update overview page on editorial, but the list is also attached above) and you want to do a correction which involves checking out a higher level fragment (i.e. cross-heading or above), then please be sure to use the <strong>website preview</strong> first, before doing your correction, to view the higher level fragment, go back through its dated versions in the timeline and <strong>use the timeline resolver button to resolves its start dates</strong>.  This should prevent the issue from occurring.
+<strong>Please also LOOK OUT for dated versions of provisions which do not contain any amendments</strong> and compare them with their latest version.  <strong>If the latest version does contain amendments but the dated versions do not, then this is an issue</strong> and we need to raise a story for TSO to fix it using the backup date from the archives.
+======Remember to check ancestor and descendant fragments after publication======
+Check that all changes carry through to the website through all ancestor and descendant fragments, in the best collection (no date in the URL), the corrected PiT (PiT’s date in the URL) and intermediate PiTs (dates after the PiT you’ve edited but before the next PiT on the timeline of the fragment you’re looking at – just change the date in the URL to advance one day).  Once published, just look around what you’ve changed – side to side temporally (including intermediate PiTs) and up and down to parents and children.
+==Correction Slip Project 2==
+Corrections slips are issued by Departments in consultation with the SI Registrar to correct errors in legislation.
+When they are issued, TSO add the correction slip pdf to the document on legislation.gov.uk under More Resources and they carry through the correction in the made/as enacted version.
+If there is a revised version of the document, we need to carry through the correction in all relevant revised versions of the corrected legislation ourselves.
+We also need to check if the correction “knocks on” to revised versions of any legislation which is affected by the corrected document (i.e. if it is a correction to an amendment) and, if necessary, do a further correction.
+We may also need to correct our TOES data.
+Simon and Hoda have come up with a list of docs which have had correction slips added to them on leg.gov.
+This information is on the corrections allocation spreadsheet here:
+https://docs.google.com/spreadsheets/d/1P_F-xbWeOPWVCNO9md5c-2mPAsTscFuVJsOBe_sjt-k/edit?usp=sharing
+===Checkers===
+In essence, you are checking the documents to find out the following:
+*Has the made version been corrected?
+*Have the revised versions (if there are any) been corrected?
+*If the provision is an amending provision, does the TOES data need to be corrected?
+*If the amendment by the provision has been applied, does the “knock on” affected legislation need to be corrected?
+<u>Method</u>
+You need to select the next doc from the list and look at its correction slip or slips (if there is more than one) on leg.gov.  Add your name against the doc.
+If there is no revised version, check that the correction has been correctly applied to the text of the made/as enacted version.  If it has, no further action is need so add a comment and mark the doc with an N in “Action needed?” column.
+If it hasn’t, add a comment so say the made version needs to be corrected by TSO and mark it with a Y in the “Action needed?” column.
+If there are revised versions, after checking the made version check the revised versions to make sure the correction also appears there.  If it does, no further action is required so add a comment and mark it with an N.
+If one or all revised versions have not been corrected, then add a comment to say what needs to be done and mark it with a Y.
+If the provision is an amending provision you will need to check that the TOES data is correct.  You can do this by using this url to download the affecting TOES data for the doc from the database:
+<nowiki>https://editorial.legislation.gov.uk/changes/affecting/<type>/<year>/<number>/data.xls?extended=full-with-co&sort=affecting-year-number</nowiki>
+e.g.
+https://editorial.legislation.gov.uk/changes/affecting/uksi/2019/588/data.xls?extended=full-with-co&sort=affecting-year-number
+If the TOES data need to be corrected (e.g. the affected provision or sub-provision has the wrong number/s or the affected legislation number is wrong or the type of effect needs to be changed), add a comment saying what needs to be done and mark it with a Y.
+You will then need to visit the affected provision (i.e the provision that has been hit by the now-changed amending provision) on leg.gov to see if the text of that amendment is correct.  If it needs to be corrected, add a comment to say what needs to be done and mark your doc with a Y.
+Then move on to the next doc on the list.  And so on, till we have checked the whole list …
+===Reviewers===
+Reviewers should check the list and look for docs marked with a Y in the “Action needed?” column.
+They should then check what needs to be done by looking at the checker’s comments and comparing it with the correction slip/s and take the appropriate action.
+As required, the reviewer should:
+*Raise a publishing support call with TSO if the made version needs correction (or ask their line manager to do this).
+*Do a legislation correction to correct any revised versions which need correction.
+*If necessary, do a TOES correction to correct the TOES data.
+*If necessary, raise a legislation correction to correct the affected “knock on” doc hit by the now-corrected affecting provision.
+Once everything has been corrected, the reviewer should mark the doc with a Y to say that all actions have been completed and put their initials next to it.
+Then move on to the next doc which requires action …
+===Example: S.I. 2020/1504===
+https://www.legislation.gov.uk/uksi/2020/1504/contents
+correction slips:
+. March 2021
+https://www.legislation.gov.uk/uksi/2020/1504/pdfs/uksics_20201504_en_001.pdf
+. September 2021
+https://www.legislation.gov.uk/uksi/2020/1504/pdfs/uksics_20201504_en_002.pdf
+. January 2024
+https://www.legislation.gov.uk/uksi/2020/1504/pdfs/uksics_20201504_en_003.pdf
+The first two slips dated 2021 had been applied already in the made and revised versions:
+Correction by slip 1 - https://www.legislation.gov.uk/uksi/2020/1504/regulation/17/made
+Correction by slip 2 - https://www.legislation.gov.uk/uksi/2020/1504/regulation/3/made
+The provision amended by reg. 17(21) is correctly showing as s. 420A, so the correction by correction slip 1 had been carried through correctly:
+https://www.legislation.gov.uk/uksi/2019/705/regulation/420A
+However, the TOES data for the (unapplied) amendment by reg. 3(12) had not been corrected to s. 0042B as per correction slip 2, dated September 2021:
+https://editorial.legislation.gov.uk/changes/affecting/uksi/2020/1504/data.xls?extended=full-with-co&sort=affecting-year-number
+[[File: Correction slips 1.png|800px]]
+So, the checker here added a Y in “Action needed?” column and a comment to say: “TOES correction needed - affected prov should be s. 42B for effect by reg. 3(12)”
+Also, although the correction slip dated January 2024 (correction slip 3) had been applied to the made version:
+https://www.legislation.gov.uk/uksi/2020/1504/regulation/6/made
+It had not been applied to the revised version and reg. 6(4)(a) still said “in Part 1, in paragraph 7” rather than “paragraph 6”:
+[[File: Correction slips 2.png|800px]]
+This info was also incorrect in the applied (i.e. marked with a Y) effect in the TOES data:
+[[File: Correction slips 3.png|800px]]
+But it had been correctly applied in the affected “knock on” provision in leg.gov:
+https://www.legislation.gov.uk/uksi/2013/264/schedule/2/part/1/paragraph/6/2020-12-31
+So, the checker added a further comment against the doc to say: “and affected prov for effect by reg. 6(4)(a) should be Sch. 2 Pt. 1 para. 6.
+And revised version needs to be corrected in reg. 6(4)(a) to say “paragraph 6””.
+[[File: Correction slips 4.png|800px]]
+This has now been corrected:
+https://www.legislation.gov.uk/uksi/2020/1504/regulation/6
+==Revert online initial edit instructions==
+===Revert online initial edit task===
+In order to revert a published online initial edit task, you need to have access to Admin.
+You cannot revert the task if a subsequent update task has been completed and published or if there has been a published legislation correction since initial edit was done.
+If there is an update task in progress, you can reset that task and then revert the initial edit task.
+You cannot revert an offline initial edit task.
+You can only revert initial edit a <strong>maximum of twice</strong>, so be careful.
+===Method===
+In Admin, search the editorial system for the research tasks associated with your document.
+Go into the <strong>online initial edit review task</strong> and open the <strong>Help and Support</strong> tab.
+Click the link marked “Rollback this Review Online Initial Edit Research of [legislation] task”:
+[[File: Revert_online_initial_edit_1.png]]
+A dialog box will appear and you can either <strong>Cancel</strong> (if you change your mind) or click the green “<strong>Revert</strong>” button to revert the task.
+The revised version will then disappear from legislation.gov.uk, leaving only the made version.  (NB It may be a good idea to open the revised version fully on the website before you click revert, if you wish to still see what was previously published).
+Then, in your <strong>usual editorial account</strong>, go back into the <strong>online initial edit review task</strong> and you will land on the initial edit <strong>Preview</strong> page.
+From the Preview page you can then use the appropriate buttons re-do the initial edit task either from the extent or commencement page to make your corrections before regenerating the PiTs and then re-publishing.
+Please note that when you re-publish the initial edit, <strong>duplicate coming into force (I-note) effects will be added to TOES</strong>.  Therefore you <strong>must do a TOES correction</strong> immediately after publishing to remove these duplicate effects before you proceed to update.
 ==Historic unapplied corrections warning message==
-We have had issues for a long time with the legislation corrections tool not properly trickling corrections through into multiple PiTs.  Most obviously, this resulted in “latest version discrepancies” where a change to the dated version didn’t trickle into the latest version.  However, it has also occurred where a parent provision has more PiTs than its corrected child and this is less easy to spot since the missing data isn’t manifest in the latest version.  TSO think they have fixed the issue in the corrections tool, but there are now legacy errors in the earlier corrected docs.  It is too big a task to correct these all in one go, so instead TSO have now added an amber coloured warning message in the relevant affected docs, for example:
+We have had issues for a long time with the legislation corrections tool not properly trickling corrections through into multiple PiTs.  Most obviously, this resulted in “latest version discrepancies” where a change to the dated version didn’t trickle into the latest version.  However, it has also occurred where a parent provision has more PiTs than its corrected child and this is less easy to spot since the missing data isn’t manifest in the latest version.  TSO think they have fixed the issue in the corrections tool, but there are now legacy errors in the earlier corrected docs.  It is too big a task to correct these all in one go, so instead TSO have now added an amber coloured warning message in the relevant affected docs.  This shows up in both the corrections page and the update page and looks like this:
-https://editorial.legislation.gov.uk/task/correct/anaw/2019/3
+[[File: Corrections_Leg_Note.jpg|1000 px]]
-[[File: Corrections_Leg_Note.jpg|1000 px]]
+ "There are some known outstanding issues with this document. Contact TSO to obtain support in addressing the historic unapplied corrections to earlier PiTs."
 The presence of the note does not prevent editors from allocating these docs for update.  So if you allocate yourself an update task and you see it has such a note, please continue with your update task.
 Editors do not need to report these notes to anyone.
-Reviewers, when you see a doc with this note in update review, please complete your review and then raise a Jira story for TSO to fix it (or if you do not have permissions to do this, ask Richard, Dean, Rob, Janine, Sarah or Ana).  The story should be called “[legislation number of doc] - historic unapplied corrections to earlier PiTs”.  You should raise a revised leg correction task and put the same story name in the correction description.  You should paste the correction task url in the Jira story.  In this way we hope to fix them gradually over time.
+<strong>Reviewers</strong>, when you see a doc with this note in update review, please <strong>complete your review and then raise a Jira support call story</strong> for TSO to fix it (or if you do not have permissions to do this, ask Richard, Dean, Rob, Janine, Sarah or Ana).   In this way we hope to fix them gradually over time.
+Jira support call portal:
+https://tsoltd.atlassian.net/servicedesk/customer/portal/58
+Select first option "Support", then "Support request" because the issue derives from a bug in corrections.
+The story should be called “[''legislation number of doc''] - historic unapplied corrections to earlier PiTs” in the summary box and put the same thing in the decription.
+Legislation support = "Editorial system" and "Corrections".
+Leave priority as P5 as these are not usually urgent, but if you need it done urgently for some reason state this somewhere in the story.
+You should raise a <strong>revised leg correction task</strong> and put the same story name in the correction description.  You should paste the correction task url into the Jira story.
 When TSO get back to you to say it’s fixed, you should at that point
@@ Line 258: / Line 511: @@
 •	mark the Jira story as done.
-==Legislation provision correction tasks (sytem tasks - do not allocate)==
+==Solving conflicting updates errors==
+===Conflicting updates errors caused by “orphan” concurrent versions===
+Conflicting update errors can be caused by so-called “orphan” concurrent versions. This is where a document contains a concurrent version that is not associated with a principal version (an “orphan”).
+The conflicting updates error message usually references the provision that is causing the conflict. If that provision has concurrent versions,  check the AltVersionRef attribute in the principal version. Compare that with the version id of the concurrent version - if you then find more than one concurrent version with different version ids, you should remove the XML for the one that <strong>doesn't</strong> match the AltVersionRef in the principal version.
+For example:
+Principal version points to AltVersionRef="v10002" and <Versions> tagging contains two concurrent versions for that provision, one with with that id, i.e.
+<Versions>
+<Version id="v10002" Description="S">
+<P1group Concurrent="true" RestrictExtent="S" RestrictStartDate="2012-07-01">
+The other concurrent version has a different id = v10001.  This is an “orphan”, because the principal version doesn't point to it, and the XML needs to be removed to fix the conflicting update error when starting update. Note that the orphan can only be seen by using the <strong>raw xml checkout</strong>.  If you check out the document in XMetaL normally, you only get the connected AltVersion.
+==Legislation provision correction tasks (system tasks - do not allocate)==
-These tasks are auto-generated when an unapplied effect is added to TOES dated at a PiT prior to last update PiT.  They are <strong>system generated tasks and therefore should not be allocated</strong>.  You should allocate a new revised legislation correction task to do your correction and then, afterwards, delete the unassigned legislation provision correction task/s.
+These tasks are auto-generated when an unapplied effect is added to TOES dated at a PiT prior to last update PiT.  They are <strong>system generated tasks and therefore cannot be allocated</strong>.  You should allocate a new revised legislation correction task to do your correction and then, afterwards, delete the unassigned legislation provision correction task/s.
 This results in the following warning message in update task under timeline:
@@ Line 451: / Line 722: @@
 [[File: Correct_effects_8.png|1000px]]
-==Notes about Corrections==
+<!--REPEATED UNDER "DANGERS" ABOVE==Notes about Corrections==
 ===TOES===
@@ Line 465: / Line 736: @@
 /ukpga/1870/90
-After you’ve downloaded the sheet you can then go back to the previous page and click the next button to get the upload page.</blockquote>
+After you’ve downloaded the sheet you can then go back to the previous page and click the next button to get the upload page.</blockquote>-->
 ==Related Content==
 * [[Editorial_Update/XMetaL_and_XML_tagging#Fixing_hyperlinks|Fixing Hyperlinks]]

Difference between revisions of "Corrections"

Latest revision as of 08:32, 15 September 2025

Carrying out correction tasks

TOES correction

Useful information

Focusing a TOES correction to override dependencies or to reduce the size of the spreadsheet

Useful URLs to access TOES database content

Be aware that multiple affecting sub-provisions may render slightly oddly in downloaded spreadsheets

Need to change download URL to download regnal year Act TOES spreadsheets

TOES corrections done while a connected update task is in progress will wipe update edit statuses

There is only one amendment, but two different ways of looking at it: affecting and affected

Dangers

Correcting IFDates in TOES - remember to correct the dates of any coming into force effects too

Report any errors if the corrected TOES upload fails (don't reset the task)

Legislation Correction

Allocating a revised legislation correction task

Welsh revised legislation correction tasks

Carrying out corrections in XMetaL

Useful tagging

Other useful information

Inserting a new provision

Previewing corrections

Inserting or removing PiTs

Whole document PiTs

Provision level PiTs

Correcting incorrect IFDates in start dates and/or I-notes in a legislation correct task - remember to correct the TOES dates for any coming into force effects too

Applying “retrospective” amendments

ISSUES

Beware of issue when removing a PiT at provision level: underlying data does not get removed

Beware of losing further commencement details at later PiTs when you check out a provision at the first PiT that an effect is partially commenced

Beware when doing high level corrections on older Acts edited on SLD

Remember to check ancestor and descendant fragments after publication

Correction Slip Project 2

Checkers

Reviewers

Example: S.I. 2020/1504

Revert online initial edit instructions

Revert online initial edit task

Method

Historic unapplied corrections warning message

Solving conflicting updates errors

Conflicting updates errors caused by “orphan” concurrent versions

Legislation provision correction tasks (system tasks - do not allocate)

Reset workspace in XMetaL

Scanned pdfs

Amendment coming into force before the provision it is amending comes into force

"Later Legislation version" error: amendment made to affected legislation before it comes into force

"Later Legislation version" error: affected legislation revoked before it comes into force

Related Content

Navigation menu

Search