New post
2

Non-login "People"

Avatar
Pliny (John Eremic)
Completed
Follow

Talked about this one with Don a few months ago.  The idea was to create a "Person" entity records that would not log in.  I had a certain function in mind, but since then I've found an even more mundane reason: contact lists.

We are importing client lists into SG, and decided against creating a custom entity for tracking them.  After all there already is a "Person" entity in the database;  why re-invent the wheel in a separate table?

We've been importing our client address books with (some) success, but I've found a number of things I'd love to see tweaked to make this work better.  To wit:

  1. Add a "non-login" permission group. Right now I am getting around this by specifying a blank "permission group" field on bulk import.  "No Permission Group" is essentially my ersatz "non-login" type for now.  (Attached Picture 29.)  Ideally I'd love to see user-definable permission groups, but that plays into the larger permissioning functionality discussion.
  2. No email to non-login users - via Notes, etc..  I ensure this by disabling all email optins for these accounts; and by ensuring that none of them are added to projects.  However, having an absolute fail-safe built into the back-end would be nice.  That way we never accidentally copy a client on internal correspondence.
  3. Do not require login or password for "non-login" users.  (In effect, we are treating "People" like our own Open Directory.  And no, I'm not going to request LDAP integration right now!)  Getting around the login/password requirement plays a little bit of havoc with the bulk importer, although there are workarounds.
  4. Finally, do not auto-suggest non-login users on "People" entity fields.  When you have a few thousand records, there are suddenly twenty "Bens".  I only need my artist Ben, not the post coordinator at Focus, or the PR guy from BMG.  (Attached Picture 30.)

Curious whether other SG users are using/abusing the "People" entity in the same way.

 




/attachments/token/lb7dqhjwkarpwt4
/attachments/token/7wxvfhdu4gfccs2
Date Votes

10 comments

  • 0
    Avatar
    Bryan Holland

    I agree.

    A few groups of people need different permissions. I can think of 5 different permission levels now,...

    Contacts for sure.

    I have yet to implement the contacts page yet. I will mull over a solution with your new workarounds, thanks :)

     

  • 0
    Avatar
    Gavin Greenwalt

    We're abusing People for render nodes and render tasks.   A non login person which has different scheduling would be good as well.   Since Render Nodes can work 24/7 and don't need overtime etc they should also be outside of conventional duration estimates.

  • 0
    Avatar
    Don Parker

    Hey guys,

    The 1.10 release coming out this weekend includes a new status on People for "Active" and "Disabled". Disabled people can not log in. We built this so you can close down accounts for people no longer working there while keeping them and the data around in the system.  This will also be useful for managing the number of enabled accounts you'll be charged for each month.  You can disable accounts for folks rolling off projects, or for artists that have not yet started but are needed in the system for scheduling reasons.

    However, this isn't an exact match for your needs.  We didn't think about making sure they don't get notes, but that's a good idea.  And I can see why filtering them out of menus and not having logins/pws would be useful.  Though if they don't log in and if they won't be assigned tasks or notes, maybe this should be another entity?

    On the permission front, we're iterating through screen designs now. We'll be building that out soon!

    Gavin, I'm super interested to learn more about what you are doing with render nodes / tasks.  Can you provide more info?

  • 0
    Avatar
    Sam Bourne

    I recently ran into this as well. We are trying to add a global "Clients" page. I tried initially to use the "People" page and ingnorantly thought I could just save as and delete the users. SG support had to help us out of that one because no one exsisted anymore. Doh!

    What is intruiging to us is the ability to add extra data to a "Clients" page. Things such as FTP info even to Billing Addresses. What would be great is if we could then link a project to a client and this extra data would be entered automatically. I have been trying to find a work around to this, and using a custom entity tool doesn't work because it tries to attach itself to a project.

    Our company does a lot of smaller projects many times from the same client over and over again. Not having to re-enter all the extra client data for each project would save us some time.

  • 0
    Avatar
    Sam Bourne

    Sorry for the double post, but something occured to me right after I posted.

    An issue that larger companies may have is not wanting all that information to be displayed for their minions. Having the data have permissions would help as well. For example, you could hide the Biling Address of client XYZ from everyone but the admins and managers. Just a thought.

  • 0
    Avatar
    Bryan Holland

    bumpety BUMP bump

    ~~~~~~~~~~~~~~~~

    I wonder if a permission level is Client.

    A review or other entity would be a filter for certain levels that need access.

    So if you just sort projects assigned to client A- and they see top line data- no need to hide the other stuff. 

    This would require a Client Template, but a small price to pay to allow "outsiders" to view top line data.

    A SECOND thot would be to assign a "Viewable" at the data structure level- Such as Address and Billing info could have a 

    "See in Profile" or "Viewable" (top line) checkbox, Then filter by: set to Viewable = checked?

    Then build a page only shows that topline view.

    IDEALLY I could go to a window and set New Permissions Level- set all the reads and don'ts and then link to a person, group or column of people.

    But I get ahead of myself.... :)

    ahh to dream.

     

    bryan

  • 0
    Avatar
    Pliny (John Eremic)

    Don - reasons for keeping this all under one entity.

    - A person might be given login permissions at a later date, or even go back and forth.  Example: a professional contact who becomes an active contractor or even employee.  Likewise, if any client-facing features are ever implemented, this will make it easier to just flip a "person" from non-login to login.

    - Taxonomy is cleaner.  Why duplicate an otherwise identical entity?

    The Active/Disabled feature is a fantastic upgrade for right now, even if other features (like filtering out non-login people) will follow later.  Thanks.

  • 0
    Avatar
    Pliny (John Eremic)

    Sam,

    Agreed that some fields need to be hidden from some employees.  In my case, it's thinks like POs, legal forms (incurance certs etc.) and billing rates.  I believe something like this might be in the works for a future release, since more granular permissioning has been a topic of much discussion on this board.

  • 0
    Avatar
    Sam Bourne

    I've been able to create a type of client page using the custom non-project entity. By modifying the projects page I was able to link the info from my clients into each project. So now when I create a project, I select a client (Client must exist prior to project creation) and info that I entered into the client displays on the project. As of now the only data I'm linking is some text fields like ftp info, but it seems like you really could set it up however you would like. Of course this is a hacked together version, but it's working. I still think that a more streamlined approach to dealing with Clients is important.

    We've also decided not to import our contacts as non-login people. Quite frankly it just seemed a little redundant to have them in our e-mail contact lists as well as on SG and wasn't worth our time yet. Perhaps if SG had an easier way to import CVS files, although the bulk importer would probably work after opening the CVS files in excel... hmm... I might have to try that and get back.

  • 0
    Avatar
    KP

    As mentioned previously, the ability to set users as 'Disabled' was released as part of v1.10 (link to release notes here https://support.shotgunsoftware.com/entries/60043-1-10-release-notes-and-patch-log-production).

    And in v1.13 we have added a UI to our permissions framework (link to release notes https://support.shotgunsoftware.com/entries/164990-1-13-release-notes). 

    We haven't put a UI in place to allow you to toggle on/off disabled users from the autocomplete UI just yet but the framework is there in the backend. We'll get to that shortly. Going to call this one done for now based on the initial request. If there's pieces of this thread you're still looking to have implemented though, feel free to start a new one!

Post is closed for comments.