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; } } }

Disable New Form Entry

sanks

I have made several DCR's from a DCT. Now, i want to disable the new form entry. How can i do it??

Let me explain more...
i wanted to store the marks of students in a auto-generated table using xslt. i made a DCT and using it i made many dcr(one dcr for one student) so that, each student's data is stored in a row of the table . Now, suppose the table contains the all students data. and I want to disable the new form entry, so that no one could make any entry in the table.

Find more posts tagged with

Comments

Adam Stoller

I have made several DCR's from a DCT. Now, i want to disable the new form entry. How can i do it??

Let me explain more...
i wanted to store the marks of students in a auto-generated table using xslt. i made a DCT and using it i made many dcr(one dcr for one student) so that, each student's data is stored in a row of the table . Now, suppose the table contains the all students data. and I want to disable the new form entry, so that no one could make any entry in the table.

Well, you could either remove it from the templating.cfg or embellish the entry in templating.cfg to severely restrict access to it.
There may be some situations in which the above doesn't quite work.
The more drastic alternative (perhaps in conjunction with the above) is to rename the datacapture.cfg file (e.g.: datacapture.config) such that FormsPublisher won't recognize it and thus won't be able to let anyone create DCRs of that type.

Note however, especially in the case of the 'alternative' - you also won't be able to view the DCRs that exist at that point.

Bhargav Coca

I am not sure if this ws the same kind of request you posted few days back regarding generating html from different DCRs. I do not know whow you have implemented that.

You are talking about student records here, I would use just one DCR with a Contain replicant of students records and generate html from this DCR.

Here i can set the max limit of the replicants and no new replicant can be added by other user, and it would be easy to change in thing in any students record.

Here you do not need to disable anything in templating.cfg.

hth

Adam Stoller

I am not sure if this ws the same kind of request you posted few days back regarding generating html from different DCRs. I do not know whow you have implemented that.

You are talking about student records here, I would use just one DCR with a Contain replicant of students records and generate html from this DCR.

Here i can set the max limit of the replicants and no new replicant can be added by other user, and it would be easy to change in thing in any students record.

Here you do not need to disable anything in templating.cfg.

hth

True - and if you're talking about 25 or fewer students it might not be bad, but if you're talking about 100 or more, or possibly even 50 or more students, the single DCR could become quite unwieldy (between 25 and 50 it's kind of "iffy")

If you're doing the single-dcr design, you'd want to use FormAPI to change the labels of the replicants to the student's name or id or something, otherwise it becomes rather difficult to find a particular student's records to update them (granted, that would have been before you wanted to disable updating of the DCR).

sanks

I am not sure if this ws the same kind of request you posted few days back regarding generating html from different DCRs. I do not know whow you have implemented that.

You are talking about student records here, I would use just one DCR with a Contain replicant of students records and generate html from this DCR.

Here i can set the max limit of the replicants and no new replicant can be added by other user, and it would be easy to change in thing in any students record.

Here you do not need to disable anything in templating.cfg.

hth

actually, it is compulsory(there is some requirement) to make a dcr for each student.

Bhargav Coca

What is that some requirement? If you would like to share, cuz I do not understand the whole requirements here. If their requirement is onetime thing to create a student record and once in a while they go in there to update one record. I wouldn't even use TeamSite for such a requirement. I would rather give them a static page and ask them to maintain in static html.

It not worth changing configs to enable DCT when ever they want to add or modify records.

Just my opinion.

Adam Stoller

What is that some requirement? If you would like to share, cuz I do not understand the whole requirements here. If their requirement is onetime thing to create a student record and once in a while they go in there to update one record. I wouldn't even use TeamSite for such a requirement. I would rather give them a static page and ask them to maintain in static html.

It not worth changing configs to enable DCT when ever they want to add or modify records.

Just my opinion.

It's not that unreasonable IMO - just guessing at the use-case scenario:

Over the course of time you would have versioned records of the students' data but (for some reason) they want to have periodic "freeze" times in which the records cannot be updated.Again, that's just a guess at the overall design specs - but it would seem to fit the information provided thus far.Is it the best design? Probably not but I don't think it's the worst design either.Is it the best use of TeamSite / FormsPublisher? Possibly not, but I think that's debatable - I'm assuming they already had TeamSite and that it wasn't just purchased for this purpose - as such it's making use of a tool they've already paid for and have in-house - which tends to make it more (rather than less) reasonable.

Bhargav Coca

[QUOTE=ghoti]It's not that unreasonable IMO - just guessing at the use-case scenario:

I concur Adam.We don't know the requirements word to word from the manger on this, so all we can do is assume.I know few people use TeamSite as a report repository, nothing else. For the Price you pay for the tool, you need to use atleast 50% of its functionality to make it worth it. Well its not my Money, Good for HP.

ShashankJain

Guys, Why are we teaching anyone how to use teamsite ? It is one's choice to use the money spent or not.

For the question initially asked, the answer is no. We can not disable New Form Entry.

ISCBorisB

We can not disable New Form Entry...

Of course you can, in many ways.

You can remove "New Form" Entry from the menu. You can *remap* TS command behind "New Form" to
a custom one that will allow/block new Form rendition by whatever criteria you need. You can
hack JSP that New Form Command is mapped to. You can recognize "New Form" within blocked Type's
FormAPI, show warning and close the window. You can... - I hope you've got the picture