*** a42niem has joined #idempiere | 05:35 | |
*** CarlosRuiz has joined #idempiere | 06:41 | |
*** nmicoud has joined #idempiere | 06:42 | |
*** a42niem has quit IRC | 07:08 | |
*** dagelf has quit IRC | 07:36 | |
Not-6102 | [IDEMPIERE] nmicoud created IDEMPIERE-3372 Check access before opening Info Windows | 08:13 |
---|---|---|
Not-6102 | [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-3372 | 08:13 |
*** dagelf has joined #idempiere | 08:19 | |
Not-6102 | [IDEMPIERE] nmicoud updated IDEMPIERE-3372 | 08:31 |
Not-6102 | [IDEMPIERE] I thought it would be an easy one... In InfoManager.create(Lookup, GridField, String, String, String, boolean, String), AD_InfoWindow_ID is always equals to 0, even when lookup is an instance of MLookup. So I don't see where the access can be controled. As we know the tablename, could we try to find an active record from AD_InfoWindow_Access for current role related to the tablename. And if it doesn't | 08:31 |
Not-6102 | exists, return null ? Any idea ? Thanks, Nicolas | 08:31 |
Not-6102 | [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-3372 | 08:31 |
*** jdpaniag_ has quit IRC | 10:08 | |
*** jdpaniagua has joined #idempiere | 10:14 | |
Not-6102 | [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-3372 | 12:03 |
Not-6102 | [IDEMPIERE] [~nmicoud], if a user is disallowed to use the info window from a field, how does it search for records? | 12:03 |
Not-6102 | [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-3372 | 12:03 |
Not-6102 | [IDEMPIERE] nmicoud updated IDEMPIERE-3372 | 12:08 |
Not-6102 | [IDEMPIERE] I would say that if he is not allowed to open the info window, he is not allowed to search for records. (same as access which are checked on process. If you can't run the process, a error popup says "you can't execute process ABC") | 12:08 |
Not-6102 | [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-3372 | 12:08 |
Not-6102 | [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-3372 | 13:00 |
Not-6102 | [IDEMPIERE] But that would make the field useless. Is not better in such case to make it read-only for that user? | 13:00 |
Not-6102 | [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-3372 | 13:00 |
Not-6102 | [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-2889 | 13:02 |
Not-6102 | [IDEMPIERE] [~hieplq], that sounds useful in some cases. But I think not for core, the way to match PO with Receipt is different depending on business cases. That link can be even destroyed and recreated (deleting the match po record and matching again). | 13:02 |
Not-6102 | [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2889 | 13:02 |
Not-6102 | [iDempiere] CarlosRuiz_globalqss pushed 1 commit to release-4.1 [+0/-0/±1] https://bitbucket.org/idempiere/idempiere/commits/ | 13:03 |
Not-6102 | [iDempiere] hie...@hasuvimex.vn 348a437 - IDEMPIERE-3371:amount in word get wrong when parse for multiple of 1000 on Viet Nam | 13:03 |
Not-6102 | [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-3371 status set to "Resolved" -assignee set to "hieplq" -resolution set to "Fixed" | 13:03 |
Not-6102 | [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-3371 | 13:03 |
Not-6102 | [IDEMPIERE] nmicoud updated IDEMPIERE-3372 | 13:08 |
Not-6102 | [IDEMPIERE] Sure, result would be the same. But in my case, i have several windows/fields to manage, and i prefer to avoid having difference inside windows for a specific role, it's harder to maintain (i already have difference between tenants - SAAS environment). That's why i was looking for another solution, and that's how i found this bug :) | 13:08 |
Not-6102 | [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-3372 | 13:08 |
Not-6102 | [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-3372 | 13:16 |
Not-6102 | [IDEMPIERE] I think is not a bug - the info windows were the way to search before the menu info windows existed. So, I think there is a reason to allow searching when the user has access to the field. | 13:16 |
Not-6102 | [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-3372 | 13:16 |
Not-6102 | [IDEMPIERE] nmicoud updated IDEMPIERE-3372 status set to "Resolved" -resolution set to "Won't Fix" | 13:18 |
Not-6102 | [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-3372 | 13:18 |
Not-6102 | [IDEMPIERE] nmicoud updated IDEMPIERE-3372 | 13:19 |
Not-6102 | [IDEMPIERE] [~carlosruiz_globalqss], I will put fields in ReadOnly and it will solve the issue. Thanks, Nicolas | 13:19 |
Not-6102 | [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-3372 | 13:19 |
Not-6102 | [iDempiere4.1] jenkins built #107 completed (success) http://ci.idempiere.org/job/iDempiere4.1/107/ | 13:35 |
*** aguerra has joined #idempiere | 14:49 | |
*** nmicoud has quit IRC | 15:47 | |
*** CarlosRuiz has quit IRC | 17:53 | |
*** aguerra has quit IRC | 17:56 | |
*** jdpaniagua has quit IRC | 23:53 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!