These are chat archives for OrchardCMS/Orchard

7th
Mar 2017
Xceno
@Xceno
Mar 07 2017 11:57

Anyone knows if there's a reason we don't look into the import context when importing CommonParts? This prevents us from setting the owner of an imported item to a user that gets currently imported :/

https://github.com/OrchardCMS/Orchard/blob/1.10.x/src/Orchard.Web/Core/Common/Drivers/CommonPartDriver.cs#L81

Carl Woodhouse
@carlwoodhouse
Mar 07 2017 12:47
i assume because technically the importer becomes the owner
having imported it
if that's right or not, who knows ;)
Xceno
@Xceno
Mar 07 2017 12:57
Well I can log in as whoever with import-privileges and run an import; but the owner will be set to the superUser or the CommonPart.Owner <- if the user already exists in orchard
bpr-admin
@bpr-admin
Mar 07 2017 15:24
I think that there's a solution to deploying Orchard to AWS Elastic Beanstalk, that I am unable to accomplish. I read the AWS tutorial on deploying drupal thinking that I could utilize the same type of procedure, however ...
AWS labs created a configuration files download that glues it all together. I really hope someone could make a similar file for Orchard.
S├ębastien Ros
@sebastienros
Mar 07 2017 16:33
@Xceno What I read is that the owner is kept, if the user account actually exists, or it will use the current importer as the new owner.
Xceno
@Xceno
Mar 07 2017 16:34
Okay, but I think if the user is present in the importContext then it technically "exists" no?
S├ębastien Ros
@sebastienros
Mar 07 2017 16:35
if there is no user with the same name
so you need to create a user account with this name before
Xceno
@Xceno
Mar 07 2017 16:41
makes sense, but then we should also check for existing users when importing users in general.
Right now we can duplicate users and populate the database with invalid data. But maybe it's by design and we should make sure that we have valid xml anyway ;)