Automation of new user configuration details

Hi everyone,

We would like that by defautl, some information are automatically put in the configuration details of every user on this page : ?func=Personal.ChangeAgents&mode=EDIT&report=1

The idea is to have the "Email delivery" and "behavior" automatically selected. And also that the email address of the user is automatically recovered

Furtermore on the "Modify interest" page : ?func=notify.interests we would like that some reports are automatically selected, according to this example.

Is this possible through a live/web report ?

Thanks for your help.

Benjamin

Find more posts tagged with

Note:

If there are Accepted Answers, those will be shown by default. You can switch to 'All Replies' by selecting the tab below.

Accepted answers

All comments

appuq

We used to do that with Oscript, so in a way, perhaps one can create a tag in WebReport. However, it's been a long time, but I believe the system uses the 'Admin' user's settings as a template for all new users. Would it have been possible if you had set Admin correctly and then checked a new user?

Benjamin_Palermiti

Hello,

Thanks for this feedback.

With the 'Admin' user, I managed to define the day/hours/minutes for all users, regarding the default notification schedule, but not the automatic tick for "Behavior" and "Email delivery".

appuq

The reason why we went with the supported "oscript way" is because of two things

The code to make them tick is very easy once you can identify the row for the particular user.
Livelink as it was called then, old name for OTCS , was fairly new to me and everyone else, and tools such as Web Reports were yet to be invented.
The OT code, as it was written, would then basically create a new row for a user only if the user had consciously pushed a change on the page you are showing otherwise it relied on that Admin user's template. Only when a user pressed the submit button would that individual row be inserted. You could find that row and manipulate it, although a supported api like we did is far better.
We were using workflows, and we didn’t want our users to be bothered to be told to set it themselves, and we were particularly interested in that email part, as if it was stored in the interface, the application slowed down for initial login.
In the end we created an agent ( a scheduled oscript job) that, among many other things, incorporated the best practices on notification from memory of 2003 I thinks 1)we scanned notification for inappropriate users who would not set a specific item, but at the enterprise level 2) we looked for new users who hadn’t set their notifications themselves