Master - Party should allow editing and display of roles


#1

Using Party, I have been unable to either display or edit “Roles”. The only way I have been able to view INTERNAL_ORGANIZATION is to go to:

Party - Find Users -> SELECT “INTERNAL_ORGANIZATION”

Example: While looking at the Party “Company”, roles are not displayed, nor is a link available.

Thanks


#2

You are right. There was no easy way to edit the SecurityGroups directly from the party screen. I guess we must have missed that one when we tried to disentangle the security screens from the party screens. The screen was still there, but not linked correctly.

I committed a quick bugfix, which will be pushed to github later today.

Thanks for reporting this issue!


#3

Just for the record, here’s the direct link to the screen you are describing:

https://ce.scipioerp.com/partymgr/control/EditUserLoginSecurityGroups?userLoginId=admin

The userLoginId is parsed as a parameter here. Please be aware that a userLogin must be created first, before any roles can be added to the user.


#4

Having looked at the screen more closely, I really think that we may want to add a list of userLogins & SecurityGroups / singular permissions there…


#5

The bugfix has been pushed to github.


#6

Great. I’ll check it out.


#7

Sorry, Paul, I was referring to Roles, not Security Groups. Iike:

https://ce.scipioerp.com/partymgr/control/viewroles?partyId=Company

But it seems like we need more ways of viewing and editing parties. It seems like there is a lot of capability that is missing in scipio that seems to be in standard ofbiz. Maybe you should put horizontal tabs in to display all the possible sub-menus. We need all of them.

Mike


#8

Ah, you are referring to party roles, which are shown here, correct?

If so, then yes, the menu item has been disabled for the moment, the screen still exists. You can renable it, by removing the comments on line 66 & 76 in applications\party\widget\partymgr\PartyMenus.xml. Before you do, consider this however: There is a reason why we disabled it for now and that is, that partyroles are circumstantial at all times. Meaning that assinging a party role is useless without the context it serves in. The screenshot I attached is a decent example of that, there you can see that the Party “Company” has the following roles attached:

  • INTERNAL_ORGANIZATIO
  • CARRIER
  • ACCOUNT
  • BILL_TO_CUSTOMER
  • BILL_FROM_VENDOR

None of which are of any use by themselves: internal_organisation is used to mark company as part of the company operating the system but only comes into play inside of accounting, carrier means that the party acts as a carrier to deliver goods of sorts but requires the delivery methods and other info about the whereabouts of delivery in general, account is used inside of the CRM and still requires the information about specific parties that are assigned to this account, bill_to_customer and bill_from_vendor are both roles that play a role in accounting, where the party acts as one or the other during specific transactions. None of these can exist by themselves however and either adding or removing one will mess with the context it is being used in. We removed the link to the screen because of this and we strongly recommend to not add or modify roles on their own. If you require them, you will require them in the context of a specific use-case and then the use-case should take care of it.

OFBiz has a problem of overbloating the screens with information that can not be used by themselves. Sure, you can always display more, but often it will not add to the usability of the system. We do not follow the same road.

As for the tabs: When we worked on the party application, a tab navigation has not been available to our toolkit. We didn’t want to rely on multiple button rows, as those are deeply confusing, so we decided on moving the links that lead to sub-screens to the left sidebar:

With the newer applications, like accounting which we are currently working on, we are tranferring these tabs to a right-hand navigation, or to group-buttons. The other apps will be updated with these changes in future releases.


#9

I would like to encourage you to not disable functionality. The ‘admin’ user should be able to edit anything without hacking the database. I’m having trouble finding things that are available in ofbiz, like viewing/editing tax authority rate products.


#10

There is always a discussion to be made here, but in general our focus is more about end-user and less so about individual developers. So we did make alot of changes to existing screens, reevaluating functionality. User roles are a good example: they are not useful for end-users and there is no benefit from the screen in comparison to directly accessing the db for an administrator. There is also the functional aspect to it: if you mess with any of the values, you will have an impact on functionality that is happening on entirely different applications. So leaving it in is not a wise decision.

We did re-evaluate many of the screens and will continue to disable and rearrange how we see fit. So it is entirely possible that you will find that things have changed from your ofbiz experience, but we are not an ofbiz clone and changes are necessary. I am sure that after time you will find that our interfaces make more sense and they are alot easier to use. You did bring up an interesting screen here, though. Like mentioned elsewhere, the accounting application is currently being worked on for 1.14.3 and the TaxAuthority Screens have not been added to the menu yet. I will take care of it the coming days (i plomise).

That being said: feel free to ask us about any screens you are missing and please keep up the great feedback you are giving us. It helps us tremendously - and it also makes us question our own decisions.


#11

Maybe allow selectable screen types, like “Advanced”, “Normal”, and “Basic”. Place a drop down under “Select Theme”.
That would be useful.


#12

An interesting idea, for sure. But wouldn’t it make more sense to rather use precise user & security group permissions then? Perhaps we could/should improve the seed data there, so that the initial security groups better differentiate between common user roles like “Author, Editor, Admin” or such…

But as far as screens are concerned: there will still be cases where it really isn’t beneficial to be able to edit such info. Just think about the DataSources for example - they do exist as empty bodys that link to Text, Documents or other objects. Adding or removing a single one will not really do the job you want to do, it just enables you to do the job you wanted to do. So having a datasource is a necessity from a db perspective, which you will require if you want to assign (for example) product information to a product. It makes no sense otherwise, however. I think with the vastness of the db model, the question we continue to ask ourselves is: are users interested in a dataviewer type application that lists all aspect of a database, or are they interested in specific functions.

As for this project: we really do want to have people working with the applications, which, btw, is an entirely different philosophy than what the ofbiz community has been doing.


#13

OK: I’ve come to the conclusion that the party editing is erratic. Besides not being able to add a Role (this is super important, a “supplier” needs “BILL_FROM_VENDOR”, for instance, the sub-menus generated after selecting a party are NOT associated with the party selected. Instead, the sub-menus jump off to non-party related stuff. Any fixing I do to a party has to be done via SQL or suck it in from an xml file, like this:

PartyRole partyId=“Gallery” roleTypeId=“BILL_FROM_VENDOR” createdStamp=“2017-06-25 22:50:26”/>
PartyRole partyId=“Gallery” roleTypeId=“SHIP_FROM_VENDOR” createdStamp=“2017-06-25 22:50:26”/>
PartyRole partyId=“Gallery” roleTypeId=“SUPPLIER_AGENT” createdStamp=“2017-06-25 22:50:26”/>
PartyRole partyId=“Gallery” roleTypeId=“SUPPLIER” createdStamp=“2017-06-25 22:50:26”/>


#14

I tried to follow your approach and agree that this is not ideal. The Roles themselves are missing in the screens and the split between the vendor screens on accounting and party means that it isn’t easy to add a new vendor.

@minifreak: Can you take a look at this?


#15

Sure thing. I will fix it right now.


#16

Roles have been added back to the user management application for now. Perhaps, We should also add additional screens to the accounting application, which allow an easier way to add new vendors. Definately something to discuss…


#17

Or maybe implement a multi-tiered complexity system: basic,moderate,advanced?


#18

lol… you never give up on that, do you? :wink: