alexisp

Hi Alexis,

The 'organize team' tab serves a couple of functions.  it allows you to create project-specific groups.  it is also the list of people who can be assigned tasks on that project.  when left blank ALL users in the system show up in the drop-down list.  Only those users who are added to the 'organize team' tab can be assigned to tasks from the drop-down.
the 'project access' tab is as it sounds. It controls who has access to the project. sometimes you may have users who you want access to the project but you do not want them assigned to any work.
It is also worth noting that project access differs depending on how your roles are set up.  I want to be clear here that "PRIVATE PROJECTS" are a feature designed to be closer to "Air gapped" within your ftrack workspace.  ONLY users who are EXPLICITLY added to a private project can access that project including administrators and API users.  If you want to have some users with overall visibility on all projects then we recommend using open projects and controlling access to those projects through the Roles and project access.

I hope that helps clear it up a little.  Please let us know if you have any other questions.
regards,
Daniel

Hi @alexisp could you please create an api user with explicit access to the private project and use that api key to create the session ? 
you can find more information in our help page: https://help.ftrack.com/en/articles/3004264-private-projects

hope it helps.
L.

Just for completeness' sake, an ftrack engineer chimed in on the subject, and I'm leaving a link here as a reference:
https://github.com/ftrackhq/ftrack-javascript/issues/73

I made a tool for exploring the API a while back (just remembered to post here after catching a few errors earlier this week), as I was a bit fed up of my old process which was like this:
>>> user = session.query('User').first() >>> print(user.keys()) # Look for a key related to groups >>> print(user['memberships']) # Perhaps this, check if entity or list >>> print(user['memberships'][0].keys()) # It's a list, check what each item has available >>> print(user['memberships'][0]['group'].keys()) # I see group, what keys does that have >>> print(user['memberships'][0]['group']['name']) # Found what I needed (random example though, I've never actually needed this) >>> user_groups = [membership['group']['name'] for membership in user['memberships']]  
I find myself loading it now whenever I'm coding something that I'm unfamiliar with, so just sharing here in case anyone else would find it useful.
https://github.com/huntfx/ftrack-api-explorer
 

This is exactly what I needed !
I could not have come up with this by myself 🤓 !
Thx @Lorenzo Angeli !

Hi @alexisp, 
at the moment there's no direct call from the api to get the review session url, but can be "easily" generated with the following snippet:
 
import ftrack_api session = ftrack_api.Session() # Retrieve the Review Session you are interested in rs = session.query('ReviewSession').first() # Ensure the shareable link is enable rs['shareable_url_enabled'] = true session.commit() # Get the signed url from the server signed_data = session.call([{'action':'generate_signed_url', 'entity_key':[rs['id']], 'entity_type':'ReviewSession'}]) # Compose the review url shareable_url = '{}/review/{}?signature={}'.format(session.server_url, rs['id'], signed_data[0]['signed_url']) print(shareable_url)  
hope it helps.
L.

@Jason Porath  I found quite fine running running unit and functional tests on test projects right on production server. It is quite easy to construct any context with ftrack_api and release it after tests finished. In worst case you will got a bunch of test entities on test project that no one cares.
so feel free to:
@pytest.fixture def session():     return ftrack_api.Session()   @pytest.fixture def context(request, session😞     context = session.create('Folder', {'parent_id': ..., 'project_id': ..., 'name': ...})     def finalizer():         session.rollback()         session.delete(context)         session.commit()     request.addfinalizer(finalizer)     return context The better approach is to running tests on staging ftrack server that should have relative fresh database snapshot from production, that is much more complex.