5.2, The "owner" role, how to define?

[Jesper W, geändert vor 15 Jahren.]

So I made a first shot at starting the 5.2 portal with our extensions and database.
Since 5.1 there is apparently a new role required called "owner". I read the Blog entries about it.

We don't have it in our old DB and the UpgradeProcess didn't create it, so I get a TB:

12:25:20,484 ERROR [MainServlet:164] com.liferay.portal.kernel.events.ActionException: com.liferay.portal.verify.VerifyException: com.liferay.portal.NoSuchRoleException: No Role exists with the key {companyId=1092, name=owner}
com.liferay.portal.kernel.events.ActionException: com.liferay.portal.verify.VerifyException: com.liferay.portal.NoSuchRoleException: No Role exists with the key {companyId=1092, name=owner}
at com.liferay.portal.events.StartupAction.run(StartupAction.java:83)
at com.liferay.portal.servlet.MainServlet.init(MainServlet.java:156)
at javax.servlet.GenericServlet.init(GenericServlet.java:212)

What tables/rows are needed in the database for this role? (I assume I will need to do it in SQL before invocation)

/jesper

[The Meurwinn Concept, geändert vor 15 Jahren.]

Hi,
did you try to look for "owner" in the sql create sript in the LR5.1 to found the tables and columns to create ?

[Ray Augé, geändert vor 15 Jahren.]

This Role should only ever be referenced if you are using RBAC
(permission algorithm 5), which you can't upgrade to.

Make sure you have your permission check algorithm set to 2 when
upgrading and after.

See the Wiki for details on upgrading.

[Jesper W, geändert vor 15 Jahren.]

Well.. See the thing is we upgraded to RBAC at 5.1 through a manual process. (Well actually through a PHP script, but anyway...)
So now we are trying upgrade from 5.1 RBAC to 5.2 RBAC.

Maybe it's a unique situation and the lack of upgradeprocess is not an issue.

I would still love a hint on what the minimum SQL rows needed are :-)

/j

[Ray Augé, geändert vor 15 Jahren.]

Ok well, here goes.

You need a new Role called Owner for each company instance in the portal
(1 record for each new "Owner" Role + Company combination).

Then for every Resource, you might need to assign default permissions to
this Role. This last part you might be able to get away with. Problem is
that you need this in particular for things like Message Board messages
and categories such that a user can edit their own posts.

See, with RBAC the normal user permissions are all granted to the single
Role "Owner", this avoids the need for user permissions. Then, Owner is
implied for any user only when the ownership criteria are met (the
object has a userId field and the Object permission check implements a
check between this value and the current permissionChecker).

So, depending on your usage, you might need to handle that case (via
your PHP script again).

[Jorge Ferrer, geändert vor 15 Jahren.]

Hey Jesper,

I would be very interested in knowing more details about the migration process that you've followed. I've been thinking lately about the possibility of implementing a portlet to guide in a semi-automatic upgrade process. The basic idea would be to show a list of all permissions that should be migrated and allow the user to assign them to roles manually. Do you think such an approach could work?

An alternative would be to provide some framework classes that would allow users to implement their own migration script. We could base it in the application builder plugin to allow doing it completely on the client side.

For either case it would be great if you could share with us some of the conclusions from your migration and if possible share the PHP script you created (or whatever part you can disclose)

[Jesper W, geändert vor 15 Jahren.]

Jorge, I'll mail you the script. It actually says quite a bit about what I did even if it's a quick and dirty thing. And totally specific to our database, of course. (Which is why I don't want to publish it for security reasons, being slightly paranoid due to recent hacker penetration attempts)

And thanks for the tips, Ray!

/j

[Ed Shin, geändert vor 15 Jahren.]

Btw Jesper, what has been your experience of developing off trunk? Has it worked out well so far? Do you stop at a certain revision and stay there, or do you continue to push the latest updates from trunk to your code? (Sorry to go OT. I'll limit this to this one post.)

[Jesper W, geändert vor 15 Jahren.]

Ed Shin:

(Sorry to go OT. I'll limit this to this one post.)

Well how on earth am I suppose to answer then?!? Hahaha

So this thread got a bit messy, what will it matter in 100 years from now...?
Actually our rev history is worth a whole novel. I'll try to keep it short.

We sat for a long time on the 4.4.x branch quite comfortably.
Now we've been on a complete mess of a 5.1+some more+bits and pieces for 6 months.
The system is solid as is but I'm looking forward to getting on a stable branch again.
We've been merging bugfixes and shipping all the mods to our portal tree upstream, and everything's been accepted except for webform enhancements which will be one of the headches for us in getting on 5.2 I think.

How it's working out... well, performance was the main reason for the premature upgrades to 5.1++, but we can handle around 500 pages per second with average 20 portlets/page since then so I think it worked out well...

[Ed Shin, geändert vor 15 Jahren.]

Jesper W:

Well how on earth am I suppose to answer then?!?

Haha, thanks Jesper!

[Ed Shin, geändert vor 15 Jahren.]

Hi Jorge, Jesper,

Please keep me in the loop too! I'm very interested in this because I want to move to the new 5.2 permissions system too. Hopefully, I'll be able to get your help and be able to contribute back too. Thanks!

[Jesper W, geändert vor 15 Jahren.]

Oh and once we're on the subject, what happened to the Beta testing forums?
What is the proper place really to discuss 5.2 issues now?

[Jorge Ferrer, geändert vor 15 Jahren.]

They weren't as successful as we had wished for last time, so we haven't made a lot of emphasis on them this time. But please, feel free (and encouraged) to use it for any issue you find in 5.2. Your feedback is always very appreciated.