We recently reorganised the department. This meant changing the access for 120 people across 240 projects. I had hoped to automate this via the API, but then, to my dismay, found that this is not exposed via the API. It took me 5 very boring days to manually do the necessary changes (and some hassle as it meant that some people did not have the correct access for nearly a week). We are planning another big change at the end of the year, so this ability would be very useful please.

Comments

  • This is a huge concern and then I would like to audit, but you can only see the information in the web browser and the excel export seems not to work right either.

  • This shortcoming makes it impossible to scale our organization efficiently. We've resorted to SQL queries to get the user/project/role mapping data out of the DB, but that doesn't help with updates.

  • I couldn't agree more; to scale effectively to larger organizations, one needs a fully-functional API that allows organizations to automate operations via scripts, and to do invariant checking on organizational policies; like if all developers are supposed to be team-members of a given set of projects, it should be possible run automated scripts that check whether this invariant holds or not.

  • Very interested in this feature as well. We are using the API to visualize project details internally in our company and at the moment we have no way of showing what role an assigned member has. Doesn't seem like there is a good reason this feature is not yet implemented.

  • I would like this for a slightly different use-case. I have the need to make a single project available to over 2000 users as observers.

  • Like Sarah, I need to make a project available to a large number of users. Having to set these roles individually, by hand, is error prone and a huge waste of my time.

  • This is a massive waste of time and energy, and really limits our ability to scale VersionOne to a large number of users. We desperately need a scriptable API to change the user's role on versionOne projects - make a user a team member, make a user a project lead, change a user from project lead to team member, remove a user's project specific role so they inherit from above. I am actively lobbying senior managers to punt on versionOne specifically because of its braindead, stone-age API for user management - why not have us write down changes on napkins, scan them in, and fax them to a sweatshop of third world school children to point and click for us. Please fix this before I tell you how I really feel :-)

  • Completely agree with the abover sentiments. User query/administration totally needs to be scriptable

  • As a large company, the lack of this functionality is limiting our ability to automatically provision users. If we can't automatically provision users, we have to look for an alternate solution that provides that functionality.

  • To all the above, I feel your pain. Literally. I have a new project with +1700 users. Not having an API for this is PITA.

  • Over a year ago, this was expressed as a need. But until now, it's the same situation. We got the the same painful process today trying to change the access of hundreds of users to only one project

  • I want to let you know that we've been working on this.

    We are implementing this within our "bulk" api, which supports JSON or YAML input.

    You will be able to do commands like this, for example:


    Assign a single member to a Project, using OID Tokens for Member and Role:

    POST /api/asset:


    JSON version:

    {
    "from": "Scope:1003",
    "execute": {
    "op": "AssignMemberWithRole",
    "args": {
    "Member": "Member:1234",
    "Role": "Role:9",
    "IsOwner": false
    }
    }
    }

    YAML version:

    from: Scope:1003
    execute:
    op: AssignMemberWithRole
    args:
    Member: Member:1234
    Role: Role:9
    IsOwner: false

    Assign MULTIPLE members to a Project using a SubQuery to identify the Member and the Role (this makes it so that you don't have to maintain a cumbersome list of OID Tokens but can specify the match via friendlier search terms like Username or Name, etc.

    JSON version:

    {
    "from": "Scope:1003",
    "execute": {
    "op": "AssignMemberWithRole",
    "list": [
    {
    "Member": {
    "from": "Member",
    "where": {
    "Username": "member1"
    }
    },
    "Role": {
    "from": "Role",
    "where": {
    "Name": "Role.Name'Customer"
    }
    },
    "IsOwner": true
    },
    {
    "Member": {
    "from": "Member",
    "where": {
    "Username": "member2"
    }
    },
    "Role": {
    "from": "Role",
    "where": {
    "Name": "Role.Name'Customer"
    }
    },
    "IsOwner": false
    }
    ]
    }
    }

    YAML version:

    from: Scope:1003
    execute:
    op: AssignMemberWithRole
    list:
    - Member:
    from: Member
    where:
    Username: member1
    Role:
    from: Role
    where:
    Name: Role.Name'Customer
    IsOwner: true
    - Member:
    from: Member
    where:
    Username: member2
    Role:
    from: Role
    where:
    Name: Role.Name'Customer
    IsOwner: false

    Note that, as of now, the SubQuery will only utilize the FIRST result. But, we will also be introducing a reciprocal operation on Member called "AssignProjectWithRole" in which you could identify N members by as complicated a query as you like and then assign them all to the same Project (as long as you're wanting them all to have the same role)

  • I realize the formatting is terrible above, so here is a Github gist with code formatting that shows the examples:

    https://gist.github.com/JogoShugh/e8ad1c01b89ac7adaadb374562a94550

  • I don't particularly care what VersionOne does to implement a resolution for this, but it is an enormous problem (and clearly not just for my company). Manually updating hundreds or thousands of users one at a time is unacceptable.

  • Support for managing a Member's Project Role was introduced in the Winter 2020 release. Details can be found at https://community.versionone.com/Release-Notes-and-Downloads/Winter_2020_Release_Notes