We are utilizing paragraph lists to assemble letters. We've noticed that if enough paragraphs are initially triggered to cause the letter to go to a second page, the following happens:
1) Any variable field cannot be edited on the second page. First page works fine on but on the second page, they don't even appear as a field. They just appear as text - whatever value is in the "Represent With" field. If you open the paragraph selection box and click replace and replace all the paragraphs with themselves, the fields now show up and work as expected.
2) If the paragraph field is marked as "No Editing", you shouldn't be able to click into the paragraph area and type freely. This works fine for the first page, however on the second page, the paragraph field becomes entirely editable. And while in edit mode, if you hit the back arrow to cause your cursor to move back to the first page, the first page is now editable even though it shouldn't be.
Any insight into either of these? Any settings I can use to prevent this?
Thank you in advance.
The first item is expected behavior and not a bug. This is the normal behavior for field propagation. The first occurrence of the field is editable, but all the subsequent locations simply receive a "copy" of the content and are not editable.
The second one does sound like a bug, if I understood your situation correctly. If the MLT is set for paragraph selection only and No Ediing, then all the pages should be protected.
As a side note, the MLT with paragraph selection will only activate from the first page and not when you click on that field on subsequent pages. I'm just drawing the connection to your first situation where only the first occurrence is where the editing must begin.
Thanks for your response. For the first item, this is a unique field that just happens to end up on the second page. It's not a field propagation situation. I've opened up a support ticket for both issues as they both appear to be bugs.
Since the previous reply, it has been proven that the subsequent pages could become editable even though the Paragraph selection definition was set to allow no such editing. I suspect the correction will appear in a future patch.