Roles & Profiles - integration of the necessary modules?

Hi,

Could you please specify why it can bring some security issues ?

Because role signup worked like that, and it was good to select a role IMHO, in addition, the custom url would provide you to add some extra code in a module depending on that url. Now, I think you cant, so I would like to understand why and try to find or create a module that could fit my need as role signup did.

I'm open to receiving patches for this feature quest if you'd like to do one that is not exploitable. The original request, if I recall properly, was to allow a code in the url that would automatically register people. Any time you can perform an action in Drupal that is available via anonymous access from a URL it creates a threat.

Hi, i am being do this too. For user role i am using Auto Assign Role.
But how to register with that path ?
Like Jolidog said,

If user subscriber register the path for register is :
http://mysite.com/user/register/subscriber

and if

user contributor the path for register is :
http://mysite.com/user/register/contributor

Thanks

Whilst I appreciate that this may be a security issue (although I don't know why exactly), is there any possibility of implementing a workaround?

I currently am developing a site where it is not appropriate for the user to have a choice of their own role. 99% of the users are just plain "members", so there is little value in offering the choice to the user. A more appropriate method is to have a "default" choice which allows the standard registration form to offer certain fields, with a separate form for other users elsewhere.

This scenario unfortunately doesn't even sit with content_profile well either, because in order to allow for c_p fields on the registration form, they have to be exposed via field permissions in cck. To do two profile types with entirely discrete forms is now seeming almost impossible, because until a role is assigned, the permissions for "member" or "premium" cannot be assigned to the requisite fields, therefore at the moment they are viewable/editable by anonymous, which is a complete hash.

This module has so many use cases where it will need to integrate with content_profile, I think it is imperative that we get a debate going (and preferably a very short one) regarding integrating aar and c_p so that we have the following:

• sane workflow! any implementation of this mechanism currently has too many steps or is actually impossible
• lightweight integration without module bloat
• distinct workflow for individual roles and profile nodes (user gets assigned one role, and a corresponding profile node)

I agree that an integration makes sense. But the permission problem can't be solved cleanly on the registration page - as there the user isn't created yet and can't have any roles. So perhaps it's best to move role type specific profiles behind the first registration step?

But there is still the possibility to create different registration URLs for different roles, like rolesignup did. Since one has to configure, which roles are allowed to register for, I don't think there is a security issue. So we can build integration, that allows selecting content types per roles like it was with node profile and role signup. However, this doesn't change that one has to enable the fields for anonymous users when field permissions are used.

The security issue reference was from a different post entirely and is not relevant to this thread. I'm still a little confused about the mechanics of the workflow involved to meet this need but can appreciate the value it would offer. I'll commit to downloading content_profile over this weekend and beginning to taking a look at options.

Just some notes about the workflow... The workflow in autoassignrole is different than the module it replaces. IMO, this is not a good thing. It's nice that there is this new option to pick a role at registration, but for me, I can't think of many use cases where this will be useful. It is seemingly much more likely that a site will be developed in such a way as so the admins can put specific registration links where they like.

So the standard workflow in autoassignrole goes like this: a user goes to the site, decides to register, clicks the "register" link (there can be only one (quote recognised)) and is presented with the user/email registration stuff, and an extra widget to pick their role (as per the settings of the AAR module). Submitting this form presents the user with their account page. There is no current integrated way to force the user to create the profile node - they have to manually click the link to edit it (IIRC). This is a very long workflow which is not good for getting complete profiles from users.

The more obvious workflow, which would have been instantly possible if rolesignup had been ported "as is", is that the user goes to the site, is presented with a custom registration link (ie, /user/register/[role-name]), and is then whisked off to a custom registration page, which contains the cck fields (and taxonomy hopefully ;) and so on. This is much shorter, means that site owners are getting the demographic information they require, is more usable, is easier to theme, and makes the job of the site developer much easier as they have custom urls that are more easily segregated.

The problem with the choosing of a role is, 99 times out of 100, the option will either confuse the user, or the site owner will want control of who gets what role, without the user necessarily having any options. In my case, I will have two "external" roles, one for subscriber and the other for advertiser. Obviously the site owner does not want to present the majority of users with the option to register as an advertiser. This is just confusing and will dramatically reduce the amount of people registering (which is what the owner wants people to do). This issue would be completely bypassed by using the workflow as previously presented by rolesignup, as far as I can tell.

I appreciate your opinions but the porting of the module was done in an effort to preserve as much of the original functionality as possible. The additional options were added based on user requests for functionality, similar to the request you are making, to directly meet the business needs of systems we've integrated this module into. The core workflow is not going to change regardless of how obvious it may seem to you. I appreciate your feedback and efforts to involve the other module developers and will make every effort to accommodate what you are looking for while staying within the bounds of what this module is intended for. If you don't want the ability for users to select their own role there are administrative capabilities to control or hide those options from them. Perhaps your energy would be best directed towards helping to enhance the admin side to provide the options you are looking for.

i'm very interested in this, so subscribing...i'm in the situation very similar to niklp

First of all, let me say I'm not here to be critical - we are all of course very grateful for the efforts of any developers who contribute to modules which we can use.

Further to your comments, cyberswat... I am a little confused by the direction of this module - you use the phrase "preserve ... original functionality" but this module does not seem to have the same workflow as the old rolesignup module did. However, this module purports to be the replacement for said module?

Can we please clarify if it is possible to replicate the functionality/workflow of the rolesignup module using this module? If not, is it trivial to port the old rolesignup module so that the workflow is preserved? I still have seen no mention of why it was inappropriate to port the module as it was, or indeed to omit the existing method of using custom paths to registration forms. I would be grateful for some clarification on the matter.

Furthermore, I will invest any effort/money as required to get this to a point where it meets my needs - the workflow as I have described it (as per rolesignup) is essential to and very pressing for a project that I am currently working on.

Many thanks for any further information etc.

This is where you confuse me ... What exactly does autoassignrole not do that http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/rolesignup/... did?

I was using the rolesignup module for displaying registration pages per role - as suggested by this line of code from the link above:

$url = "user/register/role/".$roleid;

I was under the impression that these paths were not provided by the AAR module because of some security concern?

"The security issue reference was from a different post entirely and is not relevant to this thread." The functionality your pointing to wasn't included because it's written into the theme layer ... I'll put something in that does this properly.

Don't worry, I saw the "not relevant" thing (several times) - what I haven't seen yet is why it was ever mentioned! Not sure what you mean about this being "written into the theme layer" either - will an cursory glance at the code shed more light on this?

Edit: having browsed the code, I see nothing akin to the path-based method in there. I don't get it :/

"...it's written into the theme layer ... I'll put something in that does this properly."

Any further ideas on this? I'm on the verge of porting rolesignup to D6, which I'd rather not do - if there's a secure and elegant way around this problem.

Take a look at head ... I've been working on it.

Ah! good stuff. I installed the dev version - obviously it's not working yet, but I can see roughly where it's headed.

I wonder if there are easier ways to implement the UI - but I'm not totally sure what the expected result is yet - I don't quite "get" the wording in a couple of places.

Keep it up though, man! Thanks :)

