Skip to main content
N
nxpet1-Visitor
1-Visitor
December 14, 2018
Solved

Deny creation of document/content items for dynamic group

  • December 14, 2018
  • 2 replies
  • 5678 views

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

Best answer by nxpet

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

2 replies

M
mrump16-Pearl
16-Pearl
December 17, 2018

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

 

    N
    nxpet1-VisitorAuthor
    1-Visitor
    December 17, 2018

    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.

    M
    mrump16-Pearl
    16-Pearl
    December 21, 2018

    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

      M
      mrump16-Pearl
      16-Pearl
      January 20, 2019

      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

       

       

      N
      nxpet1-VisitorAuthor
      1-Visitor
      January 22, 2019

      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.

      N
      nxpet1-VisitorAuthor
      1-Visitor
      February 1, 2019

      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...

      Terms & ConditionsAccessibility statement