Get file permissions

Get file permissions

ppauleSHGR6
Enthusiast Enthusiast
514 Views
8 Replies
Message 1 of 9

Get file permissions

ppauleSHGR6
Enthusiast
Enthusiast

Hi everyone,

 

is it possible to check, if a specific user has the write permission for a specific file it its current life cycle state?

I'm writing a C# add-in for Vault Professional 2023 and I would like to check if a user is allowed to edit a file or not.

 

ppauleSHGR6_0-1741771474715.png

 

For my general understanding, I need to check several things:

1. Is the user directly listed in the security tab of the lifecylce state?

2. Is the user member of a group which is listed in the security tab of the lifecycle state?

3. Is the group "Everyone" listed in the security tab of the lifecycle state?

4. Does the found group/user permission have the write permission?

 

I wasn't able to find a way how to access these permission for a specific lifecylce state.

 

Any help is very much appreciated.

Thank you!

0 Likes
Accepted solutions (1)
515 Views
8 Replies
Replies (8)
Message 2 of 9

Markus.Koechl
Autodesk
Autodesk

What is the primary objective to be solved? Should we add a check that the current user can edit the file in general? You could achieve this for any lifecycle and state without knowing the particular behavior configuration. 

1) Check that the file is not cloaked (this means the file is not only returned by the API but also visible for the current user). 

// Autodesk.DataManagement.Client.Framework.Vault.Currency.Entities Namespace > FileIteration Class : IsCloaked Property
mFileIt.IsCloaked == false

2) Check that the file is available for check-out or has already been checked out to the current user.

                    EntityStatusImageInfo mStatus = conn.PropertyManager.GetPropertyValue(mFileIt, mVaultStatus, null) as EntityStatusImageInfo;
                    if (mStatus.Status.ConsumableState == EntityStatus.ConsumableStateEnum.LatestConsumable)
                    {
                        // start the edits
                    }

 



Markus Koechl

Solutions Engineer PDM, Autodesk Central Europe
0 Likes
Message 3 of 9

ppauleSHGR6
Enthusiast
Enthusiast

Hi Markus and thanks for your reply.

My overall goal is to check if the currently logged-in User is allowed to edit document properties via the "IExplorerUtil".

 

I have this code:

 

 

Connection connection = new Connection(m_serviceManager, vaultName, m_serviceManager.AuthService.Session.User.Id, serverName, AuthenticationFlags.AutodeskAuthentication);
IExplorerUtil m_vaultExplorer = ExplorerLoader.LoadExplorerUtil(serverName, vaultName, m_serviceManager.AuthService.Session.User.Id, connection.Ticket);
m_vaultExplorer.UpdateFileProperties(file, propertyValues);

 

 

And I want to catch all cases that could cause the function "UpdateFileProperties" to fail before it is called.

Does it make more sense to work with try/catch and handle the different exception types and error codes?

 

I decided for this approach since I am working in an interface application which is transferring item data from an ERP system to Vault and also tries to update file properties if the item has a linked model and/or drawing and my experience with the "UpdateFileProperties" method is, that it only throws a very general exception that just says something like "Properties could not be updated", but never gives me a specfic error code or reason.

 

Thank you!

0 Likes
Message 4 of 9

Markus.Koechl
Autodesk
Autodesk

It makes sense to pro-actively handle the availability for edits before calling a property update instead of using try/catch. But instead of evaluating all behavior settings, validating that the current user can check out for edits is more efficient. You could do this as suggested in my previous answer; it will return detailed information why a file is not available for check-out/property update.



Markus Koechl

Solutions Engineer PDM, Autodesk Central Europe
0 Likes
Message 5 of 9

ppauleSHGR6
Enthusiast
Enthusiast

Appreciate your reply, thank you.

 

I looked up everything about the EntityStatus class and still have questions about it.

I understand that I can see if the file is locked or checked-out by another user - that's good.

 

What exactly does the "ConsumableState" tell me?

The SDK docs say: Gets or sets the state which describes if the entity on disk is the latest consumable entity.

 

Why do I need to check that? Is the state on the disk important? Doesn't the "IExplorerUtil.UpdateFileProperties"-method handle everything required around the property update (like check-out and check-in) by itself?

 

Is there something else I need to check before trying to update the file properties?

 

Thank you very much.

0 Likes
Message 6 of 9

Markus.Koechl
Autodesk
Autodesk

