On Friday, it’s EpiUsers Frideas Day! Have you been to the Epicor Ideas Portal recently? If so, are there some ideas you want to encourage other users to vote for? Maybe want to add comments to an existing idea?
I pushed hard to get attention on this one. This is a big deal. I’m not going to share details here. Please don’t share details outside of the Ideas login walls.
Please increase the kinetic layer description field from x(60) to x(1024).
App studio errors cryptically if you try to save with a layer description greater than x(60).
This layer description field can used in Menu Maintenance and App Studio to see specifics on what the layer changes are.
We need more than 60 characters to document what the changes are. Description seems to be the logical place, rather than the commit notes, which are more difficult to access.
Parity with Classic. Classic makes it easy to see layer descriptions everywhere. We don’t need to click and view each one, like we do in Kinetic. It’s available in the various grids as a field.
The more I work in Grow BI, the more ideas I have … Grow users, please vote!
Currently when I have to rearrange metrics on a dashboard, I zoom way out so my metrics are tiny and I can see a bunch of them at a time. Then I drag and drop.
I’d be worried the implementation of that would be like moving a picture around on a word document, I’d be happier with the ability to select multiple metrics at once so I can move a group of them down and make room.
If you saw the EpiUsers podcast on Security, you’ll see @josecgomez address this. It is really up to the users to set up the security properly. Menu security is nice, but you are not going to have proper security unless you tighten up the field and service security on the business objects.
It might make a good idea to have a way to translate menu security into service/field security so it doesn’t have to be done in two places.
I should have clarified on the Idea. That’s what support recommended. Field security works functions the same way, no difference. Service security cuts off access to the nominal menus entirely.
In service security, you can restrict by the objects method, so only people in a security group can run .Update for example. This would make the object available to users who only run trackers.
Field Security SHOULD work the same, but recently I have seen some fields not enforce the access while others do.
That’s interesting… I don’t think it solves the Idea topic, but I’d be tempted to implement something like that if it could be manageable at scale.
POST’ing new service methods looks plausible.
GET’ing all the available service methods is a minor pain since it’s limited to 100 results. Recursing off of SecCode should get there.
I’m assuming there’s a data source for all of the default UI fields and their default security state. The software is looking that up somehow, which means we can too, somehow.
That leaves the job of identifying the relationship between service methods and form objects. They’re generally trivial to cognitively pair up, but scaling to the entire application requires an unattended method. Is there some kind of reference floating around?
If service method ↔ form objects is a loop that can be closed, that could become a functional path to mapping process security back to navigation rather than the intended other way around. Kinda Rube Goldberg but feasible if it can be managed at scale, at least for reasonably skilled admins.
There is a bug in kinetic where it doesn’t look like field security works because the field doesn’t get disabled in the UI. However the security is actually enforced (values not saved).