Deny creation of document/content items for dynamic group

[nxpet]

Hi there,

I created a read-only dynamic group "Read-only Members", which must not be allowed to change or add items in a project. For the requirement document and content item I changed the item editability to: User is not member of "Read-only Members". This works only for existing items. Problem is, that the users of "Read-only Members" are still able to create a new document and create a new content item inside an existing document. How can I deny this as well for the group?

Thanks, Timo

[mrump]

Hi, 

depending on your usecase, you have 2 options to solve this:

A)

modify the state-transition in your requirement document and content item's workflow.

The transition from "unspecified" to our item's initial state(s) must not be allowed for your "Read-only Members" group. To do this you will need a "Create-Allowed Members"  group, as transitions can only be ALLOWED, not DENIED. A dynamic group is not an option, as the project to determine the group members is not "available" during item creation.

B)

create a custom rule based pre-event trigger.

the rule that identifies "item create events" is a change in the state field where the old state is "unspecified" and  the new state is your "initial State" (e.g. "new")

((field'["State"] = "new") and (field["State"] = ""))

In you script code simply check the whether the current user is member of your "read-only Members" group and if so abort the script with a message.

HTH Matthias

[nxpet]

Hi Matthias, thanks for your help. The option B with the trigger sounds better for me, since I do not need to define additional groups.

One further question: since the read-only group is a dynamic group (per project) one user could be read-only in Project X but read-write in Project Y. When creating an item, does the trigger script "know" the project where it will be created? For your option A you said that, the project is not "available" during item creation.

[mrump]

When creating an item the trigger script DOES "know" the project where it will be created (as long as the project field is mandatory) as the Project is a "NewFieldValue" like all others in the issueDeltaBean.

HTH Matthias

[nxpet]

Hi Matthias, I am thinking of switching to your solution A) since I still have the error in my script.

Lets assume I have a "Create-Allowed Users" dynamic group and the workflow for a Requirements is only: Unspecified ---> Active. Then I restrict the Transition from Unspecified to Active to the "Create-Allowed Users".

This doesn't work because the project in not yet defined in the state Unspecified, so someone who is NOT in the "Create-Allowed Users" dynamic group would be able to create a new requirement in a document?

[mrump]

IMHO nobody would be able to create a requirement at all, if you set up your workflow as described.

A dynamic group in the workflow depens on the project field to have an "existing" value.

An Item (of any type) in state "unspecified" does not "fully exist" yet and therefore the project field cannot be analyzed to define the members of a dynamic group. Hence the dynamic group is always empty.

[nxpet · Accepted solution]

Hi Matthias, I finally solved the problem using the script you provided here before (posting is now gone for unknown reason).

I had to change the

projectname = delta.getProject();

to

projectname = delta.getNewProject();

An then, as you said, the trigger rule must exclude all item that do not have a project (e.g. shared requirement).

Thanks a lot for your help!

Timo

[mrump]

Hi Timo,

depending on you Integrity version in use, there might be another option for you usecase:

Have you ever thought about "document locking" ?

This feature is only available in the document model, so less generic that the trigger script approach.

The general idea is to apply the "Lock before Edit" concept from SI to documents as well. It enforces a user to first get a Lock - meaning ensuring exclusive edit permission - on a document before the user can save any change. When the user is done he can release the Lock and allow other users to get it. This switches the editing of documents practically to a sequential instead of a parallel mode.   

There is a section in the document item type config gui that allows you to define which users are allowed to get a Lock on a document. It is either

- a fixed list of users

- a fixed list of groups (not dynamic)

- the current value of a certain field in the document 

Unfortunately there no way to define a inverted selection , so you cann defien you Read-Only-Group but have to set the "Write-Allowed".

Maybe it is worth a thought.

HTH 

Matthias

[nxpet]

Hi Matthias, thanks for that idea. Since we sometimes work in parallel on the same document, it doesn't seem a solution for us.

The main idea of this read-only group is, that we want to give read access to users, who are only interested in viewing the documents/requirements within a project. Usually they do have very little knowledge about Integrity. In order to avoid, that they unintentionally change or add something, we want them to put in a read-only group.

I will check the code, that you have provided, as soon as I find some time for reviewing/testing.

[nxpet]

What happened to the rest of the postings? There were more postings after last one shown here?? Have they been deleted?? Can some of the forum admins please have a look, why postings are missing?

Problem is still not solved...