Announcement

Collapse
No announcement yet.

Portal Users

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Portal Users

    For various reasons I am not a fan of a portal solution (I have never seen one live in 15 years of working with various CRM systems). However, I needed to explain it to a client and I had some difficulties to understand it. Why is it necessary to create a user AND connect this user to a contact? Wouldn't it be easier and more logical (and MUCH faster) if I simply added contacts to a special group (role/team)? If all my contacts were to become portal users (because they should see cases for instance) - do I have to create x1000 users? Although they are there already as contacts?

    Somebody please clarify if I missed something....

    ------------------
    Robert Laussegger
    iscon group
    http://www.iscongroup.net
    mailto://info@iscongroup.net

  • #2
    You could have a target list - "Contacts Who Should be Portal Users". This is fed by a Report based on an Account property (has_portal_access) or something.

    Then a workflow creates Users of type is_portal true on a schedule from the result of the Report

    the only issue is you can't choose the report's contact entity from within the workflow, only fields/links of the Contact.

    I'm sure the Espo team have something similar to this to manage access to extensions, either that or custom code which does something similar.
    E.g. this picture:

    Comment


    • #3
      In the picture the 'Created By.Contact' shows where this isn't working. You want to choose just the Contact returned by the report.

      Comment


      • #4
        This is a bit like a scratching my left ear with my right foot (the bug nonwithstanding). If I was to create a workflow then it should look like that: if contact fulfills criteria then enable portal access x. Plain and simple. Or having target lists of type 'portal user' - even simpler.
        ------------------
        Robert Laussegger
        iscon group
        http://www.iscongroup.net
        mailto://info@iscongroup.net

        Comment


        • #5
          The entire auth system would need rewritten to refactor auth out from users and into a shared space. I can see why they went with this approach.

          Comment


          • #6
            I do see this as well. Nonetheless it should be quite simple to pack an approach like your workflow idea (create a DB entry with portal_user = 1 as non selectable user) into a function. Users don't care about technical issues, they just see what works and what doesn*t.
            ------------------
            Robert Laussegger
            iscon group
            http://www.iscongroup.net
            mailto://info@iscongroup.net

            Comment

            Working...
            X