So there's this route to enroll a user in a section, but there doesn't seem to be the opposite: a route to unenroll a student from a section.
In fact, there doesn't seem to be a direct route to unenrolling a user from a section from within the LMS itself. I just watched our administrator "unenroll" a student by switching their role in the section to "no role," which, incidentally, isn't a role available via /d2l/api/lp/1.4/roles/.
What am I missing here?
Thanks!
From what I can tell, it definitely seems like that is an oversight in the Valence API. I haven't tried it myself yet, but I wonder if the course offering unenrollment cascades down to the section enrollment also? Naturally that doesn't help solve the problem if you have to unenroll a user from a course offering just to switch their section enrollment within that course offering.
In terms of unenrolling a user from a section within the LMS, this can be accomplished by going into the Section Management within that course offering (Edit Course -> Sections). Then select 'Enrol Users', this will open a table listing the classlist where every section has a column that you can check on/off to enroll/unenroll the user in that specific section (check off more than 1 to enroll in multiple sections).
Have you tried un-enrolling the student by referring to the section's orgUnitId directly? Perhaps you can try explicitly removing the user from the section's org unit ID, and then, either removing the student's enrollment from the course offering org unit id, or re-enrolling them in another section, as appropriate?
I think part of the issue is that you are thinking about this from a front end perspective, and not a back end one. The transaction you are looking to do is actually a delete and not an enrollment. It sounds bad because we are trained to see anything with the word delete as bad, but from a data standpoint, there's no such thing as enrollments and drops, you have inserts and deletes.
Related
I have a situation that I have a system that communicate with iLog and it should show the values of decision table first column.
Can I get all the values of the first column in a decision table? Given that the values are distinct and unique.
If yes, What if I want to get the values of the next column under the scope of the first column field.
I need this behavior since I have an agreement creation system which must allow creation of agreement terms based on what is already implemented in iLog
There isn't a way to extract values from Condition Column. I had also came across such situation when but couldn't get through it. However, there is a work-around for the same.
My Problem was, for example, there are rules to determine whether the user group to which user belong is allowed to approve the policy? If not, then what are the other user groups allowed to approve this policy?
One simple solution was to maintain two tables, one for checking and another to determine allowed groups. This was not accepted since business needs to maintain same data in two tables. Had it been FICO BLAZE Advisor, the same would have been implemented in a single table.
However, there is always another way to a problem. What I did is following:
1. Created a single table to list all are the groups which can approve the policy i.e. adding user groups into a list in the action column. Placed this decision table in a Rule Task.
2. In the final action of rule task, checked whether the user type of the incoming user exists in the list of user types. If not, it means user is not allowed to approve the policy so send the entire list; otherwise, set the list to null and set Approval flag to True.
I hope this may help you to find an alternate solution which may address your problem. Sometimes, we need to look for some weird way to get our work done.
HAPPY RULE DEVELOPMENT. :)
I have a set of queries on the Team home page that use the standard #Me, for example to let different users quickly get to bugs they have personally raised, PBIs they created that are now in a certain state.
The users are in customer groups and I'd like to have a similar set of queries showing as tiles on the home page, e.g. "Team Open Bugs", "Team PBIs for review".
Is it possible to write a query that does this -
Select all [work item type] from [team project] where [state] and [#myCustomerTeam] ?
From what I have read so far I believe this is not possible, and certainly not possible through the UI. I'm curious to find out if anyone has solved a problem like this - having different customer groups see different Team Favorites tiles on the Home page of Team Web Access - in some other way. I'm going to try making three sets of queries and putting different permissions on them (there are TFS groups that correspond to the Customer Group field) but I'm not confident that Denying even Read permission on the query itself will stop the tile showing on everyone's homepage.
Edited to say that solution worked for my purposes, as per comment.
Still interested to know if anyone has managed something like this more cleanly. In this case the field I would have liked to parameterise happened to be something I could map to a completely different type of thing, thus shifting the problem. I can imagine wanting to parameterise a field that didn't have that characteristic though.
I've been using /d2l/api/lp/1.4/enrollments/myenrollments/ to get a list of enrollments for the current user. Now, I want to just get the enrollments where the user is in an instructor role. So, I'm trying to use:
/d2l/api/lp/1.4/enrollments/users/{userId}/orgUnits/?roleId=105
When I use that, I get an empty list of Items back, with or without the roleId specified.
My expectation is that just calling it without the roleId would return the same list as /d2l/api/lp/1.4/enrollments/myenrollments/. But, I always get an empty list, except when I log in as a system administrator. Only in that case do I get anything back.
Does anyone have any suggestions on what I might be doing wrong?
The various my* API calls specifically exist to provide end users to fetch back details about the system that they should know, but segregated from information they shouldn't (that's available through the more general routes for a particular area). Enrollments is a good example of this. And end-user should be able to see their own enrollments, but they should not have generalized access to enrollment records. In particular, the D2L system treats the D2L user role belonging to an enrollment as fairly privileged information, and a side effect of this is that it's not generally visible to end users.
One way that applications and services can cope with achieving goals that the end-user cannot themselves perform is to have set up a "service account" that the app can use to make calls of an administrative nature, to fetch back data that they can use in the business logic around presenting information to end users. In this particular case, you could, for example use the service account to make calls about a user's enrollments, and then present the user with logic that could filter the list of their enrollments by "these are the student ones, and these are the ones where you're a teacher, and a tutor, and so forth".
But you'd also need to carefully consider the implications of this type of activity in balance against the intentions of the client LMS's policies and administration. Even this level of information may be giving away too much to end users, in the eyes of a client LMS administrator.
Using a service account to let an app make administrative level calls must always be done with great care around the issue of information/functional leakage to end users.
Using Rails and am new to it (and RDBMs). Have read lots of posts and articles on modeling and associations, but could really use a reality check on what I'm thinking for my particular case.
I have 3 main models: users, accounts, plans. The accounts are multi-user, with plans worked on by all users attached to the account (with varying privileges). If the account is destroyed I’ll also take down its users and plans.
Looks like the basic associations would be as follows. Is this correct?
users
belongs to - >
< - has many
accounts
has many ->
<- belongs to
plans
Is there any value in associating users with plans with “has many through”? I see that it would allow access like #user.plans and #plan.user[1], but can’t I access each via accounts, as in #user.account.plan?
Is it the case that with “has many through” the middle model simply belongs to the other two? All the examples I’ve seen show that. In my case, that would be inappropriate, since account actually owns the other two.
Is there a better way to model this (multiple users of an organization working on a set of one or more plans)?
Input is very much appreciated.
Your design is correct. The belongs_to terminology can indeed be a bit strange, but is proper. Use "has many through" if it makes your code more readable and obvious. (In other words, if the notion of a user having a plan makes sense, and is needed, go ahead and create the relationship. If it is more clear to conceive of the plan belonging to an account, then stick with user.account.plans.)
Your design should be sufficient so long as you don't need to restrict a user to a subsets of the plans belonging to an account, and so long as a user only belongs to a single account.
I'm learning Rails by building a simple site where users can create articles and comment on those articles. I have a view which lists a user's most recent articles and comments. Now I'd like to add user 'profiles' where users can enter information like their location, age and a short biography. I'm wondering if this profile should be a separate model/resource (I already have quite a lot of fields in my user model because I'm using Authlogic and most of it's optional fields).
What are the pros and cons of using a separate resource?
I'd recommend keeping profile columns in the User model for clarity and simplicity. If you find that you're only using certain fields, only select the columns you need using :select.
If you later find that you need a separate table for some reason (e.g. one user can have multiple profiles) it shouldn't be a lot of work to split them out.
I've made the mistake of having two tables and it didn't buy me anything but additional complexity.
Pros: It simplifies each model
Cons: Managing 2 at once is slightly harder
It basically comes down to how big the user and profile are. If the user is 5 fields, and the profile 3, there is no point. But if the user is 12 fields, and the profile 20, then you definitely should.
I think you'd be best served putting in a separate model. Think about how the models correspond to database tables, and then how you read those for the various use cases your app supports.
If a user only dips in to his actual profile once in a while but the User model is accessed frequently, you should definitely make it a separate object with a one-to-one relationship. If the profile data is needed every time the User data is needed, you might want to stick them in the same table.
Maybe the location is needed every time you display the user (say on a comment they left), but the biography should be a different model? You'll have to figure out the right breakdown, but the general rule is to structure things so you don't have to pull data that isn't being used right away.
A user "owns" various resources on your site, such as comments, etc. If you separate the profile from the user then it's just one more resource. The user is static, while the profile will change from time to time.
Separating it out would also allow you to easily maintain a profile history.
I would keep it separate. Not all your users would want to fill out a profile, so those would be empty fields sitting in your user table. It also means you can change the profile fields without changing any of the logic of your user model.
Depends on the width of the existing user table. Databases typically havea limit to the number of bytes a recird can contain. I fyou are close to (or over which you can usually do if you have lots of fields with null values) the limit, I would add a table with a one-to-one relationship for better performance and less of a likelihood of a record that suddenly can't be inserted as there is too much data for the row size. If you are nowhere near the limit, the add to the exisiting table.