nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How to stop the user creating more than one DCR

Mali

Hi All,

I have a DCT say X, where user can create a DCR, but I wanted to allow the user to create ONLY ONE DCR using X DCT, rather how to stop the user creating more than one DCR.

Thanks
Mali
Win2k Server
TS 6.1

m. a. l. i.

Find more posts tagged with

Comments

Migrateduser

Well, you could have the DCT assign the name of the DCR depending on the userid via IWDCRInfo.setDCRName(). Of course, the user could always rename the DCR after s/he has saved it and use the DCT again, thus creating two. Is that a realistic scenario?

There are probably more creative ways to get around this, but that's the first thing that comes to my mind.

Dave

Current Environments:
(1) TS 6.5 on W2K3 (x2 - diff. imp.)
(3) Vignette V7 Portal on Solaris 9

Johnny

Is this one DCR per user, or one DCR per DCT?

John Cuiuli

Mali

Its One DCR per one DCT..my scenario is I use the output of the DCR in another DCT say Y.

m. a. l. i.

Mali

especially, I really don't want the user to rename or create one more DCR. Since I'm using the output of this DCR in another DCT. So I wanted to stop there.

m. a. l. i.

Migrateduser

Given your response to Johnny's question, there's no need to base the DCR name from the userid, then. A slightly more creative and more secure solution to what I mentioned before is to have the user fill out the DCT, as usual, have a workflow kick off when the user clicks on the "finish" button (tt_data) and the workflow will rename and change ownership of the DCR such that the user will neither be able to rename nor save a new DCR under a different name. make sure to also remove the SAVE AS link on the DCT.

However, you mentioned that you're on 6.1. I remember that either 6.1 or 6.1 SP1 (or both) have issues with kicking off a workflow via tt_data. Are you running a service pack?

Dave

Current Environments:
(1,2) TS 6.5 on W2K3
(3) Vignette V7 Portal on Solaris 9

Mali

Thanks Dave.

But if and when I use tt_data, the ownership gets changed, but here my doubt is can the user be able to edit the same DCR?

I want the DCR to grow then and there, but shouldn't allow one more DCR using the same DCT.

Migrateduser

So, what kind of user(s) are we dealing with here? As I understand it, we don't want them to have the ability to rename the DCR, yet we want them to be able to edit it? Well, a way around this is to have everything done via workflow. Have the DCR owned by someone else and not inherently editable by the user, but allow them the ability to update the DCR via workflow. What you do behind the scenes with externaltasks and ownership is up to you.

Do I have an accurate picture of your business requirements? They seem awkward if I do...

Dave

Current Environments:
(1,2) TS 6.5 on W2K3
(3) Vignette V7 Portal on Solaris 9

Johnny

You could probably do this with some permission settings.

Manually create a dcr for each dct and set the appropriate permissions for that file... seeing that you are on windows - set it so that you cannot remname the file.
Also restrict the permissions for the data directory itself so that no more files can be created.
Remove the save as button in the forms screen.
Try to remove the dct entry in templating.cfg - This didn't work in earlier versions but I don't know about 6.x. The idea is that there would be no options for the new forms screen. Hopefully the extended attributes on the dcr will be enough to allow you to open the dcr. It may not work, but it's worth a try.

John Cuiuli

Adam Stoller

Here's another somewhat convoluted idea:
Have a field in the DCT that initially has no value - or some default value - like:<item name="locked">
<hidden/>
<text><default>0</default></text>
</item>Then have a couple of pieces of FormAPI code:

http://www.quotient-inc.com