[AccessD] Ribbon getVisible issue

Ryan W wrwehler at gmail.com
Wed Apr 14 08:51:09 CDT 2021


Thanks for fleshing this out guys.. I came up with an idea that seems to
work.

I set an AUTOEXEC macro to set TempVars!hasLinked=0

Then my getvisible requires hasLinked=1 to run my code to go get the
permissions out of the remote table.   TempVars!HasLinked is set to 1 if my
linking code completes without error and I invalidate the entire ribbon
when the MainMenu form opens up.

Don't know why I didn't think of something like that before.



On Wed, Apr 14, 2021 at 7:30 AM Ryan W <wrwehler at gmail.com> wrote:

> The table re-linking is based on the user ID being logged in, and
> unfortunately the ribbon callbacks happen before my modal login form even
> loads, let alone they enter their username and password.
>
> I think the most simple solution as much as I hate it is to replicate the
> remote permissions table locally so I can use that without relink issues.
>
> Sent from my iPhone
>
> > On Apr 14, 2021, at 1:39 AM, Bill Benson <bensonforums at gmail.com> wrote:
> >
> > I wasn’t using Access but I did have a getVisible callback in Excel that
> > used (initially) an ini file found on the user’s hard drive to see what
> > “favorite” controls should appear in a favorites menu on the ribbon.
> >
> > So I know it is possible to get a lot of work done during the execution
> of
> > the callback itself. Can you possibly do the needful table re-linking
> > within the callback?
> >
> >> On Tue, Apr 13, 2021 at 3:53 PM Ryan W <wrwehler at gmail.com> wrote:
> >>
> >> Hey all, Sorry to bombard the group so much... I'm in active development
> >> again and sometimes.. I just can't figure out the issue.
> >>
> >>
> >> So I am attempting to call a function to determine if a ribbon group is
> >> visible. This function goes out and checks the roles the user calling
> the
> >> function has.
> >>
> >> The problem becomes, the ribbon initializes before my relinking
> procedures
> >> do... so if I call the function to get the roles, it's calling it with
> >> cached or 'old' stale credentials in some cases.  I can see with exec
> >> sp_who on the back end the handle stays open with my test username
> >>
> >> So because that SPID is held open, the query will return my elevated
> >> privileges for an unprivileged user.  This ONLY seems to be the case if
> I
> >> try and use the function on the remote table for ribbon manipulation.
> >>
> >> Here's an image of the user BTJ logged in, but the SPID being held on
> the
> >> SQL side is my username / spid (I was the last one to log in, before
> >> logging in as BTJ).
> >>
> >> https://i.imgur.com/9SsE1Dz.png
> >>
> >> Unless there's a fix for this that makes sense I may have to make a
> local
> >> permissions table so that the ODBC connection string doesn't impact
> these
> >> tables before my refresh links code fires.
> >>
> >> Hope that makes sense?
> >> --
> >> AccessD mailing list
> >> AccessD at databaseadvisors.com
> >> https://databaseadvisors.com/mailman/listinfo/accessd
> >> Website: http://www.databaseadvisors.com
> >>
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > https://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
>


More information about the AccessD mailing list