cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Community Tip - Need help navigating or using the PTC Community? Contact the community team. X

moving a parent of a protected element

jsulak
1-Newbie

moving a parent of a protected element

Hello Adepters,

If I protect an element in a doctype's .dcf file using <elementoption<br/>element="xref" protected="yes"/>, I cannot edit the contents of any
instance of that element, which is what I want. However, Arbortext also
prevents me from moving or cutting-and-pasting any of that element's
ancestors, which I don't want.

Is there any way to prevent an element from being modified but allow its
ancestors to be moved? None of the other possible values for @protected
in the .dcf seem to do what I want.

Thanks,

-James

6 REPLIES 6

Hi James--

Have you considered using doc callbacks instead of the DCF? I haven't tried
this myself, but it looks to me like could put together some combination of
insert_tag, delete_tag, and modify_tag callbacks to lock down changes to
specific elements, but still allow them to be shuffled around as part of
larger chunks of content.

--Clay

Clay Helberg
Senior Consultant
TerraXML
jsulak
1-Newbie
(To:jsulak)

Thanks, Clay. I did think of that, but I was hoping there was an
easier, built-in solution. Especially considering that we already use
some of those callbacks for other purposes.

I'm a bit surprised that there's not an easier way to do it, since it
would be a common requirement for customizations where you want to force
the user to modify certain elements - like cross references - through a
XUI interface. Oh well.

Thanks,

-James

James,

I tend to agree with you, but historically, the 'protect' feature in Epic has been notoriously weak. Setting the protected element has always been an inverse operation (at least it seems that way to me).

I can, and would expect, that children in a protected element cannot be changed, but I should be able to modify or move the parent (unless the parent is also a child through nesting of the protected element) as long as I don't change content of the protected child.

It could be that Epic is not only reading the linage of the elements, but also the OIDs of the active document and thus not allowing the OID to be modified.

The last thing (and I had to go start up the Epic computer) is you may want to check the 'set protection' option (help 7999) and see if this may or may not help you out.

If it does, then you could run it through the XUI as needed.

Lynn



---- James Sulak <jsulak@jonesmcclure.com> wrote:
> Thanks, Clay. I did think of that, but I was hoping there was an
> easier, built-in solution. Especially considering that we already use
> some of those callbacks for other purposes.
>
> I'm a bit surprised that there's not an easier way to do it, since it
> would be a common requirement for customizations where you want to force
> the user to modify certain elements - like cross references - through a
> XUI interface. Oh well.
>
> Thanks,
>
> -James
>
>
ebenton
1-Newbie
(To:jsulak)

Before we broke down our large, monolithic documents into smaller chunks
to edit, we used to have some large documents with a lot of generated
text in them. For instance, we would recalculate and update the
generated step number every time we inserted or deleted a step. When a
document would have a lot of procedures with a lot of steps in it, it
would bring your PC to its knees.
We compensated for this by using ACL to turn off the gentext and then
turn it back on when we were done editing. (set gentext=on/off)

As Lynn said, you could probably do something similar with set
protect=none/write.
bibach
1-Newbie
(To:jsulak)

In the "Restricting editing in documents" help section (help 7737), it notes that a protected element cannot be deleted, so I suspect this becomes a question of implementing this potentially vague requirement. Is cutting the element so it can be pasted somewhere else considered "deleting" it? For that matter, how is the application to know at the time of the cut that you intend to paste it back? In some cases it could be argued that Editor should know, but it seems that the developers went with a conservative approach to ensure the protected element would always be preserved.

That said, perhaps protection isn't the only way to go. You mentioned wanting to force users to use your XUI interface to modify cross-references, which you do by preventing them from modifying them directly. We had the same requirement, but we accomplished it by using the DCF to hide the attributes containing the cross-reference target data. If the user needs to be able to see what the target is, use gentext, which might even be able to provide a more human-readable version of the information, anyway.

-Brandon 🙂
jsulak
1-Newbie
(To:jsulak)

Thanks to everyone who responded.

Lynn and Ed - using the DCF along with "set protection=none/all" is our
current approach. Our cross-reference XUI uses the command to turn off
protection, make the change, and then turns protection back on. Works
well except for this one problem.

Brandon - I really like the idea of hiding the data instead of
protecting it, and we'll explore that. But implementing it might be
tricky because our xref model contains child elements.

Right now I'm thinking that using ACL callbacks instead of protection
(as Clay suggested) may be our best bet. Or alternatively, protecting
those elements by default, and then using a different set of callbacks
to conditionally turn off that protection when content is moved around.
(Assuming the needed callbacks exist - I haven't really researched it
yet).

Thanks,

-James


Top Tags