[Last Call] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 203
  • Last Modified:

restricting user from editing doc.

I'm developing a workflow app. wherein a doc. moves from one dept. to another. what i want is that only dept "a" could create it and when he submits  it should move to dept "b". now he should only be allowed to edit the doc. and not delete it. No other person can edit it. Again when he submits it should move to dept "c". now again he should only be allowed to edit the doc. and not delete it. No other person can edit it.

How can this be achieved.

Thanx in adv.
0
ramakrishna030399
Asked:
ramakrishna030399
  • 5
  • 3
  • 3
  • +1
1 Solution
 
PaebdbCommented:
By using Roles for the departments. When a doc is submitted to the next department, fill a author field in the doc with the role of the next department.
And make sure that the roles dont have the right to delete docs in the ACL
0
 
ruth873636Commented:
ramakrishna,
You can accomplish this using the ACL and an Authors field in the form whose value is changed during the routing process.

However, you will not be "Moving the document" to the different depts, but rather, bringing them to the document when it is "their turn" to see it. (Using @MailSend with parameters to notify them, and a DocLink to 'bring them to it').

When Dept A "Submits" it, there can be code in the Submit button so that it changes the value of an "Author data-type" field (Authors) to a group name (Dept B). Now the only people that can Edit the document are people in the Group "DeptB" (in the ACL). The same process is used when DeptB submits the document to DeptC, the calue of the Author field can then be changed to DeptC. etc...
You will have to use some criteria matching to determine what value to change the field to each time the Submit button is pressed (perhaps a status field of sorts) OR create 3 separate buttons and use the hide-when functionality to disply only the correct Submit button at the appropriate time.

Note: Make sure that the 3 groups are listed in the ACL, and that the "Delete" checkmark is NOT GIVEN, and they wont be able to delete the document.

0
 
PaebdbCommented:
Ruth, could you please explain me the difference between your answer and my comment, beside that you elaborated the same thing with more words ?
0
Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

 
HemanthaKumarCommented:
Hi

Remove the "Delete Documents" access
in the database ACL for the person/group who are going to review/edit it.

While doc is being sent to next reviewer, replace the current user name with that of reviewers name in the authors field.


Good Luck
~Hemanth
0
 
ruth873636Commented:

Paebdb,
#1 - I did not mention using Roles, here is your statement:
"By using Roles for the departments".
I do NOT recommend Roles, as they are only a deterent to security, and not an actual security measure.

#2 -
In addition, you mentioned to "make sure that the roles dont have the right to delete docs in the ACL".
I believe you are confusing ROLES and GROUPS, as you cannot allow or disallow ROLES from deleting documents. Only the Groups or Individual names in the ACL list itself can be given that access. ROles are located in the Bottom Right corner of the ACL screen... Different from Groups.

Ruth




0
 
ramakrishna030399Author Commented:
hi,
i agree to all of you but the thing is as i change the value of the author field of a doc. and save the doc. in the submit action of a button, it dispalys me a dialog box asking to save the doc. which i don't want.

my code is:
FIELD Authors:="b";
@Command([FileSave]);
@Command([FileCloseWindow]);

i want the doc. should get saved without prompting to save.


thanx in adv.
0
 
ruth873636Commented:
You can try these for your save action:

temp:= @Command([FileSave]) ;
@If (temp;@Command([FileCloseWindow]);"")

-or-

@Command([FileSave]);
FIELD SaveOptions := "0";
@Command([FileCloseWindow]);

-or-

if you like the @SetField function:

@Command([FileSave]);
@SetField("SaveOptions"; "0");
@Command([FileCloseWindow])

0
 
ramakrishna030399Author Commented:
Thanks Ruth,
 The way u specified is working fine...but as i'm changing the value of the author field with the name of the other dept who will be receiving the mail and only who will only be allowed to edit it. Its not allowing me to save the doc. as since the author field now does not consist the name of the current user. If i keep the name of both the current user and the next user in the authors field its working but the current user is also allowed to edit which i don't want as since once approved he should not be allowed to edit the doc.

Again this thing is not working on the Web. Is it that the Authors field does not work on the Web b'cos when i'm clicking on the Edit Action of the doc. it asks me for the password filling upon which gives me authetication failure error. This person exisits as Author in the ACL and also in the authors field of the doc.

0
 
HemanthaKumarCommented:
Hi Ramakrishna

In the form apart from the "main authors" field have one more authors field which will be Computed For Display field with @username as the default formula. The user can create a document and assign some one as the author, save it and exit. Works fine.

As far as the web goes, you should force the user to login with his http password.

Good Luck
~Hemanth
0
 
ruth873636Commented:
ramakrishna
#1 -  Lets say you have 2 author fields.
Author1 has the current user's name in it (Mary) so they are allowed to save the document, and Author2 has the name of the group/person (John) that it will be going to next.

When the next user (John) opens it to edit it, you can have a formula in the PostOpen event of the form that looks at the Current user, sets the value of Author1 field to (John) the current user and then sets Author2 field to the next group/user's name (Tom).

This kind of reminds me of the concept of a Chain letter... but it sounds like it'll work.
0
 
ruth873636Commented:
ramakrishna - I forgot to address issue #2, the login.

You have to have people login for the Author fields to work, when people do not log in, they are seen as "Anonymous", not their real names or groups they belong to.
To do this,
1) set the ACL of the database so that Anonymous has "No Access", then
2) make sure each person that will be accessing using a browser has an "Internet Password" in thier Person document. The ID files are NOT used when accessing from a browser.
0
 
ramakrishna030399Author Commented:
Well Ruth,

I have tried all this. as far as Anonymous user is concerned i have given it as Reader Access as since any one can read docs. but when editing only the user whose name is specified in the Authors field should be allowed to edit it. So when the user clicks on edit action it asks for username and password, filling in the correct login and password it does not autheticates. It again asks for the username and password. The inernet password is also provided for the user.
0
 
HemanthaKumarCommented:
Hi ramakrishna

The user should be entering wrong id, it is always adviced to use the shortname for user id.

Did my solution that I proposed worked for you ?

ruth's  proposed solution is good, but the problem is until the user "john" opens the document, "mary" will have the edit access. Ruth do u agree with me !


~Hemanth

0

Featured Post

Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

  • 5
  • 3
  • 3
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now