U4-10103 - API Breaking change list

Created by Claus Jensen 05 Jul 2017, 08:34:25 Updated by Jeavon Leopold 20 Sep 2017, 12:00:44

Relates to: U4-10398

Subtask of: UAASSCRUM-1073

We need to document all breaking changes, there will be quite a lot based on the fact that User Types don't really exist. We can also investigate how to minimize breaking changes but there will be some.

  • change in IUser and Umbraco.Core.Models.Membership.User ** Replaced int StartContentId { get; set; } with int[] StartContentIds { get; set; } ** Replaced int StartMediaId { get; set; } with int[] StartMediaIds { get; set; } ** Removes IEnumerable<string> DefaultPermissions { get; set; } ** Constructor parameters changed
  • Removes interface IUserType and implementing classes
  • change to IQuery - adds WhereAny
  • Umbraco.Core.Models.Identity.BackOfficeIdentityUser empty constructor no longer exists, use BackOfficeIdentityUser.Create instead
  • UserService events removed (these have been replaced by events for UserGroups): ** UserService.SavedUserType removed ** UserService.SavingUserType removed ** UserService.DeletingUserType removed ** UserService.DeletedUserType removed
  • umbraco.BusinessLogic.UserType is gone
  • umbraco.BusinessLogic.User.UserType is gone
  • Angular changes: ** user.resource.js is now users.resource.js *** The disableUser method no longer exists. Instead we have a disableUsers method that now takes several userIds instead of just one userId
  • HealthCheckContext.HttpContext no longer exists, use UmbracoContext.Current.HttpContext instead

Additionally:

  • U4-10398 No longer shipping with CookComputing.XmlRpcV2 assembly
  • U4-5546 Remove user 'channels', weblog api, and all code / db tables relevant to those
  • U4-10084 Cleanup all unused/legacy webforms editors, tinymce files and affiliated services
  • U4-5804 Remove all the old images that are no longer used in the umbraco and umbraco_client folders

Comments

Claus Jensen 16 Aug 2017, 11:29:37

https://github.com/umbraco/Umbraco-CMS/blob/dev-v7/src/Umbraco.Web.UI.Client/src/common/resources/user.resource.js has been renamed to: https://github.com/umbraco/Umbraco-CMS/blob/dev-v7.7/src/Umbraco.Web.UI.Client/src/common/resources/users.resource.js

The disableUser method no longer exists. Instead we have a disableUsers method that now takes several userIds instead of just one userId


Shannon Deminick 18 Aug 2017, 00:12:24

  • umbraco.BusinessLogic.UserType is gone
  • umbraco.BusinessLogic.User.UserType is gone


Shannon Deminick 19 Sep 2017, 23:43:58

Why is this the case?

HealthCheckContext.HttpContext no longer exists, use UmbracoContext.Current.HttpContext instead

I don't understand why this was changed in rev 1445ff7a839dbbceb679e29614384938dc9e6c30 when we use the HttpContext when it is available. Having health checks rely on singletons is not what we want at all! We should have either left the public (should have been protected) HttpContext property or changed it to TryGetHttpContext (if the health check was running on a background thread). //cc @abutland ?

Using a Singleton will have the same problematic effect and your health check will result in a YSOD when run on a background scheduled health check if you aren't null checking.


Andy Butland 20 Sep 2017, 06:36:19

IIRC the thinking was that the only thing any health check needed access to the HttpContext for was in figuring out the website URL. So we exposed that as a property (which does use the HttpContext if available, and falls back to configuration if not). But only that is exposed, not the whole HttpContext object. That way anyone building healthchecks won't rely on it being there (and discover it's null when their health check runs on the scheduler).

UmbracoContext isn't exposed either, for the same reason.

TryGetHttpContext sounds a nice idea though - then it's clear the healthcheck developer has to work around it not being their in scheduled contexts.

@crumpled_jeavon - you recall anything further?


Shannon Deminick 20 Sep 2017, 06:40:53

Yup but now the problem is that people will start using singletons and not do null checks which will lead to further problems (and people shouldn't be using singletons in the first place)


Jeavon Leopold 20 Sep 2017, 12:00:44

I remember that Health Checks shouldn't use HttpContext as it won't be available when run in the background task so instead we introduced HealthCheckContext.SiteUrl & HealthCheckContext.ApplicationPath which were the properties needed by the Core checks. We should advise the use of these properties to anyone creating/updating custom checks and certainly don't recommend the use of UmbracoContext.Current.HttpContext


Priority: Normal

Type: Bug

State: Fixed

Assignee:

Difficulty: Normal

Category:

Backwards Compatible: False

Fix Submitted:

Affected versions: 7.6.4

Due in version: 7.7.0

Sprint: Sprint 67

Story Points: 1

Cycle: