Users wanting to access DESM through multiple organizations but the same username/email

[DMSaunders]

If you want to use the same username between multiple organizations, there will be an error. Suggested fixes were: A) tell people to use a different email for different organizations B) allow the same email/username to be used for multiple organizations

[jbaird123]

@DMSaunders - The current functionality is by design. We can modify it, but that would be a future enhancement.

[edgarf]

@philbarker Would we have to provide a "selector" between organizations when somebody logs in with a multi-org account?

[philbarker]

@edgarf I actually don't know what the fix for this is, I'm thinking it might be trying to solve the wrong problem

I think we need a re-think around organization in DESM. The current model is that people would represent Data Standards Org and be responsible in mapping schemas from that organization. That's not what is happening in many cases.

Currently,

• the same user / email can be associated with many mapping projects which helps a lot;
• a single user/org can map >1 schema in a project.

If we treat the user's organization as separate from the DSO that produced the schema, I think we would have the functionality that we need. That would mean that I could set up a project with me representing Cetis LLP, to map CTDL from Credential Engine to schema.org from Schema.org etc. But doing that would have implications right through DESM's internal data model and the export files.

@jeannekitchens thoughts?

[jeannekitchens]

@edgarf @philbarker I think we need a walk through showing how emails are now handled as the user name. The main point here is that a person working on more than one mapping or an administrator who already has an account and needs to see all of the mappings they set up the configuration for have use different email addresses to see each mapping they are associated with.

E.g., jkitchens+ceds@credentialengine.org to access CEDs; jkitchens+ctdl@credentialengine.org to access CTDL, jkitchens+CASE to access CASE. I do not want to have to add + to my email address. I need to log in with my email address and access any mappings that I have been associated with.

We had also set up a related issue to use role management as in a norm with applications that need to allow a person to have permissions to access multiple mappings.

[philbarker]

@jeannekitchens @edgar first up, yes we do need more conventional user/group role management as Jeanne has said.

We also need to remove the connection between the users organizational affiliation and the DSO that produced the schema, and we have mostly done that.

Also, the same email can already be used for as many mapping profiles as you want.

Do we need organizations within mapping profiles? Do we need to say that some people on a mapping project cannot edit what others are doing but some people can? I can see it as a useful feature in the future, but without group-level access permission settings it seems more problematic than useful.

Finally, admin users cannot currently be mappers. Do really we need that restriction?

[jeannekitchens]

@philbarker I don't think we should put barriers around team members editing within a mapping. That should be a benefit. I

We do not need a restriction that prevents admin users from being mappers.

[philbarker]

Proposed solution: Remove the concept of organizations within a profile.

I don't know the back-end implications of this so I'm not going to doa check list. but:

On the admin interface for setting up a new profile section 4, currently for DSO's Information would be replace with direct access to adding mappers: a bit like this:

When using a profile for mapping: all mappers added to the profile would have access to all mappings. Everyone would be able to see what anyone else in the same project is doing and to edit that work.

We might in the future add group-level access privilege back into mapping projects, so don't you might keep that in mind when making back end changes.

Also, please remove the mappers name from the name of the mapping, it's leaking personal information into things like filenames of exports.

When looking at specifications, e.g. through view mappings, we currently see:

The heading for that page should be "Mappings"

The column under Specification Name currently shows the mapping name comprising: Mappers Name + organization + Specification Name + Domain + Specification (I think!)

It should be changed to two columns showing the Schema Name (or "Spine"), and the Abstract Domain being mapped.

Make sure that when exported / displayed anywhere public the mappers name / author is not included. e.g. file names for exports should include only «schema name»+«schema version»+«abstract domain»

[philbarker]

Situation is better now, also see #538