The ExplorerUtil.UpdateFileProperties method executes all required steps, including check-out/-in. However, you asked how to identify more details for reasons if it fails. The consumable state is the most precise information that the current user can check out and edit a file; it even differentiates a check-out to the current user on a different machine. As mentioned earlier, the entity status info evaluates the result of the current access control without the need to read all the lifecycle or object-based security.



Markus Koechl

Solutions Engineer PDM, Autodesk Central Europe
0 Likes
Message 7 of 9

ppauleSHGR6
Enthusiast
Enthusiast

Hi Markus and thanks for your reply.

 

I tested your mentioned code and either I still don't quite understand the purpose of the consumable state for my goal or I do it wrong.

Now I wrote a method that checks for the following things before the file is updated via the "ExplorerUtil.UpdateFileProperties" method:

 

  • Is the file checked out by another user (yes, I saw I could also do this with the help of the EntityStatus class, but I anyways want to get the username for a more detailed output message)

 

 

if (file.CheckedOut)
{
	if (file.CkOutUserId != m_serviceManager.AuthService.Session.User.Id)
	{
		User ckOutUser = m_serviceManager.AdminService.GetUserByUserId(file.CkOutUserId);
		errorMessage = $"File is checked out to another user -> {ckOutUser.Name}";
		return false; // file cannot be edited
	}
}​

 

 

  • Is the file in obsolete or released state

 

 

LfCycState fileState = m_serviceManager.LifeCycleService.GetLifeCycleStatesByIds(new long[] { file.FileLfCyc.LfCycStateId }).FirstOrDefault();
if (fileState.ObsoleteState || fileState.ReleasedState)
{
    errorMessage = $"File is in non editable state -> {fileState.DispName}";
    return false; // file cannot be edited
}​

 

 

  • Is the file locked (this is probably already covered by checking the lifecycle state for "obsolete" and "released"?)

 

 

PropertyDefinitionDictionary propDefs = connection.PropertyManager.GetPropertyDefinitions(EntityClassIds.Files, null, PropertyDefinitionFilter.IncludeAll);
PropertyDefinition mVaultStatus = propDefs[PropertyDefinitionIds.Client.VaultStatus];
FileIteration mFileIt = new FileIteration(connection, file);
EntityStatusImageInfo mStatus = connection.PropertyManager.GetPropertyValue(mFileIt, mVaultStatus, null) as EntityStatusImageInfo;

if (mStatus.Status.LockState == EntityStatus.LockStateEnum.Locked)
{
    errorMessage = "File is in locked state";
    return false; // file cannot be edited
}​

 

 

  • Is the file in the consumable state "EntityStatus.ConsumableStateEnum.LatestConsumable"

 

 

if (mStatus.Status.ConsumableState != EntityStatus.ConsumableStateEnum.LatestConsumable)
{
    errorMessage = "File is not in consumable state";
    return false; // file cannot be edited ???
}​

 

 

Following CAD documents that are checked-in don't return the consumable state "EntityStatus.ConsumableStateEnum.LatestConsumable" but I expect that these documents would have been updated without problems via the "ExplorerUtil.UpdateFileProperties" method:

ppauleSHGR6_0-1742215267813.png

ppauleSHGR6_1-1742215379293.png

 

Documents that are released and locked also return the consumable state "EntityStatus.ConsumableStateEnum.Unkown", that's why I check specifically for the lifecycle state and lock state.

 

So far I don't see the benefit of checking the consumable state or I'm misunderstanding you in general.

What do I understand wrong?

 

Thank you for your assistance!

0 Likes
Message 8 of 9

Markus.Koechl
Autodesk
Autodesk
Accepted solution

I am sorry for leading you in the wrong direction with the consumable state; this is irrelevant as you are not downloading a file for edits rather than updating metadata only. Anyway, I would recommend using this cascade:

- Check that the file is not cloaked (means it is read accessible as a minimum, and to avoid subsequent calls to fail)

- Check that the file is not locked by leveraging the EntityStatusImageInfo Lockstate. (it will return a reliable result of any life cycle state, not only for states having the Obsolete/Released flag)

- check that the file is available for check-out. An unlocked file that another user has not checked out should be available.
I hope having clarified now. I appreciate your patience.



Markus Koechl

Solutions Engineer PDM, Autodesk Central Europe
0 Likes
Message 9 of 9

ppauleSHGR6
Enthusiast
Enthusiast

Then I understood everything now and I achieved everything I needed.
Thank you for your clarification, your assistance is very much appreciated. 👍

 

0 Likes