setting different default values for access status for different user profiles

ebarthel

Hello,
I would like to set different default values for the access status variable for different users/roles. The variable is taken from a list at the system level and the default is set for this list. Is there a way to set the default value at user/role level ?
Thanks a lot !
Etienne

monica

I don't believe there is a way to do what you are asking. You can set it so certain user roles cannot edit this field

ebarthel

Ok, thanks !
The aim is to have the contributions of different catalogers (different roles) to appear separately in different instances of Pawtucket, through an extended range of the access status variable. A quick hack could be to assign the role id to the access status upon saving the ui data. Does anybody know in which file this part of the program is ?
Many thanks.
Etienne

monica

This doesn't sound like the easiest way to have different content on different Pawtuckets. Leave the access field alone and use a different field. You might even be able to use the intrinsic data of the record that records who created it. Or a hidden field that prepopulates the user role.
Another way is to create an object type for each Pawtucket instance and give permissions to each role to only create that object type. If you want to control what people can see, create and edit, then doing it though the record types would make more sense.

ebarthel

Good suggestions. I tried the object type solution filtering in Pawtucket through RestrictToType in Browse and Search and it works well. Is that what you suggest ? The drawback is that you need as many types as fields (objects, entities, representations, etc) x number of catalogers and also the configuration of Pawtucket is somewhat involved.
The access field would do it through public_access_settings = [n] in app.conf which is simpler.
Using the source field would be great but I don't see how I can filter using this variable: am I missing other ways to filter the input into Pawtucket ?
Thanks,
Etienne

monica

This is not really what the platform was developed for (Many different front ends to the one backend based on user/role), so you would need to work out the coding yourself to limit records to given users/group/roles.

How do you keep them from seeing each others records inside providence? I'm sure it could be done, but I am not sure it's going to be a simple solution.

ebarthel

For the type based approach, I use Type-level access control. That solution works, with the drawback noted above.
For the creator based approach, I use Source-level access control, which references the user. If user id could be used to control access in Pawtucket, in addition to the access field, that would do it. No idea if this involves extensive or spot modifications.
Thanks,
Etienne

seth

You can control access to specific records with item level access control. This can be enabled in Pawtucket as well, although I can't say we've ever actually tried it. It's usually a back-end thing.

Item-level ACL controls access to specific record by user or group. By setting global access to a record to "no one" and the letting specific users or groups of users "see" the record you could approximate what you want. An issue is going to be that this is all based on the current user, so viewing these things in Pawtucket would require logins. This could change, but would require some additional options to be added to Pawtucket.

ebarthel

Oh, good ! I'll have a try at this as well.
Thanks !
Etienne

ebarthel

Quick summary in case anybody else has the same needs sometime...
Using source control in the back-end and access control in the front-end also works. The problem of the unique default value of the access variable can be solved by prepopulating the access variable from the source variable (or directly the user_id for sets) upon save as suggested by Monica. However, Pawtucket also needs access to the list values so some sort of public access must be allowed as well.
In the end, for the basic functionalities I tested, source control and type control come out even, although type control looks more native than source control, which feels a bit more hackish.