This thread is a convoluted mess of different topics. The original request was vocalized clearly in comment #1. The dev branch that will be generated tonight has a solution to that problem in place. The solution is imo properly implemented utilizing the correct hooks for the task. The solution has appropriate administrative control and security for the original request in this thread.

With the introduction of comment #5 an entirely different topic came into the discussion. It is my firm opinion that there is now a solid framework for path management that can serve as a foundation to meet the requirement of displaying Profile content type form fields on the registration form.

Now that this framework is in place I am focusing on providing an additional option in the administrative area of AAR that will allow you to associate a content type with the path. AAR will then provide the necessary functionality to enter that content types fields after the account is created. I do understand the benefit of this use case and am working to provide a solution ... I do not yet know exactly how this is going to be implemented, so I am being intentionally vague, but I do know that when I am done it will work ... your patience is appreciated.

Just spent the past couple hours in irc with NikLP to get a full understanding of the problem ... taking a look at it now.

Tentative fix for this http://drupal.org/cvs?commit=146208 and http://drupal.org/cvs?commit=146209 where I removed the comment I had in place for testing. The attached patch is necessary for content_profile_registration.module but is extremely minor. This needs feedback and testing.

This scenario now offers role-based registration on pre-configured pages (paths), in a secure way. You can enter configuration information to set up custom paths on a per-node-type basis for this. Furthermore, it offers a widget under the "content profile" dropdown in the content type configuration to specify which path should be assigned to this particular node type.

