If you have questions or if you want to share your opinion about Aware IM post your message on this forum
#51585 by Jaymer
Thu Sep 12, 2019 7:22 pm
Like many places in Aware, there are multiple ways to do things.

Scenario:
I have External & Internal users --- Customers (who can log in) & the owners of the app (the internal, the company).
Of Internal, I have Admin/Mgmt, Sales, Tech.

So do I have 2 Access levels - External & Internal ?
And then, for INTERNAL as an example, control appearance by checking a LISU (LoggedInSystemUser) "Type" field (choices: Admin, Sales, Tech)?
Or do I have 4 Access levels - External, Admin, Sales, Tech?
(of course, I still have Aware's Administrator Access Level)

Now, before you answer that, consider this: One issue with having multiple VPs, is that you now have lots of redundant stuff - and since its not easy to copy things BETWEEN VPs, then you have to make changes multiple times. Like if you made a change to your banner, you have no choice but to make it ON ALL 4 VPs - manually.

Of course, some times you REALLY want to have a different look and feel for a user - so that user type really does need a significantly different VP.
But I'm talking about
Admin - starts with Dash Board, has other tabs open with query data, lots of stuff
Sales - Has 2 tabs showing, different Menus
Tech - Different tabs than others, different Menus

These things can be done using ONLY 2 ACCESS LEVELS (Internal or External) and then Invisibility Conditions to show/hide menus, tabs, options, etc.

BUT IS THAT THE RIGHT WAY TO DO IT? (if so, then why do I have the diff. Access Levels)
In reality, I may end up with 1 or 2 MORE types of External Users (managers, clerk, superusers) and now I'm up to 6 Access Levels.

One thing I know is that if you have 1 VP with lots of TABS, and Invisibility Conditions HIDING the tabs, there's still Code in the HTML in your browser for each TABSTRIP ITEM, even though it may not have executed yet or is hidden. So there's still overhead for having it this way, and of course lots of Conditions to evaluate to display a tab or not.

Since the VPs are "hard to manage and copy between", that might be pushing people to do it "the easy way" - which might not be the "right way". Thats the point of this post. And if thats the case, maybe a push to improve the ConfigTool to handle VPs better makes this issue go away?

jaymer...

PS _ I always go back to thinking that Aware is massive and very functional - and integrating with Kendo (which is massive), for example is VERY COOL, but that doesn't mean Support decided to integrate everything that Kendo could do in the 1st release. There's lots more functionality in Kendo to take advantage of... but not until we ask for it (and push for it). Its not so much that Aware CAN'T do it, just that is DOESN'T DO IT YET. Maybe Visual Perspective Management is like this... just needs some TLC. And recently Sean (Pointswell) mentioned that in a long list of Processes in the ConfigTool Element tree, To add a New Process makes you scroll WAY UP to the parent node to do a New Process, when really, you should be able to click on any Process in the tree and do a New Process. Its now also an issue for me and I'm sure anyone else with a decent sized app. Lets push more for these QOL (quality of Life) issues to help us enjoy doing this a little more than fighting/cursing a current shortcoming in the tool. Support does a great job of responding to our requests... which leads us to The New Wish List Page
#51587 by PointsWell
Thu Sep 12, 2019 11:47 pm
Jaymer wrote:One thing I know is that if you have 1 VP with lots of TABS, and Invisibility Conditions HIDING the tabs, there's still Code in the HTML in your browser for each TABSTRIP ITEM, even though it may not have executed yet or is hidden. So there's still overhead for having it this way, and of course lots of Conditions to evaluate to display a tab or not.


I conducted a similar experiment (but different) whereby I had one do it all Contact record that then showed and hid things (Fields panel operations etc) depending on the type of Contact. This created a ***k-ton of processes running checking things and applying applicability rules. In my experience* it became simpler to have separate BOs and a BOG where necessary because: I am not infallible and sometimes I forget to update a rule and ended up showing something that was not meant to be there and also it felt like it was slowing things down unnecessarily to save some developer time at the expense of user experience.

I would always consider making all of your actions deliberate - don't over re-use things for the sake of development convenience. I have gone the route of separate login Objects for different user types, because I can't accidentally re-use something, I then rely on roles as infrequently as possible because when you have two hundred business objects and eight roles it is incredibly cumbersome to apply roles to BOs.


*not an endorsement of a method, a benchmark or anything other than an anecdote. Your mileage may differ. Filmed using an amateur driver on the open road with no insurance and an almost empty tank.

Who is online

Users browsing this forum: No registered users and 17 guests