Using this method, we can now:

- create multiple user profile types (using cck, content_profile)
- assign a role to users as they register (using autoassignrole)
- internally assign a path to each role that is assigned (using autoassignrole)
- designate which profile node form is to appear on that path (using autoassignrole)
- save the profile node, and the new user, with the correct role assigned (using cck, content_profile, autoassignrole)

What remains to be fixed is that taxonomy does not appear on the user registration pages. The code also requires some testing. There are some outstanding bugs in the content_profile_registration module that need to be looked at also. (see #21)

Edit: Warning: Some of the code for autoassignrole may still only be in HEAD

Ehm.... Any one can give the steps to do that ?
Thanks

I will certainly be hoping to get a guide up on this in the near future - at the moment I'm hoping one of the dev guys will fill in the few remaining gaps so that we have a watertight solution - at least for my use case, which I feel is pretty common.

Has this actually worked for anyone?

It does not want to auto assign the role when using Assign from path----I get the form I specified in /drupal/admin/user/autoassignrole, and can fill it out and submit it when I go to the link I designated for that form....but after submitting, upon checking users, I never get assigned my designated role (so I'm never able to access the role specific content profile).

I ran the content registration patch, and am using lastest dev of Auto Assign Roles. Where am I going wrong, or do I need \HEAD for Auto Assign Roles?

-Daniel

Edit: Looks like it was grabbing comparing the full path to a partial in the database. In the module, changing the last line of:

if ($form_id == 'user_register' && module_exists('content') && module_exists('content_profile')) {
$profile_types = content_profile_get_types('names', 'registration_use');
$path = request_uri();
...to...
$path = drupal_get_path_alias($_GET['q']);

fixes my little issue.

Hm, my brains's not quite in gear, but this looks like it should be using the Drupal internal path, instead of the request URI - which is what the code above (I think) is doing - right? :)

It uses the path var in its query to get the role it should switch to, but in my database it showed a short, relative path (which I guess is the drupal alias) while the original var was returning an absolute one and therefore causing the match to fail.

So... I changed the var to return the alias, and it matches what's stuffed in the database now. (Not versed in the ways of drupal enough yet to know how path aliasing and such can factor in, but this seems to work in all cases for me...)

You may need to also change the other place the url is accessed, if it's not taking into account aliasing, earlier in the module:

$path = substr(request_uri(),1); should probably be:

$path = drupal_get_path_alias($_GET['q']);

Having those in place, it works fine for me now after running the patch earlier in the thread. I set it up two paths for my two login types, associated them with the profile content, and when I go to those pages as a new user, I'm given the right registration form and auto-role'd to the proper role.

Hmmm...may have spoke too soon. If I allow the actual profile fields to appear on the registration page (not just on the profile page), I get the following when it's accessed:

warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, 'node_form' was given in C:\Program Files\EasyPHP 2.0b1\www\drupal\includes\form.inc on line 366.

warning: Invalid argument supplied for foreach() in C:\Program Files\EasyPHP 2.0b1\www\drupal\sites\all\modules\autoassignrole\autoassignrole.module on line 411.

This solution currentlyit works fine for me, as long as I make a few very small changes.

(I'm posting this on both Content Profile #313341: setting up various content types for different roles and AutoAssignRole #301464: Roles & Profiles - integration of the necessary modules? threads related to the subject, since they seem to be focused on the same thing and maybe this info will help. I think once all the varied peices are updated to fix the below with something more than my hacks, it will be a solid solution.

The intent here is to be able to designate a URL which when used will take the new user to a registration page containing fields specific to a given role, and auto-assign that role to him when he submits it. The scheme uses Content Profile, and AutoAssignRoles.

I'm using the current dev version of AutoAssignRole and Content Profile (6.x.1.x)

These are what I had to do to get it to work for me...your mileage may vary:

---- Changes in: autoassignroles.module

$path = request_uri();
...to...
$path = drupal_get_path_alias($_GET['q']);

..and..

$path = substr(request_uri(),1);
..to...
$path = drupal_get_path_alias($_GET['q']);

(These are to get it to handle path aliases right when figuring out how to assign role by the path used to get to page.)

if ($type) {continue;}
..after..
foreach ($profile_types as $type => $typename) {

(This is to avoid a callback error I'm getting when it calls drupal_retrieve_form...not sure exactly why it's getting a bogus callback, but this change fixes it with seemingly no ill effects but this probably isn't optimal)

--- content_profile_registration.module

I used a modified module supplied in #313341 by kenorb (thanks!) to allow proper use of content profile stuff on registration page mostly by fixing some path alias issues. Not absolutely sure it's needed--put it in before i thoroughly tried the base module.

Finally, I had to remember to assign the URL used to get to the login page (the one you set in the AutoAssignRole path field) to be the same as the content profile "type" name I used when creating the content, or it will act like "All Registration Forms" is in place and you'll get content from all the content profile's that you've set up to be on registration forms. Looks like it's trying to match the content type to the last argument of the path in "content_profile_registration_form_alter" in the content_profile_registration.module. In other words, if I call my path in autoassignroles /sites/fan_registration...the type name of the content I'm pulling the fields from needs to be "fan_registration".

I've updated the path calls so basically consider this issue to be closed ... Tonights dev version should have everything in it that will make it work. This leaves the problem of getting the patch applied to content_profile.

@fago any chance of getting the patch in #21 committed to content_profile?

@daneyuleb your efforts at documenting are appreciated but please learn to submit patches ... you will also find that placing the issue numbers in brackets [] will automatically create a link to the issue. I edited your comment to illustrate.

Sorry for the confusing reporting. I'll look into creating patches (though the base hackery I was doing isn't something I'd want to commit to the module.)
Trying the latest, I get the following error when loading the registration page:

warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, 'node_form' was given in C:\Program Files\EasyPHP 2.0b1\www\drupal\includes\form.inc on line 366.
warning: Invalid argument supplied for foreach() in C:\Program Files\EasyPHP 2.0b1\www\drupal\sites\all\modules\autoassignrole\autoassignrole.module on line 406.

This occurs only when I have two content profiles, each assigned to a different URL path via the Content Profile UI. The module seems to be trying to access both content profiles on the registration page even though each URL's registration page should only load the content it's been designated to. I have applied the content_profile_registration.module patch in #21 in this thread and it made no difference--same error. (Using the latest Content Profile registration module: content_profile_registration.module,v 1.1.2.24)

I'm not sure if I'm missing something or there's a bug. I have installed the latest release of AAR and the latest Nov 4 dev version of Content Profile. I setup 3 content types with a variety of form fields. From the Content Profile setting on the content type Edit page, I selected "Use this content type as a content profile for users" and selected the path for that content type. I have AAR enabled and also enabled each role within Assign from Path settings. Each role is set to display in tabs on registration page and the path is the name of the content type. I set user permissions for anonymous to have access to edit and view the fields from within those content types. When I go to mysite.com/user/content-type then the correct tab is selected, but only the username and email address fields show up. If I try to create a user it doesn't assign a role to the user. Am I missing a step or is this a bug? Thanks.

subscribe

I'll make the efforts to work on this again if the patch to content profile gets applied ... it doesn't make sense for me to keep trying to accommodate that module if the changes aren't going to be incorporated.

I'm not sure if it's ok to do this, but I asked at the Content Profile forum if it would be possible to apply the patch soon so that Auto Assign Role and Content Profile can robustly work together. The thread is at #330479: Working with Auto Assign Role . I hope we can get them to work together soon.

The Patch in [21] doesn't actually fix anything - hence, I'm confirming the bug in [28]

Also, I'm really lost as to what's going on with both of these modules now - can't we centralise this somewhere? There's threads all over the place, and there's no clear unified goal that I can identify at the moment.

Can someone please update as to where this is headed? We have paths set up for content_profile_registration ready to go, thanks to cyberswat and the adaptations made to the AAR module.

It seems now that the c_p_r module needs some... well, CPR, really! I *urgently* need this module to be working for multiple content profiles, with full node forms on dedicated paths.

I am prepared to invest money in getting this moving forward, but I *really* need some help determining what the issues actually are. If we can just get some input here as to what is actually needing to be done to get ANT/AAR and C_P(_R) working together.

Pleeeease? :)

Surely this needs some love?!

mostly just subscribing.. thanks to niklp and cybersawt for getting things this far.. and just to re-enforce niklp's much earlier comments.. way back in 4.7 days i put together a site with nodeprofile and role_signup that worked quite well and performed the 2 basic functions:

- provide different registrations forms for 2 different types of users
- assign them to these roles when they signed up (but still needed to be validated in std methods)

doing a Dr6 site now and amazed to find out this functionality has disappeared.. surprised fago hasn't been all over this.. sounds right up his alley.

i'll start going through the various threads and checking out the patches and see if i can sort out where things are at... hopefully there is a working solution here; if not.. i might need to do it myself.. grrr.. :(

Peter Lindstrom
LiquidCMS - Content Management Solution Experts

just trying to figure out where this is at and make sure i am not redoing earlier work.. i grabbed dev of aar and latest rel of content_profile and no patches (what is content_profile_registration.module, is that part of this mix?).

anyway.. pretty much everything seems to be there - i am able to create 2 node types, set it to be used in registration (sadly, need to set this twice i think, once in node edit page and once under content profile tab) and define each specific to one 2 roles. I have 2 links for register/role1 and register/role2, all looks great; but when i select either link i get:

    * warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, 'node_form' was given in C:\Inetpub\websites\8to13\includes\form.inc on line 366.
    * warning: Invalid argument supplied for foreach() in C:\Inetpub\websites\8to13\sites\all\modules\autoassignrole\autoassignrole.module on line 406.
    * warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, 'node_form' was given in C:\Inetpub\websites\8to13\includes\form.inc on line 366.
    * warning: Invalid argument supplied for foreach() in C:\Inetpub\websites\8to13\sites\all\modules\autoassignrole\autoassignrole.module on line 406.

is this as far as anyone gets?

Your use case is similar to mine I think, but AFAIK there is no available fix for this. The problem isn't with autoassignrole, but with content_profile_registration, the two main threads as far as I can gather are:

http://drupal.org/node/307639
http://drupal.org/node/301464

Your use case is similar to mine I think, but AFAIK there is no available fix for this. The problem isn't with autoassignrole, but with content_profile_registration, the two main threads as far as I can gather are:

http://drupal.org/node/307639
http://drupal.org/node/301464

ok, well not sure of the status of all this - but it seems to be working for me.

i get my parent node type when i click "register as parent" link, and when i fill them in and signup i can see on that users profile page that my node has been added with that content and i see that that user is indeed in the role they should be in based on the url used for registration

haven't tried much else.. but so far it all seems to work just as i recall role_signup working back in Dr4.7 days :)

perhaps i spoke too soon suggesting this all works.. it mostly works, but these are the bits i see busted.

would be good to hear from others what they they think the current "closest" solution is, mine is this:

- latest dev versions of all modules concerned
- patches from here applied: http://drupal.org/node/337423#comment-1131270

this is what i have working:

- 2 roles: parent, child
- 2 node types: parent_profile, child_profile
- 2 links for registration: register/parent, register/child

- link shows only the profile node type for that role
- when user registers they do get their profile node attached to their profile and they are automatically assigned to that role

bits that don't work:

- user has both node types assigned to their profile (i think patches listed above were meant to fix this??)
- if i go to std user/register i see both node types on the reg form (node settings for autoassign suggest it controls this; but dont think it is doing anything)

Can anyone confimm that this is where this solution is at?

What if you don't even care about the advanced profiles and stuff?

I just want to create two different user roles using paths. I don't care about all this extra profile stuff. Shouldn't this work with AAR?

Check this patch: http://drupal.org/node/313341#comment-1237651 for content_profile.

re #45, yes, i think if you just want multiple roles (possibly with patches noted above, but maybe not even required) then it should work just fine.

hey kenorb, thanks for link to updates to the other issue (one of too many on same topic here). i had seen that post as well a couple wks ago, but looks like new development;

hard to tell from the posts exactly what is working or what modules required or what other patches are needed to what; but will likely sit down and go through your solution in next week or so. too bad we don't have a clearly defined set of requirements (assuming superset of them is pretty common) as i believe the use case i define in #44 above is. or, we could just say, replace rolesignup module.. lol.. since that worked.

eager to try your new module though - can you verify it does what i define in #44?

thanks,

Is the issue described in http://drupal.org/node/364638 the same one as you are trying to solve here ? In which case I'll mark it as duplicate and close that one

If so can someone please confirm for me which bits I need to get to test things at the current stage of development.

From what I can see reading above my use case is similar to that described comment #39 (http://drupal.org/node/301464#comment-1228741).

I think I need dev snapshot versions of the following modules

• Auto Assign Role
• Content Profile - which already has this patch appiled (http://drupal.org/node/313341#comment-1239705)
• Profile Role ????

Do I also need these patches ? http://drupal.org/node/337423#comment-1131270

Thanks

Ian

subscribing

subscribing. will check out all those patches which are running around for both content profile and AAR. soon to report back ;)

@liquidcms - about issues in #44 and #48 - i just tried a clean install with the patches you've mentioned + the patch kenorb mentioned in comment #46. this is what i've got:
- 2 user roles, appended to users on registration using separate paths (signup/1 and signup/2)
- 2 content types, marked as profile content types, selected to appear on registration paths above accordingly
- I've set permissions so that anonymous users are allowed to create both profile types, and also allowed creation of each to the appropriate role. this way, once a user is registered with a certain role - he will not see the "Create profile" link for the other profile type in his user account.

This is what's working:
- User can register on either paths, and correct roles are granted on registration.
- While registering through paths, correct fields show up in reg form.
- The permission i've described work to eliminate confusion.

This is what's not:
1) When anonymous users visit user/register they are presented with fields of all forms
2) The title of the created profile is not displayed on the user's page.

Possible solutions:
1) Get rid of user/register all together - it simply isn't necessary in most cases if you found the need for AAR and Content Profile anyway.
2) I don't know about this. my plans are to now override the user page with panels (possibly using APK), so that might be a solution. another idea could be to user a module such as Real Name (if we can get one to work correctly with Content Profile) which would solve this + provide a nice bonus to the setup.

Has anyone got these issues figured out?

I'll mess around with this some more...

I have done similar on my current development site and found much the same as asak. All works.

Unfortunately the bit I need is not yet functioning - My issue is how the unregistered i.e. anonymous users choose what user type they are going to be once they visit the site ? I guess I could create some content that says if you are a user_role_1 use this link and if you are a user_role_2 use that link.

However I'm more looking for something that does what role_signup did in D5 i.e. when user decided they want to register then they get to choose what user_role they are before proceeding to filling in profile?

From my view point I think it may be possible to use profile_role rather than content_profile to deal with the role specific profile information - but this is only because if I use CCK and content_profile then when I want to USE that information in a user list I can't because CCK and views don't play nice together - a whole other issue and not one for this thread. Unfortunately Can't persuade profile_role to hide the user_role_2 content for user_role_1 unless the user is already registered and their role type is known !

Suggestions please ?

IanT

...this is only because if I use CCK and content_profile then when I want to USE that information in a user list I can't because CCK and views don't play nice together - a whole other issue and not one for this thread.

Well, from my point of view CCK + views works much better then profile fields + views - BUT i just assume that because of my experience with D5 and "old" views.

You could probably achieve what you're after by having a custom "What role would you like to be?" form dynamically load the actual registration form, which will include (following this discussion) the desired profile fields. I'm just going to place two links "Signup as X" and "Signup as Y" so that users will be directed to the right form, but I think views could do what you're after...

I think that if the 2 issues i mentioned above would be solved and all patches commited - this is actually a very easy and powerful solution for D6 custom profiles and roles setups.

And now i'm puzzled...

How could I manually call the autoassignrole_user function to display a specific role registration form, regardless of the current location, in a block?

function autoassignrole_user($op, &$edit, &$account, $category = NULL) {
so the $op is 'register' - but what can i pass for the other parameters to get the correct "signup for x role" form?
should i manually set the arg(s) and "fool" it that way...?

I know this should be easy.. but i'm not a coder ;)

from #53

i.e. when user decided they want to register then they get to choose what user_role they are before proceeding to filling in profile?

I'm sure AAR does that at this point.

I believe #477910: fix / simplify content profile integration finally puts this issue to rest. Tentatively marking fixed.